Topic on Talk:Talk pages project/Replying/Flow

Geraki (talkcontribs)

The current function assumes that there are no blank lines between replies. But that is not a standard. In most discussions where posts are extended to more than some phrases, users do put blank lines between replies, to make them distinguish both in read and in source editing. Let's assume that someone is not using the tool and tries to edit the whole section and imagine that those replies are more than a couple of phrases and contain markup such as links. Impossible to read and reply.

But it is not more than usability and accessibility thing, it is also technical:

If there is a blank line before a reply (R1) to a comment (A) when another user presses "reply" after A, their own reply (R2) is put before R1.

Also, blank lines are put between and after replies to prevent edit conflicts. They rarely happen if the posts are separated with blank lines (different blocks - merged by mediawiki itself) and if they happen they are easily resolved with the edit conflict view (and even more with Two Column Edit Conflict View).

Whatamidoing (WMF) (talkcontribs)

Hello, Geraki. See w:en:Wikipedia:Manual of Style/Accessibility#Lists for why people shouldn't be putting blank lines between replies, even if it does make it easier to read the source in the editing window. This edit shows an alternative that preserves proper HTML and accessibility while also spacing things out in the source editing window.

Geraki (talkcontribs)

But we are already abusing HTML! Years ago some of us had supported to change the parser output for the column markup from dl/dd to div but was not implemented.

Replies and generally discussions are not lists or description lists. A reply may or may not contain a list, but most times it is one or more paragraphs of text.

The colon (:) markup was widely adopted by users to be used in discussions because of its visual rendering as intented text. Much close to the use of tables for layout purposes. It has nothing to do with its semantic meaning.

Look at the example of edit you give:

<p>Post</p>
<dl><dd></dd>
<dd>Reply</dd></dl>

There is nothing semantically correct or accessible in this. In fact this way of indentation was always described in mw:Help:Formatting as a "workaround [that] may harm accessibility."

And I now see that the very same enwiki MoS guide you mention above has this warning:

As can be seen by inspecting the code sent to the browser, this results in broken HTML (i.e. it fails validation). The result is that assistive technology, such as screen readers, will announce a description list that does not exist, which is confusing for any visitor unused to Wikipedia's broken markup. This is not ideal for accessibility, semantics, or reuse, but is currently commonly used, despite the problems it causes for users of screen readers.

A related discussion is in en:Wikipedia:Village_pump_(policy)/Archive_138#RfC%3A_Accessibility_versus_convenience_in_indentation

So, the very same old question should arise: Why we don't stop using broken html? If 99.9999% of the colon markup is used for indentation and not the prescribed purpose, and there is no intention to stop using this markup/use, then change the html output.

ESanders (WMF) (talkcontribs)

Changes to the wikitext specification need to be done very slowly and carefully via the RfC process, even if it is just 0.1% of cases affected. While we are engaged in such processes to improve wikitext syntax and HTML output on discussion pages, we are proceeding within the current limitations.

From what I have seen there is not universal "standard" with regards to line breaks between comments, indeed on English Wikipedia I would say it is probably more common not to have linebreaks. No doubt whichever option we choose we will annoy the people who prefer the other option :)

> Also, blank lines are put between and after replies to prevent edit conflicts.

Fortunately the reply widget now avoids all edit conflicts by fetching the latest revision if required before posting, then repositioning your comment based the generated ID of the parent comment.

Reply to "No blank lines?"