Wikipedia:Colons and asterisks

The question 'why does it matter?' often arises when editors are discussing issues about switching from asterisks to colons in a discussion (and vice-versa). Colons and asterisks are part of our wiki-markup and are used extensively on talk pages of all types to indent comments and replies in a debate. The issue is that Wikipedia misuses lists to indent our comments. This can cause a variety of issues for those using screenreaders and other assistive technologies, as well as sometimes breaking the ways that lists render.

Mixing colons and asterisks

So why would

* I'm making a point
:: I'm replying to it

be a problem to anyone?

Well, whenever we use a colon (:) to indent, we are using 'description lists' and this code produces the following html:

: first reply

<dl><dd>first reply</dd></dl>

If we add another level of indentation we find the code produces an HTML list inside a list:

: first reply
:: second reply

<dl><dd>first reply
<dl><dd>second reply</dd></dl></dd></dl>

Now a screen reader will read out those lists as lists including each closing and opening tag. It's not too bad, as our regular screen reader users get used to it. Every additional level of indentation simply adds another list inside the preceding one (and they all get closed at the end).

Similarly, a two level list using bullet points makes use of a 'unordered lists' so the * code produces this html:

* first reply
** second reply

<ul><li>first reply
<ul><li>second reply</li></ul></li></ul>

A screen reader will cope with that as well.

But if we mix up the two different types of list, the wikiparser has to completely close the first list and then start again with a second one at the increased level, so we get this html

* first reply
:: second reply

<ul><li>first reply</li></ul>
<dl><dd><dl><dd>second reply</dd></dl></dd></dl>

A screen reader has to hear the first list being "unwound" and then the second list being "wound up" again.

If the level is greater, then the problem gets increasingly worse:

* first reply
** second reply
*** third reply
**** fourth reply
***** fifth reply
:::::: sixth reply

<ul><li>first reply
<ul><li>second reply
<ul><li>third reply
<ul><li>fourth reply
<ul><li>fifth reply</li></ul></li></ul></li></ul></li></ul></li></ul>
<dl><dd><dl><dd><dl><dd><dl><dd><dl><dd><dl><dd>sixth reply</dd></dl></dd></dl></dd></dl></dd></dl></dd></dl></dd></dl>

Just imagine you're listening to that with a screen reader, and see how much has to be read out between the fifth and sixth replies, even though it's not apparent to a sighted reader. That wouldn't happen if we kept the list style the same.

Best practices

Does that mean we can never mix list styles in a thread? No, the simple rule is that you're fine as long as you copy the style of the preceding indent and then you are free to add your own type of indent to your reply, so both

***** fifth reply
****** sixth reply

and

***** fifth reply
*****: sixth reply

don't cause the "unwinding/rewinding" issues discussed above because they can start the next list inside the previous list. Of course, the seventh reply would have to copy the style of sixth one, and then add another level of choice, but any combination of : and * is fine as long as all but the last character matches the style of the comment being replied to.

The present community-agreed guidance can be found at Wikipedia:Manual of Style/Accessibility § Lists.

Empty lines

As in articles, leaving a gap between colons- or asterisk-prefixed lines creates an issue. See the unnecessary closing and re-opening of the <dl>

: first reply
:: second reply
::: third reply

::: fourth reply

<dl><dd>first reply
<dl><dd>second reply
<dl><dd>third reply</dd></dl></dd></dl></dd></dl>
<dl><dd><dl><dd><dl><dd>fourth reply</dd></dl></dd></dl></dd></dl>

If the gap is between a colon list and an asterisk list, there is no issue, as the HTML is identical with or without the blank line. Likewise, a single-line gap between an unindented line and an indented line makes no difference. Leaving multiple lines, however, will cause the creation of an empty paragraph.

unindented line


* indented line

<p>unindented line</p>
<p><br></p>
<ul><li>indented line</li></ul>

Best practices

Don't leave gaps! If you absolutely must leave a blank line in the wikitext for some reason, the following works:

* first line<!--

-->
* second line

<ul><li>first line</li>
<li>second line</li></ul>

For bulleted lists, note that the asterisk must be placed the line after the --> in order to work as a bullet.

Multi-paragraph replies

Do not place empty lines between paragraphs, as discussed above.

When writing a comment that begins with a * (such as in an XfD) or a # (such as in an RfX), we might be tempted to do this

* first paragraph
: second paragraph

or this (noting that numbered indents are double the width of others)

# first paragraph
:: second paragraph

This also causes the winding/unwinding issue, albeit only for the innermost level. The latter example also restarts the list's numbering.

When writing two consecutive unbulleted paragraphs, prefixing both with the same number of colons avoids the worst issues, but risks confusing people that a new person's message has begun. (If you are going to do this, it doesn't make a difference if you place empty properly-indented lines in between the paragraphs; screenreaders will ignore them.)

Best practices

Instead, we can use <p> tags to create paragraphs within the list item, or use {{Paragraph break}} (shortcut {{pb}}) to create a line-break that uses the same amount of padding as a paragraph-break. (By default, <br /> and {{break}} use less padding.) Both this

* first paragraph{{pb}}second paragraph

<ul><li>first paragraph<div class="paragraphbreak"></div>second paragraph</li></ul>

and this

* first paragraph<p>second paragraph</p>

<ul><li>first paragraph<p>second paragraph</p></li></ul>

render as

• first paragraph
  second paragraph

If using <p> tags, remember to put your signature before the closing tag. If you omit the closing tag, MediaWiki will usually manage to correct it, but this sort of behavior is unpredictable and sometimes subject to change, and thus should not be relied on.

More complex cases

A similar issue arises when a bulleted comment has a bulleted list midway through this. For instance:

* Thus begins a reply. Oh look, a list!
** Item one
** Item two
** Item three
... and what goes here to continue the reply?

A single bullet will make it look like a new comment has begun. A colon will cause unwinding and then winding. The template {{invisible bullet}} (alias {{i*}}) exists to solve this problem. It creates an empty <li>, but screenreaders ignore this. Note that, unlike most similar templates, it wraps the text in question; it cannot be used as an element of its own like {{pb}}.

* Thus begins a reply. Oh look, a list!
** Item one
** Item two
** Item three
{{i*|Thus concludes the reply}}

<ul><li>Thus begins a reply. Oh look, a list!
<ul><li>Item one</li>
<li>Item two</li>
<li>Item three</li></ul></li>
<li class="mw-empty-elt"></li>
<li style="list-style:none">Thus concludes the reply</li></ul>