The current spec says that two blank lines (except in a fenced code block) terminates all containing lists. I’d like to reconsider this rule. It is inconsistent with the principle of uniformity that guides some of the spec’s other decisions, and with the “basic case” (rule 1) in the spec for list items. For the following text is two paragraphs:
so, by the principle of uniformity (and rule 1 for list items), we’d expect the following to be a list item containing the same two paragraphs:
- aaa bbb
but because of the tacked-on “two blank lines breaks out of lists” rule, it is instead interpreted as a list item with one paragraph, followed by a separate paragraph not in the list item.
I’ve come to think that the “two blank lines breaks out of lists” rule is more trouble than it’s worth. It creates surprise by breaking uniform patterns. Why did we think we needed it? The idea was first suggested long ago on the markdown-discuss list, in response to the question “how can I have a code block after a list item?” The problem was that if you wanted the sequence (LIST) (CODE BLOCK), you couldn’t write
1. list item code block
because the text
code block would be interpreted as part of the list item, not a separate block after the list. The recommended solution was to insert an HTML comment:
1. list item <!-- --> code block
which works just fine, though it’s a bit ugly. But now we have an even better solution: just use a fenced code block:
1. list item ``` code block ````
So, the addition of fenced code blocks seems to have solved the problem that first motivated the two-blanks break out of lists idea.
There is one other kind of case that might be thought to motivate the two-blanks rule: a case where you want to have two separate lists of the same type, instead of a single list with two items:
- one - two - one - two
This is not so common. But here, again, some CommonMark enhancements can give us what we want without the two-blanks rule:
- one - two + one + two
Any thoughts on this? The proposal is to remove the two-blanks-break-out-of-lists rule.