RuneScape Wiki
Register
Advertisement
Forums: Yew Grove > Addition of explicit guidelines to RS:STYLE
Archive
This page or section is an archive.
Please do not edit the contents of this page.
This thread was archived on 6 April 2015 by Cqm.

The purpose of this topic is to create explicit guidelines to be used in the source code of articles, ranging from how to handle white-spacing and blank lines, to grouping and ordering of templates. Yes, this topic is about nitpicking, something many users will probably not care about, but no, RS:UCS is not the silver bullet here: the users that do care, do not necessarily share the same view, yet are likely to feel strongly about their own opinion or their own view on what this 'implicit' standard is. A proper set of guidelines that have been discussed and are included in RS:STYLE can avoid things turning into a nitpicking edit war.

The point of this topic is not to force all users to follow the created guidelines as if law. Users can edit articles as they always have; these guidelines serve as an agreed to set of rules to follow for those who will nitpick.

I start this topic with 'my' stance on the various points I would like explicit guidelines for. This stance is what I believe to be the current implicit standard used across all articles. While I have been making changes that follow these stances, I do want to make clear that this does not imply I 'own' or necessarily invented them. I welcome other suggestions, preferably with proper argumentation why that idea would be better as the guideline to use. Feel free to suggest (or request the current status of, if any) guidelines for anything I have not (initially) provided a section for.

I am certainly not the best with words; suggesting rewordings to make this understandable as a part of RS:STYLE would be much appreciated. IP83.101.44.209 (talk) 19:10, February 9, 2015 (UTC)

Example page[]

Starting off with an example page for a full overview. I'll try to keep this up-to-date as guidelines change.

__BEHAVIOURSWITCH__
{{DISPLAYTITLE:Different title}}
{{RSC page|PARAMETER_VALUE}}
{{2007 page}}
{{Hatnote|PARAM_VAL1|PARAM_VAL2|PARAM_VAL3}}
{{Box template}}
{{HasStrategy}}
{{Official world|PARAMETER=VALUE}}
{{Infobox name
|PARAMETER = VALUE
|PARAMETER2 = VALUE1
}}
[[File:DETAIL.png|left|100px]]
[[File:CHATHEAD.png|left]]
'''Subject''' has information in lead paragraph.

__NOTOC__
==First heading==
Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua.

{| class="wikitable sortable mw-collapsible mw-collapsed"
|+ Table header
|-
! Header cell 1
! id="header2" colspan="2" style="text-align:right;" | Header cell 2
|-
| Content cell 1
| Content cell 2
|
|}

{| class="wikitable"
|+ Small table
! h1 !! h2
|-
| Cell1 ||
|}

{{Clear|left}}
==Second heading==
===Sub heading===
[[File:FILE|thumb]]
PARAGRAPH<br />
New line, same paragraph.

* Item
* Item

==Drops==
{{DropsTableHead}}
{{DropsLine|PARAMETER1=VALUE1|PARAMETER2=VALUE2}}
{{DropsTableBottom}}
<references group="d" />

==Trivia==
* Trivia
{{WP also}}

==References==
{{Reflist}}

{{Navbox}}
{{DEFAULTSORT:Key}}
[[zxx:lang link]]
[[Category:CATEGORY]]

For disambig pages:

'''TERM''' may refer to:

* Item
* Item

{{Disambig}}

White-spacing[]

Trailing spaces[]

Do not allow trailing spaces at the end of lines/paragraphs, with the exception of a single trailing space following the '=' of a parameter without a value in a block-style template.

Multiple spaces[]

Only a single space should be used between the end of one sentence and the beginning of the next.

Styling/tags[]

There should be no spaces between text styling wiki syntax elements or HTML tags and their content. If the styling only surrounds a fraction of a full block, spaces should be on the outside of the styling. Use:

This is '''bold''' and <span style="color:red;">red</span>.

instead of:

This is '''bold '''and<span style="color:red;"> red</span>.

Line break tags[]

When <br /> tags are used, they should not be surrounded by spaces, but immediately follow/precede the content that is broken into two lines. When used in a paragraph, the tag should be followed by an actual new line.

Templates[]

Inline[]

Inline templates should not have spaces between the pipe ('|') symbol and the parameter name (or value), nor before or after the '=' sign.

{{DropsLine|PARAMETER1=VALUE1|PARAMETER2=VALUE2}}
{{Otheruses|PARAM_VAL1|PARAM_VAL2|PARAM_VAL3}}

Note: currently the Cite-templates do not seem to follow this rule; they all have an additional space between the VALUE and the next pipe.

Block[]

Block templates should have each parameter on a new line, with no space between the pipe symbol and the parameter name or value. The '=' symbol should be surrounded by a single space on each side. The final '}}' should be on a separate line.

{{Infobox Item
|PARAMETER = VALUE
|PARAMETER2 = VALUE1
}}

List[]

There should be a single space between a list character (* or #) and the content of that list item.

* List1
* List2

Section headers[]

There should be no spaces between the '=' signs used as wiki syntax for the section headers and the content of the header.

==HEADER==

Blank lines[]

General[]

Paragraphs should only be separated by a single blank line; if for some formatting reason a wider gap is required, use the {{Clear}} template as necessary. The clear template should be on its own line. Example:

Paragraph 1

{{Clear}}
Paragraph 2

If the formatting issue is caused by a right-floating element (such as an infobox), the clear template should generally have the value right; for left-floating elements (like chatheads), left.

A section header should always be preceded by a blank line, except if the previous line with content is another section header, or if the previous line is a {{Clear}} for formatting purposes (and is preceded by a blank line). A section header should never be followed by a blank line. As with the detail and chathead images just after an infobox, if the first line after a section header is a (group of) file(s), or a simple text-template such as {{Main}}, it should not be followed by a blank line before the next paragraph.

There should be no blank line between a <references /> tag and its preceding table, if applicable; nor between the last trivia bullet and a {{WP also}} template.

Language links and categories should not be separated by blank lines. They should also follow the last content part of the article without any blank lines separating them, regardless of what that last bit of content is (text, list, table, template, ...).

Template grouping[]

There should be no blank line between the 'header templates', the infobox, and the first paragraph. 'Header templates' is what I call the grouping of all templates that are generally put at the very top of an article (rsc/07scape links, otheruses, strategy, dual wield, ...). There should be no blank lines between navboxes, nor between templates that belong together (such as drop table templates). Reflist tags should be separated by a blank line from following navboxes, even if they are not preceded by their own section header.

Lists[]

Lists should be followed by a blank line. On disambig pages the listing should always be preceded by a blank line.

Orders[]

Special tags[]

DISPLAYTITLE should be placed at the very top of the page, prior to any actual article content. At the bottom of the page DEFAULTSORT should be placed just prior to any language links (or categories). In both cases no blank lines should precede or follow these tags, and each tag should be placed on its own line. __NOTOC__ should be placed before the first section header, without a blank line in between them. All other behaviour switch magic words should be at the top of the page before DISPLAYTITLE; however, this should almost never occur.

Template order[]

The number of 'header templates' has grown. Generally only one or two are used on an article, but there are cases when several of these are applicable. The following order should be followed, and each template should start on a new line:

{{RSC page}}
{{2007 page}}
<<Templates that redirect away from the current page: otheruses, redirect, dual wield, lucky variant, ...>>
<<Box templates that are about the current article: rare item, hasstrategy, holiday, ...>>
<<Remaining templates about the current article that generally are simple (italics) text: official world, ...>>

Detail/chathead[]

The detail image of an article should come first, after the infobox, followed by the chathead image (either only if applicable of course), and the first paragraph. Both of these should be left-floating elements.

Tables[]

In normal articles tables should always be created using the wiki syntax, and not using HTML tags. In other namespaces (specifically Template: and Module:) it might be required to use the HTML tags instead.

Except for very simple tables, multi-line row formatting should be preferred, where each cell starts on its own line.

Formatting[]

Tables in mainspace articles should always have the class "wikitable", unless there is a specific reason why this is omitted. CSS classes for tables should be placed in the following order:
wikitable, sortable, lighttable, mw-collapsible, mw-collapsible-collapsed/uncollapsed

If present, the table header should be the first thing following the table opening.

The order that should be used for any style and attributes applied to a table, cell or row is:
id, class, rowspan, colspan, style

White-spacing[]

A space should be placed between each table syntax element and table content, styling, and attributes. Empty cells should not contain anything, even a space, with the exception of an empty cell in the single-line row formatting as long as this is not the last cell of the row. In this case a single space should separate both cell boundary syntax elements.

Below are examples of the expected placement of white-spacing in both formats.

Single-line row[]

{| class="wikitable"
! Small table h1 !! h2
|-
| Cell1 ||
|}

Multi-line row[]

{| class="wikitable"
|+ Table header
|-
! Header cell 1
! id="header2" colspan="2" | Header cell 2
|-
| Content cell 1
| Content cell 2
|
|}

HTML[]

Unless this turns into a fight with the visual editor (of which I am not sure), strict XHTML should be used in preference to older HTML. For example, prefer '<br />' to '<br>'. This also implies:

  • Surround all attribute values by double quotation marks: use '<references name="g" />' instead of '<references name=g />'
  • Separate attribute values by a space, but do not put a space around the '=' between attributes and their values: '<references name="g" group="d" />' instead of '<references name="g"group = "d" />'
  • Style attributes should contain no spaces surrounding the ':' between the style's tag and its value. Each style tag+value combination should be terminated by a ';', even if there is only a single pair, and a space should separate multiple tag+value combinations: '<span style="color:red; background:yellow;">' instead of '<span style="color : red;background: yellow">'
  • There should be no space between the last part of a tag and the closing '>', except in the case of a self-closing tag. For self-closing tags, a single space should precede the '/>'.

Prefer using CSS over deprecated HTML tags such as <u>...</u>, except when appropriate wiki syntax elements exist (such as '''BOLD'''). Notable exceptions are: the sup and sub tags.

Number formatting[]

Always include thousand separators in any numbers above 999 (and below -999), with the exception of in the year of a date (be it a real date or an ingame lore date) and for numbers that are template parameter values, which the template will automatically format (convert value of an Infobox Item, quantity of a DropsLine).

Image captions[]

I couldn't find this mentioned in RS:STYLE nor RS:IMG, but non-thumbnail/framed images should not contain a caption. Use:

[[File:Fire rune detail.png|left]]

instead of:

[[File:Fire rune detail.png|left|A detailed image of a fire rune]]

Disambiguation pages[]

Disambiguation pages should begin with

'''Term''' may refer to:

And each item listed should be part of an unordered list (*). Each item may stand alone or have a short sentence fragment following it. If a term is disambiguated in the title, it may have the parenthetical removed via pipe link; however, this will require it to have a description. For example:

'''Harry''' may refer to:

* [[Harry]]
* [[Harry (Falador)|Harry]], a man in Falador
* [[Harry (Slayer master)]]

{{Disambig}}

Information presented in the description should be kept to a bare minimum (remember: these are not actual articles; they are navigational tools), and should only be just enough to direct a reader to the correct article. For the same reason, links should be used extremely sparingly. "Harry, a man in Falador" is preferred over "Harry, a man in Falador".

For pages with more than several items, the list may be split into sections. Short pages may use fake section headings (by starting the line with a ";"); longer pages should use proper, level-3 headers (===).

Points of discussion[]

Some points I have not seen a consistent answer on, which perhaps could use one as well.

WP also[]

Should WP also templates be placed at the start or end of the trivia sections? If placed at the bottom, they will generally take up additional height.

The bottom. The additional height is very little in a relatively insignificant part of the article. It outweighs the clunkiness that could be caused by having it at the start. MolMan 12:59, February 20, 2015 (UTC)

Infobox bonuses[]

Should requirements be separated by commas or not? Should captions end with a full stop or not? 'Yes' and 'No' respectively in my opinion.

No, they have images that delimit them well enough. Captions should follow proper English rules. "A played wearing ___" is not a complete sentence, so it should not get a period. "This image is a player wearing ___." however weird it may be, is a complete sentence, and should get a period. MolMan 12:59, February 20, 2015 (UTC)

Language links[]

Put each language link on a separate line, or group them all into a single line, without any linebreaks?

Preferably separate lines for easier parsing should it ever be needed. Though this will be a fight with visual editor. MolMan 12:59, February 20, 2015 (UTC)

Lists[]

Should lists always or never (aside from disambig pages) be preceded by a blank line?

This should be case by case. MolMan 12:59, February 20, 2015 (UTC)

Specific template order[]

If anyone has a suggestion for a defined order of the box 'header templates', I would welcome it (e.g. first rare item, followed by safe minigame, hasstrategy, and has money making guide).

Hat notes (those that are relatively unstyled, simple, one-liner things like Template:Otheruses) should go before the boxier templates. MolMan 12:59, February 20, 2015 (UTC)

Navboxes[]

What could be a consistent order for navboxes? Smallest first? "Most specific" navbox first? Specifically in regards to items that are on both Quest navboxes as well as other grouping ones, which should come first? (E.g. should "Experience lamp" or "Heart of Stone" come first on Runecrafting lamp?) On a quest page, should that quest's navbox come first, or the navbox linking all quests in the series, or the navbox grouping all F2P quests? (And so on, and so on...)

Gaz covered below the relevance test. If an item is "equally relevant", use the smaller one first. MolMan 12:59, February 20, 2015 (UTC)

Discussion[]

most of this is lolboring - DEFAULTSORT goes at the bottom with categories because that's what it's for. DISPLAYTITLE goes at the top, because that's where titles are. NOTOC should be before the first section header. NOWYSIWYG should go at the top.

Captions for not just infobox bonuses, but everything should follow proper English rules. If it isn't a sentence, it doesn't get a period.

4 digit numbers don't really need a comma unless they are in a context that tends to require commas (such as being output with commas by any template), or are with other, larger numbers that do need a comma.

Images like DIIs and icons don't need a caption. Captions can still find use on non frame images, but it's much less common.

Everything else is stupidly nitpicky, and I don't see how anyone could care. It'd be helpful for everyone if those-people-who-know-who-they-are would stop being so anal about whitespace. It annoys people and it's close to unproductive. MolMan 19:22, February 9, 2015 (UTC)

all of this is my opinion - Since tables weren't mentioned, here's my take on them:

  • Wiki-style tables (using {| |- ! | |}) - as opposed to (X)HTML tables (<table> <tr> <th> <td> et al [and relevant closing tags]) - should be used on pages for source readability, unless there's a reason why wiki-style tables cannot be used (e.g. some interaction with a Lua template - though such uses should be wrapped). Obviously does not apply to what's used within a template.
  • Except for very simple tables, multiple-line row format is preferred.
  • Use a single space between each the cell opening | and the content.
    • If single-line row format is used, a single space should be placed before and after the content of a cell, though there needn't be after the last cell's content (| a || b || c rather than |a||b||c).
    • If attributes are applied to the cell, there should be a space between each attribute group, and between the last group and the |.
    • Intentionally empty cells should be empty (i.e. |<linebreak>) in multiple-line format, and contain one space in single-line format (except for the final cell of a row, which is empty - i.e. | ||), unless there is a specific reason why not.
  • Table captions should appear immediately after the table opening, and not used as a row boundary. i.e.:
{|
|+ hi
!header
|-
|content
|}

and not

{|
!header
|+ hi
|content
|}
  • class="wikitable" is preferred for the vast majority of tables. Tables without this class should have a good reason.
    • In collapsible and/or sortable tables, wikitable should come first [optional expansion: followed by sortable, then mw-collapsible and finally the default-forced state (mw-collapsible-collapsed/uncollapsed)]
  • When used, rowspan and colspan should come before any style used for the cell, but after id and class.

Other stuff:

  • Tags and attributes (most of these can also apply to usage of attributes in templates but that's less of a concern)
    • In general, CSS styles should be used over tags that give the same result (e.g. font-size:120%; over <big></big>; text-decoration:underline; over <u></u>; etc). Some exceptions are bold and italics (using '), sup/sub, etc. Mostly just follows deprecation, to be honest.
    • Attributes for various tags (including tables) should be separated from each other by a single space, but within the attribute there shouldn't be a space between the name, the = and the value.
    • Attribute values should always be quoted (even when it is valid to not do so).
    • The style attribute's rules should have no space between the style name, the :, the value and the ;, but there should be a space between the ; and the next rule. The final rule in a style attribute should end with a ; (even if it is the only rule of the style attribute).
    • There shouldn't be a space between the final attribute's closing " and the > closing the tag (with the exception of tables, which have a space between the final " and the |)
    • For a general order, id should come first, then class; style should come last. As mentioned, rowspan/colspan should come before style, but after id and class. (My idea is: id and class are 'most important' so go first; they're also usually short (id being only one 'word' and there rarely being more than 2 or 3 classes for a tag), whereas span is often the longest so goes at the end. I don't know why I prefer this way; row/colspan debatable)
    • Unless needed for some reason, there shouldn't be any spaces between the > of the opening tag and the content of a tag, nor between the content and the < of the closing tag.
    • eg:
      <span title="hi" style="color:red; background:green;">hello</span>
  • Speaking of title... (though maybe this is a different discussion?)
    • The title attribute should be used rarely, and when it is, it should be made fairly obvious that a hover text exists. In tables this can be a 'hover x for info', and in-line I like to use style="border-bottom:1px black dotted;", sometimes also with cursor:help; - maybe make a proper class? Whatever. (example: Boss pets, notes for first table)

Various discussion point responses:

  • I'd say the reason for citation templates having spaces is for readability - they're best off in-line (otherwise it can disrupt the readability of the source of a paragraph, as they can be in the middle), but the template usage is often long (especially with longer URLs, a quote and much of the other parameters filled out), thus spaces help them out.
  • Navboxes, I think each is mostly a case-by-case decision, but generally in order of most to least specific - but also taking account of how prominent the article is in the box:
    • for example, Dagannoth Prime, at time of writing, has {{Dag Kings}}, {{Soul Reaper}} and {{Dagannoth}}; I would say the order should be Dag Kings, Dagannoth, Soul Reaper: Prime, as a dagannoth king, is most important in the Dag King box; he's also a dagannoth, but lumped with the other dagannoth bosses in the Dagannoth box, and finally he's a Soul Reaper assignment along with a bunch of other bosses, so he's least important to that box.
    • for the mentioned Runecrafting lamp, {{Heart of Stone}} then {{Experience lamp}} - as (part of) the reward, the lamp is more important to the quest box than it is to the very large lamp box (as shown by the font size and relative ease of finding it).
    • for quests, the quest's specific navbox should come first, then the series, then the global quest box; since the quest is most important to its own navbox (being as its the title), then its pretty important to the series navbox, and least important to the global quest box.
  • Lists, I tend to not have a blank line before them; but I also try to avoid having more than one sentence in the preceding paragraph.
  • I don't have a comment on messagebox/header template order at the moment
  • Mol covered special tags

Weird gloop @Gaz#7521 00:12, February 10, 2015 (UTC)

I will try and incorporate both your and Mol's answers so far into the top of this topic. I had indeed not given thought to tables or other HTML attributes, and have found no reason to disagree with the choices at this time for a standard. One question and a note regarding your feedback:
  • "If attributes are applied to the cell, there should be a space between each attribute group, and between the last group and the |."
    • This doesn't mention whether a space should be present before the attributes and the cell opening pipe; preferring | rowspan="2" | content to |rowspan="2" | content. I will expand the statement to include this.
  • I assume your table header example focusses on the table header part; as it does not conform to the earlier guideline of having a space between the cell opening (| or !) and its content.
IP83.101.44.209 (talk) 05:14, February 10, 2015 (UTC)
I tried summarising your points and adding them to the proposal. Perhaps a few things are not as specific as they should be, in that case I could add your exact cases and wording if preferred. If I missed anything, my apologies. Point them out and I'll get to correcting that.
I've not yet altered the points on blank lines before lists, navbox order and HTML title attributes until there has been some more discussion on them (or this topic dies a silent death).
The list definition of references is something that I could consider very useful. It would make finding the definition of a specific reference much easier, and keep the source code more readable; but can it be combined with the {{Reflist}} template that is used (as far as I know it provides some additional formatting)? Or will the placement of the block references tag define where the references are placed in the article as well? IP83.101.44.209 (talk) 17:45, February 10, 2015 (UTC)
Yes, both points you're right on what I meant. A fairly small change to the reflist template makes that doable: examples and template (check src for what's going on). Weird gloop @Gaz#7521 18:40, February 10, 2015 (UTC)
That reflist variant looks very interesting. I'd suggest adding a guideline to use that style at least for all reference-heavy articles, but I wonder if it'd be worth making it a general standard for all references? If it would become a general standard, I am still undecided as to whether it should also be applied to references used as notes in (drop/calculator/...) tables or if those should be an exception. If no exception, the template should support the inclusion of a 'group' attribute. IP83.101.44.209 (talk) 19:06, February 10, 2015 (UTC)
I amended my template and examples with grouping (both edits c/o wikipedia:Template:Reflist). (Probably worth updating all citation templates that have a ref tag built-in to include grouping, but that's mostly unrelated to this.) For normal references (citation templates or otherwise), it should definitely be with reflist; for notes on stuff, less necessary but I'm leaning toward 'it should use reflist too', but not that strongly. Weird gloop @Gaz#7521 15:54, February 11, 2015 (UTC)

Comment - I have a few specific comments, but I'll preface them by saying that most of the content here is overboard on microscopic detail. The wiki has style guidelines, not style laws. Imposing rigidity on most people encourages them to have contempt for rules (all rules, not just the silly ones), not to embrace them. Once upon a time, CBlair and his bot attempted to enforce certain formatting rules unilaterally. Eventually he pissed off enough people on enough wikis that he got himself globally banned. Or perhaps I should say he pissed off the wrong people. He pissed off a lot of people for a long time before anything happened.

  • MediaWiki always inserts a blank line following a section header whenever making a new section via the "new section" link at the tops of pages. I know you re-edit an article whenever anyone adds a new section to remove the blank line, but you're fighting MediaWiki software on this one.
  • Blocks and lists can/should use spaces (even multiple spaces) in raw wiki mark-up lines to improve their readability by humans. The argument has been made (during the CBlair stuff) that, while raw mark-up isn't code, it's very much like code. I didn't make the argument, but I agree with it.
  • Single-line table rows are more readable and maintainable for a similar reason. Raw text isn't WYSIWYG, but a table that looks like a table in raw mark-up is easier to maintain, especially if editors can fit a larger portion of the table on their screens while editing. The reason to go with multi-line rows would be if the cell content is long, like a complex expression, a paragraph of text, or a list of points.
  • Having spaces in tables after pipes makes sense because MediaWiki reserves the character after the pipe for a special meaning, so +, -, }, and space are the options for header caption, row-break, table end, or content. However, no row-break is required, nor should be enforced by policy, before the first row. MediaWiki documents such row-breaks as optional, but none of the MediaWiki developers use it in their documentation.

HTH --User:Saftzie/Signature 22:27, February 13, 2015 (UTC)

Just to be sure, you are proposing:
  • The block-template style to use padding with spaces between the parameter name and the '=', such that all '=' line up for readability
  • Lists to have a space between the '*' and '#' characters and the content of that list item
And are agreeing with the current spacing guidelines for tables, albeit without having a preference to the multi-line row styling.
As for your first note, the intention of this topic is to add this to RS:STYLE as guidelines, not as a policy. Average users will likely not even know about these or even care for them, and I have no intention of these being forced on users. The point is to get a common ground to avoid fighting for those who do nitpick. IP83.101.44.209 (talk) 04:57, February 14, 2015 (UTC)
That's the problem. It creates a global standard to please 1 or 2 people about stuff that doesn't even matter. I already know offhand two cases of people vocalizing how annoying you are with this. Making it an official guideline will just make things worse by validating these useless edits. MolMan 12:24, February 14, 2015 (UTC)
If you, or they, want to properly discuss my edits, sure, but I do not believe that should be part of this topic (other than perhaps as an argument to oppose the proposition). IP83.101.44.209 (talk) 15:42, February 14, 2015 (UTC)
I'm actually not proposing anything additional. I'm suggesting not including such detail in the policy, because different contexts and content may work better different ways in different places. However, I am also suggesting
{| class="wikitable"
|+ Table header
|-
! Header cell 1
! id="header2" colspan="2" | Header cell 2
|-
| Content cell 1
| Content cell 2
|
|}

becomes, if anything,

{| class="wikitable"
|+ Table header
! Header cell 1
! id="header2" colspan="2" | Header cell 2
|-
| Content cell 1
| Content cell 2
|
|}
I can easily see a future forum thread to yank all/most of this stuff out if it gets in. A better approach might be to take each point one at a time. "Should we add NOWYSIWYG to every page" is a big enough impact all by itself. --User:Saftzie/Signature 23:18, February 14, 2015 (UTC)
(NOWYSIWYG won't be allowed on every page because it interferes with the visual editor which Wikia considers a core part of their wikis) I assume that's just a hypothetical. MolMan 23:20, February 14, 2015 (UTC)
My 'example page' at the top is meant as a reference to put the notes below into a context. Only the bits and pieces that are actually applicable to a certain article should be in that article. I'm not proposing to add NOWYSIWYG (or NOTOC, ...) to every page.
I remember that a while ago for a short period, the visual editor started adding extra blank lines after every "{| class="wikitable"" if the next line was not a "|-"; I'm unsure how that interacted with tables with headers, but perhaps that one should be included as well? IP83.101.44.209 (talk) 05:01, February 15, 2015 (UTC)
Not that I'm privy to the reasoning behind global blocks, but given what else he did leading up to that block I very much doubt his bot's actions here were anything to do with it. User:Cqm/Signature

Update - Added an exception to the trailing spaces guideline: a single space should follow the '=' of a parameter in a block-style template, regardless of whether it has a value (and thus makes that space trailing). IP83.101.44.209 (talk) 04:55, February 19, 2015 (UTC)

This is the kind of stuff that literally does not matter. MolMan 13:02, February 19, 2015 (UTC)
In the cases so far where this space isn't present when a value is added to the parameter, most non-active contributors will just add the value, without the separating space. If the space is already there, the end result will automatically comply with the proposed styling for block-style templates. And as the guidelines are meant to be exact, the exception should be noted. IP83.101.44.209 (talk) 16:24, February 19, 2015 (UTC)
Again. Literally does not matter. Guidelines, strict and binding or not, should never be this anal. Not for stuff like this. It's going to annoy so many more editors than it would please. MolMan 16:27, February 19, 2015 (UTC)

Comment - Whilst I'm sure most of this has good intentions, I don't think it's really worth having when you realise the Visual Editor is never going to comply with the guidelines we set. I'd much rather have no guidelines, but allow editors to make small alterations if something is obviously messed up, e.g. table row templates being merged into a single line. I'd disallow editors raising 'issues' because something doesn't conform with what they think it should be due to minor infractions.

Some of the points, such as multiple spaces, are completely pointless. As multiple spaces are ignored by the parser, it makes no difference if they're there in terms of the reading experience. __NOWYSIWYG__ is also pointless as CKEditor is eventually being phased out in favour of VE (which doesn't recognise the tag).

Can we just allow people to write content unharassed and clean up source code as we go? I don't think it's enough of a problem to warrant this many guidelines. User:Cqm/Signature

The aim here is not to force all/average users to comply to the guidelines (not 'policies'). If a user makes an edit, and as a result of that the Visual Editor changes part of the source code, so be it. There are a few users, amongst which myself, that will make the nitpicky edits part of 'cleaning up source code'; however, their view are not always the same on certain points, which could cause friction or possibly some form of edit warring. The goal of this topic is to discuss and eventually provide common ground that this group of people can adhere to when making such edits. IP83.101.44.209 (talk) 16:24, February 19, 2015 (UTC)
Could all of this not be resolved by not making those nitpicky edits in the first place? Thing like what order table classes should be makes no difference at the end of the day. I'm sure we can all find better things to be doing. User:Cqm/Signature
As mentioned before, if you want to properly discuss my edits, I don't mind, but this topic does not seem the appropriate place to divert to that. In any case, to me, these nitpicky edits are just 'what I do': I see something that does not conform to the standard I've seen, and change it. They do not take effort, and are a part of "me browsing RecentChanges" rather than being part of some project of mine to actively edit every single article to make it conform. I cannot speak for the driving force behind other users' edits, however. IP83.101.44.209 (talk) 17:24, February 19, 2015 (UTC)
The point is your edits (and everyone who goes into a page just to make these kinds of changes) are absolutely useless. And no one wants to make amendments to guidelines that encourage or validate them. Unfortunately, we can't make you stop, but we can still oppose something that effectively gives meaning to your activity. MolMan 17:29, February 19, 2015 (UTC)
Perhaps adding the guidelines could be seen as "encouraging these kind of edits", but as I've stated, the main reason for them is to have a common ground to avoid bickering for those who do/will regardless. Adding or not adding these guidelines will not increase nor diminish the amount of meaning I consider these edits to have. IP83.101.44.209 (talk) 17:36, February 19, 2015 (UTC)
In the end, I think it might be more helpful to allow the bickering to continue and see some 3RR blocks. MolMan 17:38, February 19, 2015 (UTC)
So you propose a solution that will eventually cause people to run into policies, as opposed to a solution that will avoid conflict? IP83.101.44.209 (talk) 17:40, February 19, 2015 (UTC)

┌───────────────────┘
As it happens, I don't object to you making this kind of edit; I vastly prefer editing wikitext that is nicely formatted over wikitext that isn't. I even make some of the mentioned formatting whilst editing a page just because it annoys me as I'm changing other things. But I've never found myself in a position where formatting text has caused even so much as a question on my talk page, let alone the need for all this. I have no intention of taking issue with your contributions, but perhaps if you find yourself changing something that parses exactly the same whether you changed it or not ask yourself if the edit really needs to be made? I'd rather not end up blocking someone, whether that's you or someone else, over something as minor as this. User:Cqm/Signature

I understand what IP is saying completely. As some who also makes small simple style edits, it should be uniform. I noticed that IP has reverted some of my edits, where I may not have followed the style guide 100%, but the wiki should be visually correct, not only with grammar, but style. I don't mind if IP corrects me, but his point to make a uniform standard make sense, so the person who it does bother can be shown the correct style. 16px‎AtlandyBeer 02:08, February 20, 2015 (UTC)
In that case, how about adding this as a subpage of RS:STYLE, e.g. RuneScape:Style guide/Formatting (RS:FORMAT), with a clear notice that these are simply guidelines for formatting wikitext? Additionally, I'd like to see something to make users aware that the VE may or may not follow these guidelines and thus may changes the formatting depending on what it's designed to do. In an ideal world, we'd update these guidelines to follow what the VE does when we notice it in order to minimise confusion. User:Cqm/Signature
Sounds like a good idea. I will add said disclaimers when I reword all of the above to make it suitable (and understandable) for the new article [assuming this proposal passes]. IP83.101.44.209 (talk) 12:24, February 20, 2015 (UTC)

A THING - I've added a section on disambiguation pages that sums up their style guidelines (or rather what they should be). It's a lot less my opinion, and more similar to guidelines used by Wikipedia, for example. Basically no links, short descriptions. I'm attaching it the same way any bill gets passed in the American government. MolMan 12:48, February 20, 2015 (UTC)

Thanks for this and the other rewording you did. Just to make it explicit, you also changed lists to have a space after the list-character. I can be fine with that as a standard (just adding it as a comment here as to not sweep the change under the rug). IP83.101.44.209 (talk) 13:01, February 20, 2015 (UTC)
I'm making several changes section by section that I was going to make note of at the end. Anyone who wants to see can check the history. MolMan 13:04, February 20, 2015 (UTC)

Comment - Have the guidelines been finalised yet, or are there planned changes to be made in the near future? User:Cqm/Signature

I don't have anything pending. IP83.101.44.209 (talk) 10:13, March 5, 2015 (UTC)

Closed - The guidelines page may be created. User:Cqm/Signature

Advertisement