Note that the convention on English Wikipedia is the opposite: https://en.wikipedia.org/wiki/Wikipedia:Manual_of_Style/Accessibility#Lists. Most other projects also avoid adding blank lines (I don't have links to guidelines, but that's my impression from testing the tool on various wikis, and no one else reported this as a problem). So this would have to be some custom setting for Finnish Wikipedia.

At HTML-level it looks like this. So, with newlines, the extra margin between rendered comments comes from the margin between separate lists. However, as Whatamidoing (WMF) noted in village pump the separated lists are an accessibility problem for screenreaders etc.

So, I think it is a good idea to get rid of the newlines in future. However, the tricky part is how to add small space between comments with CSS without making the talk pages with comment separated by newlines ugly. AFAIK: We can't just remove the newlines using bots because as it will break some comments.

Without newlines

: One
:: Two
::: Three

<dl>
	<dd>One
		<dl>
			<dd>Two
				<dl>
					<dd>Three</dd>
				</dl>
			</dd>
		</dl>
	</dd>
</dl>

With newlines

: One

:: Two

::: Three

<dl>
	<dd>One</dd>
</dl>

<dl>
	<dd>
		<dl>
			<dd>Two</dd>
		</dl>
	</dd>
</dl>

<dl>
	<dd>
		<dl>
			<dd>
				<dl>
					<dd>Three</dd>
				</dl>
			</dd>
		</dl>
	</dd>
</dl>

In T265291#6537610, @Zache wrote:

However, the tricky part is how to add small space between comments with CSS without making the talk pages with comment separated by newlines ugly.

Try something like this, from the English Wikipedia's MediaWiki:Common.css.

/* Same spacing for indented and unindented paragraphs on talk pages */
.ns-talk .mw-body-content dd {
	margin-top: 0.4em;
	margin-bottom: 0.4em;
}

Thanks. It however should be able to handle cases like this too (in wikicode) where comment is splitted to multiple dd:s.

: comment 1

::comment 2
::comment 2
::comment 2

::comment 3

:::comment 4

In CSS i think this would be something that would add space between comments. Ie, this adds a little bit of space under the signature which separates the comments. However, currently, there is no class/id in the signature so they cannot be directly detected via CSS.

.dt-init-replylink-buttons {
    display: inline-block;
    margin-bottom: 0.5em;
}

We've talked about this request in the Editing team engineering meeting today, and I also investigated it a bit yesterday.

From the technical point of view, this would be possible to implement, although we're somewhat reluctant to do it:

• We agree with the concerns about accessibility (also described by @Whatamidoing-WMF at https://fi.wikipedia.org/wiki/Wikipedia:Kahvihuone_(sekalaista)#New_Beta_Feature_next_week)
• It's more complex to implement than it looks like (the replying is based on the HTML structure that @Zache presented above, rather than wikitext, so this involves producing all the wrappers in the right places instead of simply adding empty lines).

But we also want to adapt the tool to existing conventions, and we've implemented or planned other changes with this in mind (e.g. handling for "unsigned" templates, or replying using bullet list items), and this isn't that far off from that.

I think that if you had CSS code that added a visual-but-not-real blank space in the editing boxes and/or on the page, that it would probably be popular with editors at many wikis.

@Stryn: we appreciate you making us aware of this issue. As @Zache and @matmarex alluded to above [i][ii] and @Whatamidoing-WMF on-wiki, we are not comfortable knowingly writing code that disadvantages people who depend on screen readers. [iii] Read: we are not comfortable adjusting the Reply Tool's behavior such that it inserts a blank link above comment posted with it.

With the above said, we assume this blank line behavior, and the policy that specifies it [iv], is/was a response to issues Finish Wikipedians experience and it is those underlying issues we would like to understand. So, a resulting question for you: What do you understand to be the reasons that led to this policy being implemented [iv]?

Reading this comment [v] leads me to think two of those reasons could be the following:

1. It can be difficult for people reading conversations to differentiate comments from one another.
2. It can be difficult for people contributing to conversations in full page wikitext mode to do the same.

So you're aware: we've decided to delay making the Reply Tool available as a Beta Feature a week to create an opportunity for us (read: you, the Editing Team and other volunteers from the Finnish Wikipedia) to talk about this blank line behavior and for you all (volunteers from the Finnish Wikipedia) to have a conversation of your own. This is the new deployment ticket for the Finnish Wikipedia: T265446.

I commented the above on the deployment ticket here: T264693#6541327.

i. T265291#6537610
ii. T265291#6540067
iii. Please know in saying the above I am not meaning to suggest you, or anyone else at fi.wiki, is advocating a decision that disadvantages these people.
iv. https://fi.wikipedia.org/wiki/Wikipedia:Keskustelusivu#Keskustelusivun_selke%C3%A4_k%C3%A4ytt%C3%B6
v. https://w.wiki/gkJ

@ppelberg It was to make editing the wikicode easier. The original proposal was in the village pump discussion "Selkeyttävä ehdotus in 2005. It was low volume and contained only three comments. The next village pump discussion which referred to empty lines in discussions was in 2015 (Muistutus_keskustelusivukäytännöstä) when Otrfan notified that writers should follow the new line guideline to make commenting more easier.

I think that this is pretty much all of the community discussions so far on the topic. However, it has been pretty unproblematic and unchallenged though not strictly followed.

In the enwiki's help page, the spacing between items should be done using comments. Like this in wikicode.

https://en.wikipedia.org/wiki/Help:List#Spacing_between_items

: One<!--
-->
:: Two<!--
-->
:::Three

It seems that we could do spacing with nowiki also instead of html-comments. With nowiki broken comments would not fail silently.

: first comment.<nowiki>
</nowiki>
:: second comment.<nowiki>
</nowiki>
::: third comment.

Even more clean way could be

: One<br
/>
:: Two<br
/>
::: Three

In T265291#6543744, @Zache wrote:

@ppelberg It was to make editing the wikicode easier. The original proposal was in the village pump discussion "Selkeyttävä ehdotus in 2005. It was low volume and contained only three comments. The next village pump discussion which referred to empty lines in discussions was in 2015 (Muistutus_keskustelusivukäytännöstä) when Otrfan notified that writers should follow the new line guideline to make commenting more easier.

I think that this is pretty much all of the community discussions so far on the topic. However, it has been pretty unproblematic and unchallenged though not strictly followed.

This is precisely the kind of historical context we were seeking – thank you, @Zache.

Based on our understanding that the discussions you've linked to above did not seem to elicit strong responses from people who are in support or opposition to the current policy [i] , and the limited participation in the current conversation [ii], we will move ahead with enabling the Reply Tool as a Beta Feature on the Finnish Wikipedia this upcoming Tuesday, 20-October without introducing blank lines to comments posted with it.

If you, or anyone else, strongly disagrees with the assessment and plan above, please let us know.

i. https://fi.wikipedia.org/wiki/Wikipedia:Keskustelusivu#Keskustelusivun_selke%C3%A4_k%C3%A4ytt%C3%B6
ii. https://fi.wikipedia.org/wiki/Wikipedia:Kahvihuone_(sekalaista)#New_Beta_Feature_next_week

In T265291#6546058, @Zache wrote:

It seems that we could do spacing with nowiki also instead of html-comments. With nowiki broken comments would not fail silently.

We appreciate you thinking through potential solutions that could make it easier for people interacting with talk pages in "full wikitext" to differentiate between comments in ways that work with screen readers.

With the above said, we'd like to experiment with the Reply Tool not outputting any content/syntax that people did not explicitly type themselves to start.

For context, the primary reason that is leading us to favor the approach above is as follows: to date, the consensus among people at wikis where the Reply Tool is available has been that they prefer the Reply Tool not add text to the page they did not explicitly type themselves. While this may not be the case at Finnish Wikipedia, we think it is safer to continue carrying this assumption until there is clear evidence it should be revised.

! In T265291#6557038, @ppelberg wrote:
With the above said, we'd like to experiment with the Reply Tool not outputting any content/syntax that people did not explicitly type themselves to start.

So technical options are

1.) for old wikieditor to changes to wikitext syntax which is not plausible(?)
2.) Or for new wikitext editor some rendering rule which would separate comments. using CSS styles. Ie, increase margin-bottom if the line starts with : and contains the signature.

In T265291#6557326, @Zache wrote:

! In T265291#6557038, @ppelberg wrote:
With the above said, we'd like to experiment with the Reply Tool not outputting any content/syntax that people did not explicitly type themselves to start.

So technical options are

1.) for old wikieditor to changes to wikitext syntax which is not plausible(?)

• @Zache are you able to describe what you are referring to above in a bit more detail? I want to make sure I'm understanding what you are saying before responding.

2.) Or for new wikitext editor some rendering rule which would separate comments. using CSS styles. Ie, increase margin-bottom if the line starts with : and contains the signature.

• @Zache would it be accurate for me to understand the above as you saying: "Is it possible to change how talk pages appear in "read mode" to make it easier for people to differentiate between comments by adding more visual space between them"?
  • If yes, then we do have plans to address this issue as part of the Talk pages project. This work will happen in this ticket: T249579.

@Zache are you able to describe what you are referring to above in a bit more detail? I want to make sure I'm understanding what you are saying before responding.

I mean that if we rule out the solutions where extra wikicode is added to either start or end of the comment AND target is accessibility then the only solution for plaintext wikieditor is to change wikicode parsing. This however sounds to me that it is out of scope for this project.

If we are able to change the wikicode parsing then next would be possible:

• Ignore empty newline between lines if the line starts with : AND it contains signature AND line after newline starts with :

would it be accurate for me to understand the above as you saying: "Is it possible to change how talk pages appear in "read mode" to make it easier for people to differentiate between comments by adding more visual space between them"?

I meant that when wikitext is edited with 2017 wikitext editor it is rendered as html and not plaintext. The wikitext is also annotated with html-tags so technically edited wikitext could be styled with CSS so that if the line begins with : and contains signature then the margin-bottom of the line would be larger in talk pages.

In T265291#6561999, @Zache wrote:

I meant that when wikitext is edited with 2017 wikitext editor it is rendered as html and not plaintext. The wikitext is also annotated with html-tags so technically edited wikitext could be styled with CSS so that if the line begins with : and contains signature then the margin-bottom of the line would be larger in talk pages.

Unfortunately this would be quite complex to implement:

• Our discussion parser is designed to work on HTML output, not wikitext. The signature detection part is quite complicated and would need to be rewritten.
• Syntax highlighting is provided by a third party library which would need to be reconfigured, if even possible.

Also the proportion of users using 2017WTE+Syntax highlighting is probably relatively low, so this would only work for a minority of users.

In T265291#6563170, @Esanders wrote:

Also the proportion of users using 2017WTE+Syntax highlighting is probably relatively low, so this would only work for a minority of users.

Yes, this is true.

Note: next steps on this ticket are blocked on outcome of the conversation happening on fi.wiki here: https://fi.wikipedia.org/wiki/Wikipedia:Kahvihuone_(sekalaista)#New_Beta_Feature_next_week.

I agree that there should be no blank line at all that breaks the semantic HTML structure. The presentation can be fixed only by customizing the CSS between successive comments at different indentation levels).

The Finnish "rule" also only applies (inconsistantly) to some of their community pages, it is ignored in most of them (notably when these comments are supposed to be onlines (e.g. in votes where they are at the same level) or are multiple replies to the same initial base message.

As well some users will want to reply using several paragraphs. The real separator is the user's signature (and unfortunately there's no standard way to format it as they can contain add-ons in addition to the plain default signature format. All that can be done is (on talk pages only) to increase a bit the separation between successive paragraphs (i.e. "dt" elements) using vertical margin.

For now it's still up to each user to present their replies the way that fits well in each page: if you want a blank line between replies, just insert an empty ":" paragraph at the correct indentation level.

This tool could also use a bottom margin for the last paragraph added separately for the signature/date only. But unfortunately there's still no way to style a ":" paragraph using the Mediawiki syntax, so we would need to use instead plain HTML, like <dt class="signature">~~~~</dt> on its own separate line instead of just : ~~~~ (this could cause a problem in some pages that want a one line comment, so the reply tool could include a checkbox disabled by default: if it is checked, it will append a <span class="signature">~~~~</span> (after a separating space) on the last line of the reply, instead of adding a <dt class="signature">~~~~</dt> on a separate line: only the CSS for "dt.signature" would have the extended bottom margin (1em should be enough to increase the default vertical margin of ".6em" of "dt" elements).

In my opinion, it's better to use a "class" attribute rather that try to "parse" signatures (too complicate, because user signatures has lot of formats and can contain any wiki content, even if it's limited to inline content, it may include several links: the user's page, the user tlak page, link to a user pager on another wiki, link to a user's page on a social network...; so, parsing signatures won't work if we don't encapsulate them in a reliable way).

The bonus is that some wiki may decide if they want to apply a specifi style (Finhnish wikis) or not, and on specific namespaces (e.g. not in user talk pages) or not. The calls definition would be included in the general stylesheet of the wiki.

Another way could be also to modify the Wiki parser so that if there's a blank line between 2 ":"-indented blocks, that blank line should be interpreted as implicitly *repeating* the same number of ":" of used in the preview line.

So:

:::: One talk continued on several paragraphs...
:::: .... Terminated here with a formatted signature anywhere (sometimes missing/forgotten).

::::: Reply starts here.

would be interpreted like if it was:

:::: One talk continued on several paragraphs...
:::: .... Terminated here with a formatted signature anywhere (sometimes missing/forgotten).
::::
::::: Reply starts here.

This way there's no interruption of the "dl" element, an empty "dt" element will be generated in HTML containing that separating blank line. No style/class is needed. And users are then free to add a separation blank line as they wnat on their pages. Existing Finnish talk pages can continue to use blank lines, but we get a cleaner HTML, people don't have to count the exact number of ":" needed.
As a bonus, the wiki editor could also suppress multiple empty lines (you can insert one or many, they'll count as only one: if we really want a large separation, the line has to have some content such as several "br" elements, or an element with an explicit bottom margin; generally these "br" are only used to "clear" the space used by floatting contents).

Note that if somesone replies to a message and includes floatting contents in his message, that floatting content make steal horizontal space in the space needed for responses. But floatting contents can also occur from outside the messages (e.g. in a long floatting TOC at top of the talk page), before all messages and responses in one or many sections with separate headings for distinct talk threads on the same page). We should not design however this solution based on possible floatting elements: it's up to designers of the relevant talk page to provide a correct layout for their floatting contents at top before their threaded discussions.

However floatting elements inside discussions are quite common (e.g. thumbed images which are floatting by default, but at least their width is nortmally limied, they are not very tall, and have margins around them to avoid collisions with the text written after them).

Prioritization
I am moving this ticket to the backlog and disassociating it from T265446 considering this ticket being resolved is no longer blocking the Reply Tool being made available as a Beta Feature at fi.wiki, as noted on-wiki. [i]

i. https://w.wiki/k8f

@ppelberg just FYI that I added some quick CSS workarounds for problems mentioned earlier in this page.

https://fi.wikipedia.org/w/index.php?title=J%C3%A4rjestelm%C3%A4viesti%3ACommon.css&type=revision&diff=19317975&oldid=19283017

/* Do not show reply links in "ul" or "ol" lists as they never should be replied to*/
li > .dt-init-replylink-buttons {
	display:none;
}

/* Do not show reply links in archived parts of the page */
.noreplylinks .dt-init-replylink-buttons {
	display:none;
}

/* Add some margin after end of the comment */
.dt-init-replylink-buttons {
	display: inline-block;
	margin-bottom: 0.5em;
}

Thanks for letting us know. I have to say that we can't promise that reply links will always be compatible with that CSS, and it makes it harder for us to debug any issues that occur on Finnish Wikipedia. Also, that CSS is loaded for everyone, and not only users who enabled the beta feature. But we can't stop you… :)

If you want to do it anyway, I have two comments on the implementation of this part:

/* Add some margin after end of the comment */
.dt-init-replylink-buttons {
	display: inline-block;
	margin-bottom: 0.5em;
}

Adding display: inline-block; there undoes our fix for T260072, and it should not be needed. I suggest removing it.

The workaround also increases the spacing between comment using the current convention (with an empty line between them), and I don't think that was your intention. You can instead put it on the <span data-mw-comment-end="…"></span> elements and take advantage of margin collapsing to avoid that. (We've only added the data-mw-comment-end elements recently, so you might not have seen them when writing that code.)

[data-mw-comment-end] {
    display: block;
    margin-bottom: 0.5em;
}

.mw-headline [data-mw-comment-end] {
    display: none;
}

Eh, actually, I have another comment. I'm not sure if Do not show reply links in "ul" or "ol" lists as they never should be replied to is a good idea.

Even on https://fi.wikipedia.org/wiki/Wikipedia:Kahvihuone_(sekalaista) (permalink), there are 3 comments affected by that rule, and they all look like normal comments to me that should have reply links.

(I can't link to comments, but they are the three comments starting with: "Toinen esimerkki"…, "Tämä ei nyt"…, "Jatkan numerointilinjalla"…)

In T265291#6617114, @matmarex wrote:

Thanks for letting us know. I have to say that we can't promise that reply links will always be compatible with that CSS, and it makes it harder for us to debug any issues that occur on Finnish Wikipedia. Also, that CSS is loaded for everyone, and not only users who enabled the beta feature. But we can't stop you… :)

No support for local changes is expected, but it would be nice if the fixes in some form could be implemented in the main version (in some form) so the local workarounds could be removed.

I updated the CSS and it is now like this

/* Do not show reply links in "ul" or "ol" lists as they never should be replied to*/
li > .dt-init-replylink-buttons {
	display:none;
}

/* Re-show reply links when reply contains a list and signature is inside of the list */
dd li > .dt-init-replylink-buttons {
	display:inline-flex;
}


/* Do not show reply links in archived parts of the page */
.noreplylinks .dt-init-replylink-buttons {
	display:none;
}

/* Add some margin after end of the comment */
span[data-mw-comment-end] {
    display: block;
    margin-bottom: 0.5em;
}

/* Do not add margin after the signature in the voting rows etc */
li span[data-mw-comment-end] {
    display: none;
}

.mw-headline span[data-mw-comment-end] {
    display: none;
}

Eh, actually, I have another comment. I'm not sure if Do not show reply links in "ul" or "ol" lists as they never should be replied to is a good idea.

Thanks for noticing those. I added dd li > .dt-init-replylink-buttons { display:inline-flex; } rule for handling most common of the corner cases, but i think that the cases are pretty rare so i will just look and see how it works with the rest of the cases.

This still won't catch top level comments that end with a signed list item.

I would strongly suggest you hold off on local customisations while the tool is still a beta feature and in active development, especially ones that can break the tool.

In T265291#6619631, @Esanders wrote:

This still won't catch top level comments that end with a signed list item.

On purpose as the idea is to prevent the replying to votes/lists. Also, as said, comments with lists are rare in fiwiki and missing reply link is far less disruptive than replying to votes in example.

I would strongly suggest you hold off on local customisations while the tool is still a beta feature and in active development, especially ones that can break the tool.

The tool can be in beta, but it is used in live enviroment and it will be treated by the community with same level of expectations than everything else. Replying to votes or archived part of pages are things which are bound to create social problems (and also creating opposition against to the tool) which needs to be handled somehow even if it makes debugging harder.

@Zache: we appreciate you making us aware of the changes you put in place at fi.wiki. [i]

I'd like to comment on, what I understand to be, the scenario you are most concerned with preventing: people commenting on votes, archived discussions and more broadly, using the Reply Tool to participate in conversations that could cause social problems.

For now, we are going to continue documenting cases where the Reply Tool is present in places where it could and does cause people to participate in ways that cause social problems.[ii]

Taking this time to document a range of cases will help with two things:

1. Understand how work on T249293 and T259865 ought to be prioritized and
2. Devise a sustainable way of suppressing the tool and/or creating a way of participating in these voting-style conversations.[iii]

As it relates to this issue at fi.wiki, I am thinking we revisit the impact of the changes you've put in place [i] when are considering making the Reply Tool available by default there...does this sound agreeable to you?

i. T265291#6614297
ii. T249293#6604678
iii. See T249293 and T259865

Yes, it sounds agreeable to me.

Btw, one visible problem which exists but no-one have complained so far about is that if user doesn't use the Reply Tool then when there is no empty line between comments the margin is smaller in rendered version of the page. Users who are logged in can enable the Reply Tool which fixes the margin difference if it bothers them. However, users who arent logged in don't have that option and fixing it waits that the Reply Tool would be enabled by default.

In T265291#6653081, @Zache wrote:

Yes, it sounds agreeable to me.

Great.

Btw, one visible problem which exists but no-one have complained so far about is that if user doesn't use the Reply Tool then when there is no empty line between comments the margin is smaller in rendered version of the page. Users who are logged in can enable the Reply Tool which fixes the margin difference if it bothers them. However, users who arent logged in don't have that option and fixing it waits that the Reply Tool would be enabled by default.

Hmmm, would you mind writing out the steps we can take to reproduce the issue you are describing in the description of this newly-filed ticket: T268960? Also, if you have a link to where you observed this behavior that would be helpful as well.

Thank you, @Zache.