List items are fragile in wikitext, and there are many things that can't be effectively embedded in lists. In theory we can just use a <dl><dd> tag in wikitext to work around this, but this isn't done in practice, mostly because it looks very ugly.
So (using talk pages as an example) instead we have:
: This is a comment : This is still the same comment! {| |+ I wanted to embed a table but I had to break out of the list item to do that |} : Ok, another item. I'm done with my comment now... ~~~~
A better syntax for multiline list items would help. T114432: [RFC] Heredoc arguments for templates (aka "hygienic" or "long" arguments) interalia proposes a syntax that looks like:
: <<< This is a comment This is still the same comment! {| |+ I wanted to embed a table but I had to break out of the list item to do that |} Ok, another item. I'm done with my comment now... ~~~~ >>>
But there are other alternatives that have been mooted.
One is to use {* ... *} / {: ... :} syntax, which is based on the wikitext 2.0 proposal. The nested form of that would look something like:
:::{: line 1 line 2 :}
although different variants are proposed.
Another proposal is to use "traditional" email quoting characters:
> line 1 > line 2 > > * embedded list
This doesn't actually conflict with HTML, since < is the special character in HTML -- > is only a meta character after an initial < has been seen. The angle brackets also work well in a RTL context, since they are "logical" punctuation and change direction in a RTL context, for example: https://ar.wikipedia.org/wiki/%D9%85%D8%B3%D8%AA%D8%AE%D8%AF%D9%85:Cscott/AngleTest . However, it is then difficult to cut-and-paste content into a comment, since you need to go through and manually add > to each line. In theory you could mix this with heredoc quoting to avoid this, but that results in:
>>> Deeply nested reply <<< multi line * embedded list >>> >>>> Next item
That might be considered bracket overload. By making this syntax only work at start-of-line, we can probably avoid most breakage of legacy content, although probably some folks mask whitespace in wikitext using constructs like:
<span class="foo" >something something...
Presumably we'd use entity encoding or <nowiki/> to handle quoting content that started with a literal > character (this should be rare!), but the old usenet quoting standard considered >> and > > to be different: the former was a two-level-deep quote, and the latter was a one-level-deep quote starting with a literal angle bracket (the intervening space is removed). No reason we have to implement usenet quoting exactly, of course.
It should be considered how well these various multiline content proposals integrate with/account for:
- Interoperability with existing :-style items, since old-school editors will continue to mix "traditional" syntax and new
- Extensions to add attributes to the item: T230658: Syntax for list item attributes or similar
- The desire to have an HTML box around "just this one comment". The old-style : context technically nests replies in the same box as the original comment, so it is hard to use styles which highlight "just this one comment not its replies". T230654: Parser support for talk pages discusses this issue.