GuildWiki talk:Style and formatting/Archive 4

Table Templates
I would like to add the html command: rules="all" to several templates that include a table, because the inner lines are not drawn in the Opera browser. I have tested it with IE6.0, Firefox 1.0.7 and 1.5, and it seems there is no harm in adding this. --Trilo 11:44, 19 May 2006 (CDT)
 * lovely. - 12:25, 19 May 2006 (CDT)
 * I have changed it for the armor art and function template. If there is no negative post about it, I will continue with the other templates. --Trilo 12:49, 19 May 2006 (CDT)

Use of the article in self references
Is it "GuildWiki" or "the GuildWiki"? I notice that User:Tanaric, the original author of many of the style and policy pages, prefers the latter, but the former is the more prevalent usage. Koyashi 07:59, 25 May 2006 (CDT)
 * The site is called GuildWiki, so I always refer to it as just GuildWiki. It's kind of different from "The New York Times", though I'm sure some ppl would just call that "New York Times" anyways... - 08:07, 25 May 2006 (CDT)
 * Of coures, if you are referring not to the entity GulidWiki, but using it as a qualifier, like referring to admins or whatever, then I'd use "the GuildWiki administrators" or "the GuildWiki server" etc. - 08:11, 25 May 2006 (CDT)
 * Sorry, I didn't ask for an English lesson. Is there no set policy on this? Koyashi 08:17, 25 May 2006 (CDT)
 * Sorry, I didn't intend to give you an English lesson (and I make no claims that my personal preferred usage above are grammarically correctly in English). There's no declared policy on it, I was describing how I personally saw the issue. - 08:18, 25 May 2006 (CDT)

the untouched question: Prefix vs Suffix
This should've been hammered out a while ago, but we never got to it. I think all the categores that says "Factions blah" should be renamed to "Blah (Factions)". The "Blah" is the more important part of the information, and I see Factions as additional supplemental to distinguish this Blah from the Blah of other campaigns. It also eliminates the use of sortkeys for some of the categorization process. If I see no discussion, I'll do a crusade two weeks from today. If there is discussion, then we'll see how it goes. - 13:51, 27 May 2006 (CDT)
 * Plz do, and a lot of the Factions quick reference etc needs to be Canthan quick reference etc imo Skuld  13:56, 27 May 2006 (CDT)
 * That I disagree, but that's a different discussion for a different section. - 13:57, 27 May 2006 (CDT)
 * I would say that unless an object is specifically named "Factions Sword" or something within the game, then certainly (Factions) should be used to distinguish items from Prophecies and Factions.  &lt;LordBiro&gt;/&lt;Talk&gt; 19:52, 27 May 2006 (CDT)


 * Quick bump since there have been quite some distractions. I'm not going to bother with last day reminders or anything. - 23:34, 31 May 2006 (CDT)

Going on a lunch break. Will start the crusade when I get back. - 14:04, 10 June 2006 (CDT)

& vs and
Let's make it consistent. Either rename "Style and formatting" to "Style & formatting", or rename "Slang & terminology" to "Slang and terminology". Is there anything else that would be impacted?

For previous discussion, see, GuildWiki talk:Style and formatting/Archive 1. - 07:56, 8 June 2006 (CDT)


 * Software_&_Technical_Issues/Bugs &mdash; Skuld  08:35, 8 June 2006 (CDT)


 * Skuld, could you be a bit more specific? I can't seem to figure what you're referring to. --Bishop (rap|con) 08:39, 8 June 2006 (CDT)
 * Unless... you're trying to point out the use of ampersand there... I see... you may want to be a little less convoluted in your replies, it makes it easier for us slow folks. :P --Bishop (rap|con) 08:41, 8 June 2006 (CDT)
 * I thought Pan was looking for stuff with &s in, am I wrong? &mdash; Skuld  08:43, 8 June 2006 (CDT)


 * Nope, not wrong. If you had said: "Here's one:" I would have gotten it too. I'm slow that way. (Often, when responding with just a link people, especially you, mean to say "read here" so that caught me off guard.) ;P --Bishop (rap|con) 08:48, 8 June 2006 (CDT)


 * I'm in favour of completely avoiding the ampersand in article titles because they're reserved characters (or whatever the term is). -- Gordon Ecker 00:39, 27 August 2006 (CDT)

Double spaces after periods
There is one thing that has been irritating me for quite a while: The inconsistent use of double spaces after periods/full stops in GuildWiki articles. Most people don't use them, but some few regulars use them all the time. What's the deal? I'm not a native speaker, so others should explain. I wouldn't have said anything, but since some of the regulars here are very nitpicky about grammar, spelling, capitalization and such, I thought it's about time that somebody asks for clarification. Shall we define a standard or let everybody do as he prefers? -- 06:51, 23 June 2006 (CDT)
 * P.S: Full_stop --[[Image:TurningL sml.gif|Tetris L]] 06:55, 23 June 2006 (CDT)


 * I have noticed this as well. I see it only as a very minor issue though, since the only time you'll even get aware of it is when editing articles. HTML can't display multiple contiguous blanks (as long as you don't use no-break-spaces) so everything is displayed single-spaced once the article is saved. It would be nice of course if we had conformity here, too, but it's nothing where I would see the need of a written policy or something like that. :) --84-175 (talk) 07:08, 23 June 2006 (CDT)


 * Yeah, on the              wiki, it  doesn't                                                        matter how    many spaces     you   use, after a     period   or  not.                                                                                                                    - 07:26, 23 June 2006 (CDT)


 * LOL, nice PanSola. I agree that it doesn't need to be as a policy. There's nothing stopping me from getting rid of the double spacing too :P -:- Ab.Er.Rant (Talk)  07:41, 23 June 2006 (CDT)


 * I'll admit that I use them, mostly out of habit. You learn to type on something other than a computer/word processor and the general rule is you use two spaces after a period.  I could care less if people use them or not, as has been stated above it doesn't make a difference in the display, but there is no way I am going to try to break myself of the habit.  :P  --Rainith 10:25, 23 June 2006 (CDT)


 * I agree. It's a tough habit for either to change.  Either you were trained to use them when first taught to type; or you weren't trained to use them.  That training establishes habits that both groups would find hard to change (either to start double spacing or to stop).  As it makes no difference in the final displayed article, I don't see a reason to make a requirement one way or another on this (and for the record, I double space - learned on a typewriter, pre-pc).  --- Barek (talk • contribs) - 10:29, 23 June 2006 (CDT)


 * Yar. It really doesnt matter to me. And nice example pansola =P. However spaces do matter inside pre tags

I like pancakes.

I like pancakes.

I    LLLLOOOVE     PANCAKES!

outside pre tags:

I like pancakes.

I like pancakes.

I    LLLLOOOVE     PANCAKES!

--Draygo Korvan 10:31, 23 June 2006 (CDT)

Capitalization
I searched but could not find anything on this subject. How do we capitalize? Eg, profession types? So far I've capitalized it Elementalist only if it's the first word of a sentence, elementalist if it isn't, but it also seems I'm the only one. &mdash; Galil  19:12, 25 June 2006 (CDT)
 * First rule of thumb: use proper Engligh. Second rule of thumb: use proper nouns as desginated by the game (if something is capitalized in the game, we capitalize it too).  Elementalist is desginated as a proper noun in the game, at least for the great majority of the time I believe. For the actual policy, refer to GW:case. - 19:40, 25 June 2006 (CDT)
 * In other word, as I have always done. Thanks. ^^ &mdash; Galil  19:47, 25 June 2006 (CDT)
 * Um, the other way around. Proper nouns should always be capitalized. - 21:17, 25 June 2006 (CDT)
 * Hmm, think I misunderstood your first response. Then I better change my habit of not capitalizing profession names.. Thanks again. :p &mdash; Galil  21:23, 25 June 2006 (CDT)


 * Do not capitalize profession names, they are not capitalized in-game when they come in the middle of a sentence, and they would not be capitalized in regular English caps rules. --Karlos 23:10, 25 June 2006 (CDT)
 * Then I'm reverting to not capitalizing profession names in the middle of sentences. Thanks for clearing that up. &mdash; Galil  22:33, 1 July 2006 (CDT)


 * Umm... actually, they are capitalized in-game, most easily seen from dialogues and quotes. Example? Here's one of Cynn's lines to Jamei after your Tyrian characters arrive in Cantha: "Listen lady, he may not be much, but that Monk is mine!" And this isn't the only instance. There are alot of dialogues where profession name captilization occurs. Really? Yea... I'm kinda guilty of removing the capitalization of the profession name from sentences... :P I guess I should try to revert when I come across some of them again... --Ab.Er.Rant @ User:Aberrant80 (msg) 00:09, 11 July 2006 (CDT)

on Characters being "Tyrian"
When you create a new character, the game doesn't offer the choices of "to be born in Cantha" vs "to be born in Tyria", the choices aren't "Tyrian" vs "Canthan". Thus I want to push for standardization on the wiki that uses the phrasing "Prophecies Campaign characters" vs "Factions Campaign characters", versus "Tyrian characters" or "Characters born in Tyria" etc etc. A very specific semantic beef I have with "born in" is two native Ascalons could have gone to Cantha, and a kid there, then brought their kid back to Ascalon. The kid would have all the "racial" markings (or character creation options) inherited from the parents, witness the Searing, yet be "born in Cantha". This is on the nit-picky extreme, but I want to illustrate the issue of using "flavored text" not from the game. Because the roleplayer character creation does offer choices based on Campaign and not on continent (and when you log in, character selection also doesn't say "Tyrian" but says "Prophecies Campaign", I think we should stick to that. It's fine to call them Tyrian or Canthan in casual conversation or talk pages, but for technical stuff it's different.

Another issues is what if a future campaign takes place on multiple continents, or if a particular continent ends up being the main location of multiple campaigns? - 00:43, 12 July 2006 (CDT)


 * Yep, I kinda thought about that "multiple campaigns on the same continent" thingy for NPC categories, so I'm agreed to the standardization. I'd also suggest that the "Campaign" part be dropped to make a shorter bit of text, so it'll be " Prophecies characters " and " Factions characters ". --Ab.Er.Rant @ User:Aberrant80 (msg) 02:31, 12 July 2006 (CDT)

the ranger profession icon template
Can we put something in here about using lowercase for profession icon templates (,, , , and ) by default to prevent the problem with template:r? -- Gordon Ecker 04:58, 22 July 2006 (CDT)
 * We could... but isn't that a bit drastic? How about simply deleting the template and then recreating it? Maybe it'll solve whatever's wrong with it. --Ab.Er.Rant (msg Aberrant80) 05:07, 22 July 2006 (CDT)
 * Deleting and recreating the template was already tried. This is seemingly something that can't be "fixed" because it is not really a glitch, but instead now a reserved character (in uppercase at least) in the new mediawiki version. There is previous discussion of the topic on the template's discussion page, Skuld's discussion page, and the Software and technical issues/Bugs page. --Kwisatz 23:21, 22 July 2006 (CDT)
 * We could incorporate it into the profession ondering section. -- Gordon Ecker 20:27, 24 July 2006 (CDT)

Please stop floating TOCs to the right!
Guys, I understand that, on some pages, on some browsers, a right-floated TOC looks nice. However, If somebody wants to float the TOC, they can do so on their user CSS page (I'm doing this now: User:Tanaric/monobook.css). Shoving stylistic information into our pages adds needless complication. Forcing the right-float mucks up things for some people. It's confusing to browse on pages and have to find the table of contents each time. Finally, whether the right-float is better or not is a personal opinion, and forcing it on everybody isn't the thing to do.

If the consensus is with me, I'll start reverting right-floated TOCs as I find them. &mdash;Tanaric 23:34, 9 December 2005 (UTC)


 * If we're going to do this, then I request that each page starts with a section (for the text part at least). That way we don't get pages with a half dozen lines of text and then a TOC, then the rest of the article.  See Academy training quests for an example of what I'm talking about.  A Table of Contents should be at the top of the article.  Or we could just get rid of the altogether.  --Rainith 23:52, 9 December 2005 (UTC)
 * Apologies, I right float TOCs because I saw other ppl doing it, so just assumed it's the "right" thing to be doing. I agree with Rainith though.  Having the TOC buried at an unknown location vertically is worse than looking for it at the top of the page not knowing if it's gonna show up on the right or left. -PanSola 00:04, 10 December 2005 (UTC)
 * As an addition, I don't care if we have them on the right or left or none at all. I've stated before that for things with a box on the right side (Bestiary entries, Items, Skills, etc...), a TOC looks bad on the right.  In those situations I don't like it on the right.  Other pages I have no problem with it being on the right.
 * If you can't find it when it's on the right... just how big is your monitor? Or how high do you have the resolution set at?  I run at 1280x1024 at home and have no problems finding the TOCs on the right or left.  --Rainith 00:27, 10 December 2005 (UTC)

I've revived this somewhat old discussion because this trend is continuing&mdash;actually, it seems to have become the standard. I'd like to reiterate that it's an extremely bad idea&mdash;the contents of this edit box is supposed to be the page's content, not the page's formatting. The wiki engine will format the page however it feels.

It has been noted elsewhere that forcing TOCs to float right on individual pages can cause them to render incorrectly on different browsers / small windows. I like the fact that I can use GuildWiki (on most pages) with a 400px-wide window or less. This allows me to run Guild Wars in a 400px window, side by side with the wiki.

More importantly, though, it's not asthetically pleasing to me. I prefer the standard MediaWiki TOCs. I can't even force them all to render on the left, since the local style commands in the TOCright template override user CSS. For such a questionable application of personal taste&mdash;especially when we've decided in the past that we're to emphasize content over presentation&mdash;I think that we need to remove TOCright tags.

&mdash;Tanaric 05:54, 2 August 2006 (CDT)


 * Back to the original replies to this: as long as all articles start with a heading, then I have no major problem with this - although I would like more discussion before a change is made (see below). I find that it's much harder to locate the TOC when it's buried under several lines, or even several paragraphs of text, rather than a right or left issue, so I would want to insist on ensuring that the TOC is always at the top.
 * On the issue of at the top ... I believe that the reason that most users force to right isn't an issue with their personal preference on right or left as much as it's a preference in how the article contents display. In the two browsers I've used, a TOC right results in the main text being at the top of the page along with the TOC also being at the top, with the article text wrapping around the TOC box much as it would around a thumbed image box.  With the default TOC on the left, you need to scroll down to reach the start of the article (ie: only the TOC starts on top, the  article begins after it).  I don't have a strong preference here (I need to think more about the issues here), but I can certainly understand a preference for the article text to be at the start of the article, and the TOC to be as well, just next to it.  If it causes problems, I would like a better understanding of those before we reach a decision here.
 * I'm curious about the browser issue you mentioned. With all of the pages that force to right (including this one), I'm surprised that the first I've read that some browsers have problems with this is here.  Can you point me to the discussions where it was brought up before?  Which browsers have problems with this command?  What, exactly, is the rendering issue it causes? --- Barek (talk • contribs) - 08:19, 2 August 2006 (CDT)


 * I don't like it on build pages, when I have to run 800x600 all the boxes show bits through the ToC &mdash; Skuld 08:28, 2 August 2006 (CDT)


 * Honestly, I don't know where I read that right-floating TOCs cause rendering issues at low resolutions. It's not something I felt the need to test. Nobody has provided a reason to float TOCs right besides "I like the way it looks better," and that alone is reason enough for me to argue against it.


 * What happens if an upgrade causes the Monobook style to do weird things with TOCs that floating right makes them horribly unusable? For that matter, how well does floating them right work on non-Monobook styles? There are too many questions, none of which have been asked by the editors who started this habit.


 * We've chosen to use MediaWiki software. If Gravewit wants to hack around with the source to change things, I'm totally okay with that. However, us changing things on a case-by-case basis like this in the content has the potential to lead to problems down the road&mdash;not to mention, annoying me at present. :) &mdash;Tanaric 11:25, 2 August 2006 (CDT)


 * To me, the ifs about the future are a non-issue (and borderline FUD - don't fear change; adapt). Afterall, it's done via a template; if some future MediaWiki change did come along that caused horrible, nightmarish things to happen when TOCright was used, no problem.  We would just need to neutralize the template and all pages would work again.
 * The bigger issue to me are any rendering problems that occur in the here and now. From what I'm reading here there are problems with it on anything that uses a table in an area that could intersect with the TOC; build pages, skill pages, etc.  I also agree, it looks horid on most item and weapon pages.  Those, to me, are reasons to argue against its use if you have a strong preference for it to always be in the same location for consistency (ie: always left instead of right on some).  Thus far, I have no preference on left vs. right, other than a strong dislike of orphanned text appearing above the TOC.  But I am trying to understand the issues more here. --- Barek (talk • contribs) - 09:01, 3 August 2006 (CDT)
 * on some pages (high-80s percent) with some browsers (mozilla, IE, firefox, Opera, pretty much everything except Lynx) right floated TOC looks better. getting the table out of the line of text is preferable on every page excepting pages that already have something float right, i.e. the skill box, etc. the text should be allign left, with extraious stuff, like pictures, TOC, skill box, item box on the right. pages flow better and read easier. --Honorable Sarah [[image:Honorable_Icon.gif]] 09:49, 3 August 2006 (CDT)
 * That's odd. When I read about browser issue I too thought about Lynx. For that reason, I tried it (running linux half of the time and it's invaluable to have installed). The result was actually surprising. It didn't render too bad at all. The TOC ended up above the contents, but that's it (tried this page: Community Portal).
 * Other than that, the issues I have with the way editors seem to want to make things are using tables for design. Tables are meant to contain data, not to move things around on the page. That's what layers (aka divs) are for. Also, I sometimes see tags that aren't even following the html/css/xhtml standards. If one were to validate the code used on every page on the wiki, I doubt either of them would turn out valid (but then again, I guess MediaWiki's developers are partly to blame). This isn't good for accessibility. But those are just minor problems at the moment. And I feel I'm going off-topic here, so I'll just stop it there.
 * Either way, I don't really care if TOC's are floating left, or right, or none at all, as long as there's consistency (actually, now that I think about it, and after testing, TOCs floating left doesn't look good). So in a way I do agree with Tanaric. But on the other hand, long TOCs tend to "dodge" page contents downwards, so I also see why this is necessary on some pages. Also, how would you solve it with pages like this? In short; I want consistency, but I also realize we cannot get it on all pages unless we modify all the styleguides and pages. &mdash; Galil  10:37, 3 August 2006 (CDT)
 * most pages of that size do not require a TOC, and pages that are long enough to require a TOC should be float right unless there is something already there, such as this page. --Honorable Sarah [[image:Honorable_Icon.gif]] 10:55, 3 August 2006 (CDT)
 * That's also how I was thinking. Though if we float the TOC to the right even when there is something there, I don't think it'd look horrible, as long as the TOC is on top of the other stuff. Granted it depends on what is to the right. &mdash; Galil  11:27, 3 August 2006 (CDT)


 * I'm sorry Tanaric, but I just plain don't agree with you. As far as I'm concerned, the TOC should be A) at the top, and B) in the place where it fits the article, be it left or right, according to the contents. Some articles, like skills and armor, we have a specific template that goes to the right. In such cases, having the TOC on the left -- or not at all -- makes the most sense. However, on many articles, especially long ones, it is a real pain to have to scroll simply because of the TOC, especially at low resolutions or in a small window. The solution to that, is to position the TOC on the right, where it floats nicely and the text flows around it. This placement conserves valuable screen real-estate, and is more aesthetically pleasing than the large chunk of blank space that is caused if the TOC is on the left. The issue of "not being able to locate the TOC" is bogus, especially since noone notices the TOC at all (except as a nuisance) unless they're actively looking to use it. And so is the issue of formatting in "some browsers we don't really know". All browsers are different in how they display things, and if actual, real problems crop up, then they can be handled at that time. There's no reason to change good practice because of problems that may or may not arise in the hazy future. -- [[Image:Bishop_icon2.png]] Bishop [ rap|con ] 22:08, 3 August 2006 (CDT)


 * Disagreed. You don't have to scroll to get around a large default-position TOC. You just have to click "hide."


 * The arguments against using the default TOC seem to be based around the opinion that it looks better on 80% of the pages. My opinion is that it doesn't. While I totally respect that you can have a different opinion than me, I don't understand why we're filling the pages with formatting code to make it look better under your opinion. Again, I go back to user CSS: you guys can force the TOCs right via user CSS if you like. However, if you force the TOCs right via the TOCright template, there's no way for me to force them left again.


 * There's a reason the TOC splits the text in an article the way it does. It's to provide an introduction, then the table of contents, and then the body. This is a standard that exists everywhere&mdash;books do this, as do text files and other websites (including the oft-referenced Wikipedia).


 * Additionally, there's the matter of consistancy&mdash;I abhor having the TOC be in a different place in different articles. Right now, only about 16% of the wiki uses right TOCs. This is low enough that I don't expect it when reading, and thus will very rarely ever actually see the TOC. It's human nature to follow the patterns you're used to. I've been around this wiki for 15 months with normal TOCs, and that's a tough habit to break when the gain is marginal (or totally negative, in my perception).


 * Also, there's the matter that it breaks absolutely the Simple skin and looks horribly with MySkin.


 * Any arguments I haven't fleshed out in this post I'm willing to abandon as trivial or borderline-FUD. If nobody is swayed by this response, I'll just grit my teeth and bear it, I suppose. &mdash;Tanaric 21:33, 5 August 2006 (CDT)


 * You know, in general terms, I very much agree with much of what you're saying. For example, I am a firm believer in content over presentation. And when you mention the short introductory text above the TOC on some pages, I have no problems with that. In the end, however, it really comes down to a matter of preference, and I still feel that dynamically placing the TOC according to what fits the article is preferable to forcing it left.


 * On a side note, I'm wondering if it really isn't possible for you to force the TOC left by using the !important css tag. My skills in css are rather limited, so I really couldn't say for sure. -- [[Image:Bishop_icon2.png]] Bishop [ rap|con ] 21:49, 5 August 2006 (CDT)


 * I believe !important affects only the precedence between user-defined style and author-defined style, not the cascade order within a document. The TOCright template sets the style at the element level, so something at the stylesheet level shouldn't override it, even with !important, as far as I know. That said, my CSS skills are pretty limited too. In any case, I think it's somewhat inappropriate to require users to tweak layouts themselves to get back to the default Mediawiki setting. Like it or not, MediaWiki's skin has become something users are accustomed to&mdash;not just at the GuildWiki, but across the internet. Subtle changing that default, and only on 16% of pages, is bound to confuse. &mdash;The preceding unsigned comment was added by Tanaric (talk &bull; contribs) 04:40, 6 August 2006 (CDT).

Categories: "tree" vs. "sort key" method
This discussion was sparked here, but moved here for general discussion and hopefully more people involved. Currently we have two different methods of organizing sub-categories if there is more than one criterion to sort by:


 * 1) The "tree" (a.k.a. "bla by bla") method, used for example here.
 * 2) The "sort key" method, used for example here.

The "tree" method has the advantage that it is self-explanary, with a simple tree structure. It is well established, commonly used in Wikipedia and most other wikis. The big drawback is that it adds an additional level for each branch of the tree, requiring the user to click through multiple levels of sub-categories before he reaches the entry he is looking for.

The "sort key" method is (correct me if I'm wrong) an idea by PanSola. It keeps all subcategories on the 1st level, allowing to see them all without additional clicking. It is "flat", as opposed to the multi-level structure of the "tree" method. The big drawback is that it isn't quite as self-explanary, and the structure isn't obvious.

I think we should preferably use only one method, thoughout this wiki. So I'd like to make a decision, if necessary by vote. Please voice your opinion. Thanks! -- 07:33, 11 August 2006 (CDT)


 * While the sort-key method is better for those who are more familiar with the game to get them where they want to go quicker; I think the tree method will be better for newcomers as it's more easilly understood and intuitive. More clicks are involved to drill-in to where you want to go, but I still prefer the tree method on the basis that newcomers to the game and/or the wiki will find it easier to understand how to find the data they want. --- Barek (talk • contribs) - 09:35, 11 August 2006 (CDT)


 * As I said there, I prefer category trees. Categories aren't meant to be pretty, user-facing pages.  If you want to present the user with some kind of elegant display, make an article.  --68.142.14.39 13:26, 11 August 2006 (CDT)


 * I don't really agree with the sort key method. I agree with 68.142.14.39. If you want to create such a list use an article.  &lt;LordBiro&gt;/&lt;Talk&gt; 15:17, 11 August 2006 (CDT)
 * I prefer the tree method as well. To me it seems a touch simpler, and simpler is usually better in my book. Whenever I find one of the sort key pages I have to look twice to figure out where I'm heading next (i.e. Monk Skills isn't under "M"). With the tree method I don't. --Zampani 16:28, 11 August 2006 (CDT)


 * To be fair, Monk skills will still not be under "M" under the tree method. It will be in a subcategory of "Skills by Profession", that will either be under "S" or under "P".  So it's either look twice and click once (sort key), or look twice and click twice (tree). - 16:55, 15 August 2006 (CDT)
 * Touche. Perhaps that was a poor example. In the end consistancy is the most important factor for me, so as long as the same is used all around I'm not one to complain. Still, I find the tree slightly easier to understand at first glance. Then again, I eat breakfast for dinner sometimes as well, so I could just be confused easily.  --Zampani 01:31, 16 August 2006 (CDT)


 * I too prefer the "tree" method style. As mentioned already, if a flat list of links is desired, an actual page should be created rather than relying on categories. I see categories more of an index off the important aspects of each page. While the "sort key" method is also quite user-friendly, it's not very edit-friendly. --Ab.Er.Rant (msg Aberrant80) 11:32, 13 August 2006 (CDT)


 * I agree with everything pro-tree stated here. &mdash;Tanaric 13:55, 13 August 2006 (CDT)


 * Yup, tree is better imho. --[[Image:Gem-icon-sm.png]] (talk) 05:49, 15 August 2006 (CDT)

The result of the discussion is pretty clear so far, so I don't think we need a vote, unless PanSola insists. The majority favors the tree method. I'll take that as a permit to roll back any category from sort key to tree method when I come across one. PanSola, do you remember which categories you changed to sort key? -- 01:56, 16 August 2006 (CDT)


 * Triggered by the new Nightfall skills for core professions I have finally updated all the skill categories according to the result of the vote. --[[Image:TurningL sml.gif|Tetris L]] 04:12, 21 September 2006 (CDT)


 * Oops missed the aug 16 message. Anyways, the ones I touched would've been armor, skills, locations, weapons, and maybe some parts of the bestiary.- 09:08, 21 September 2006 (CDT)

Here's my stab at how to arrange it. Users shouldn't be directed at Category:Skills, only various subcategories (from appropriate places).
 * Skills
 * Skills by type (skills of type "skill" go directly in here)
 * Spells
 * Enchantment Spells
 * Hex Spells
 * Skills by profession (professionless skills go directly in here)
 * Monk skills (attributeless Monk skills go directly in here)
 * Divine Favor skills
 * Skills by campaign (campaignless skills go directly in here)
 * Prophecies skills (professionless Prophecies skills, not that there are any, go directly in here)
 * Monk skills (Prophecies)
 * Elite skills
 * Special skills
 * Skill stubs
 * Skill sub-classes
 * Elite skills
 * Special skills
 * Skill stubs
 * Skill sub-classes
 * Skill stubs
 * Skill sub-classes

Category:Skill types goes somewhere else since it doesn't contain skills. Right now it's in skills by type, I think. The above organization makes each "Skills by X" subcategory tree contain exactly the same leaf articles: each skill once. Right now "by profession" is sort of doubled up, which confused me. Category:Skill sub-classes isn't a bad idea, but some of the choices are strange. Grouping together by our own external classification is good. I think a name that better indicates this would be a good idea, though I can't think of one. But "mantras" is useless. "Storms" is okay but the name isn't really helpful unless you already know what the skills share in common. I'd rather call it "DoT, AoE spells" or something. --Fyren 23:55, 21 September 2006 (CDT)

Skill/Attribute bar
The current combination of and  to show a build combines two different looking tables and stacks them on top of each other resulting in an ugly presentation. Example. I've been working on a combined table to get around that and the use of two different templates for builds. See User:Chuiu/Skill bar for the format and an example. I propose we use this template for whenever there is a need to show both the attributes and skills and keep the current two templates intact for other uses (like showing alternate attribute distributions or skillsets for builds). The only problems with the template I setup is that it extends past 800x600 resolution. I don't see that as a problem though since most of the pages that use a skill or attribute bar look horrible with overlapping tables in 800x600 anyway. (T/C) 21:53, 21 September 2006 (CDT)
 * They can be in the same template and be different tables. I think they look better separate so there's not a ton of empty space for the attributes.  (Also, GuildWiki talk:Style and formatting/Builds.)  --Fyren 22:02, 21 September 2006 (CDT)
 * I'm not against combining into one template; but I think the current multi-template / multi-table appearance is cleaner and better looking that the new proposed combined version. Too much empty space and ugly dotted lines everywhere in the new one. --- Barek (talk • contribs) - 22:20, 21 September 2006 (CDT)

Section 0
I added a note saying section 0 of an article should contain intro matter. I went through and did quick/dirty changes to the S&F pages that had a == General == or == Description == as what should begin an article to remove the headings. But in general the S&F are woefully out of date anyway. --Fyren 07:55, 10 October 2006 (CDT)
 * You pointed Rainith to this talk page, but you haven't explained why an article should not begin with a section heading? I know Wikipedia encourages the presence of a leading section. But I think the General/Description section more appropriately provides that. On pages with a long table of content, that lead section at the top just makes the page look weird (imho).
 * Having a lead section was never part of any s&f, so being outdated doesn't really matter. The s&f pages are not woefully out of date. Do check the date for the NPC s&f and check the NPC articles. I'm also still awaiting feedback for the Towns s&f. -- Ab.Er.Rant (msg Aberrant80) 20:28, 10 October 2006 (CDT)
 * MW and WP are tied together in some ways since the main goal of MW development is to support WP. In this case, that's how they designed it to work weven if the root is in WP's style choice.  The software is designed such that intro text is supposed to be at the top, followed by the TOC, and then the rest of the article.
 * Stylistically and organizationally, given how MW displays headings and articles, I think this is the correct choice (especially compared to the alternative of a section beginning an article). In the context of this being a guide (or a reference, or an encyclopedia, or whatever), pages aren't floating in limbo.  They're meant to be liberally interlinked.  The topmost level heading of an article is really the title.  It's there on every page and has the horizontal rule that accompanies "normal" headings.  That's why we use second level headings and not first level headings for everything.  Adding a "general," "introduction," or "description" header is a waste of space (gap between the title's horizontal rule and the heading) and useless (is someone going to get confused if the heading isn't there? does the heading help organize anything?).  --Fyren 21:49, 10 October 2006 (CDT)

In reply to Abberant above: about being outdated, most of them are. --Fyren 21:49, 10 October 2006 (CDT)
 * NPCs, builds, materials: They're fine.  NPCs are mostly due to your own large effort in going through all the articles and applying the existing S&F.  Builds is the same but through the effort of many editors.  Materials also match, though they're also probably one of the smallest set of articles.
 * Bestiary: Looking through a random selection of bestiary articles, while they often share the same order, headings are often arranged differently so some sections are subsections while in the S&F they're all second level headings. There's no mention of how to display drop rate data.  There's no S&F describing how to layout species pages even though we have a ton of very old species pages.
 * Items: No mention of collector sections for collectable drops. Mentions there are only four images for salvage items, which has been out of date since the Factions PvE preview (or at least since Factions).  There's not really much to say in the S&F I guess, since most items fall under the other, more specific types.
 * Armor: I don't want to say these are useless since they do describe the templates, but otherwise they are. If I wanted to make a new armor page, the only way I'd figure it out is looking at the mesmer armor page and styling it after that.
 * Weapons: A ton of weapons are missing sections. This is either because they're actually optional or because no one has bothered adding hem (perhaps a problem for "boring" items like Wooden Buckler).  This is still a problem, since you shouldn't write a S&F that no one wants to implement.  The item stubs category is huge.
 * Uniques: The "counterpart" heading has a zillion different names across the articles. The S&F doesn't help with picking a consistent set.  The intro line is a single sentence saying what drops the unique, which is not followed by most articles.
 * Towns: You're putting effort into this now, which is great, but a lot of the formatting (especially of the lists) varies from article to article.
 * Halls: For such a small set of articles, it's suprising the S&F doesn't match. They all use the location box template.  There's the same issue with items where lots of stuff is missing, though in this case it's more clear that no one really cares whereas for items getting the information for the non-option sections the S&F requires would be a massive undertaking.
 * Missions: Most articles don't follow the organization/headings in the S&F. This S&F has received an incredibly low number of edits given how popular the mission articles are.  It went without an edit for nine months, when someone changed it but didn't change any of the Prophecies articles to match.  A lot of Factions articles, probably written before this change, don't match it.
 * Professions: Doesn't reflect changes to our secondary profession articles. The rest is fine, at least, though I think that's mainly because the rest hasn't been touched in forever.
 * Quests: Mostly right, probably through Tetris' efforts (not to discount a lot of other people). It's lacking in describing optional sections/alternative walkthroughs as it only prescribes two sections: overview and walkthrough.
 * Skills: In flux and I plan to rewrite it after updating the skill box template. The template use is out of date and, depending how you look at it, always out of date.  Acquisition is particularly bad, since it's incredibly vague and led to a zillion different formattings across the articles.
 * General stuff: A lot of stuff doesn't obey GW:ULC. A lot of things like when to use subpages for species/quests/collectors/skill trainers, what to put in the subpages, how to format articles for trainers and collectors (as in, beyond the general NPC S&F) aren't described.
 * Okay..... so I was a bit too hasty to say that the S&F articles are not outdated :P I wonder if the main problem is that alot of editors don't read them, or don't even know they exist. While I get your point regarding the leading section, I'm also kinda dreading the fact that I might have to go through all the NPC articles again... of course, a bot might be able to do that, although it might depend on rules like how long should it be and how concise should it be. -- Ab.Er.Rant (msg Aberrant80) 00:55, 11 October 2006 (CDT)
 * Yeah, I can kill the headers with my bot pretty easily, I think. I could also run a test to see if any articles have particularly long sections.  Assuming someone doesn't come up with a good reason to leave it be.  Also, just to note, before I changed any of the S&F pages, bestiary, NPCs, towns, materials, weapons, and armor (not actually stated in the armor S&F, but the articles have them) had intro headers.  The rest either didn't or don't have intro text (missions, quests, and skills).  I don't think most editors want to read through a page larger than the one they're trying to create to figure out what to do.  This is okay as long as someone else will do it.  But if no one is willing, we should relax the S&F.  --Fyren 01:12, 11 October 2006 (CDT)
 * Good point about the length of the S&F. Maybe I should try and trim the NPC S&F. This kinda makes the template really important. We have to squeeze as much important conventions/style/guidelines/information into the template as possible then. -- Ab.Er.Rant (msg Aberrant80) 01:20, 11 October 2006 (CDT)

This might be trivial, but personally, I hate Style and formatting for its ridiculously long title. Have you ever written Style and formatting/Guild Halls for a link somewhere? I have not, and maybe that is part of why it is poorly linked/watched. Another fact is that most users will simply copy a good looking example when making a new page, so it is very important that early examples of articles in a section follow the S&F.

Additionally, I dont see why sections with a small number of articles need a S&F at all. Why should there be one for guild halls, when everyone making a GH article will have a look at the others and make the article comparable for sure? --Xeeron 06:25, 11 October 2006 (CDT)


 * While the main reason for having documentation is so that people can see how they should create articles on certain subjects, it is also there to settle disputes. If we did not have a style and formatting area (as we didn't in the earliest days of the wiki) then there can be misunderstanding as to what articles should look like. The main reason it was started was because there was some confusion when users started submitting the original skill articles, i.e. inconsistencies in the skill box including changing the colours of it for each profession.  &lt;LordBiro&gt;/&lt;Talk&gt; 11:53, 11 October 2006 (CDT)

Any resolution on this? If there's an agreement on removing the "General" header, how should we treat some of the NPC pages where there are more than 1 "General" header? Most notably, some of the henchmen pages, where we have a section "as NPC" and another "as henchmen". We'll need an additional summary paragraph then. -- Ab.Er.Rant (msg Aberrant80) 20:33, 15 October 2006 (CDT)
 * The intro for that case should be general enough to cover all topics. If there's a == As Henchman == (or whatever), then just remove the h3 "general" header and leave that text under the h2 header.  For Cynn (for example), it's really already like that, just missing a single sentence or two at the top to show up before the TOC.  --Fyren 20:45, 15 October 2006 (CDT)