New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
nested ordered lists indented with 2 spaces are broken #399
Comments
The two-space rule is explicitly discussed in the spec marked and redcarpet are not even consistent about the Anyway, this tracker is not the place for open-ended +++ Sean Lang [Mar 31 16 21:39 ]:
|
Moved the post to http://talk.commonmark.org/t/nested-ordered-lists-indented-with-2-spaces-are-broken/2064, but had to break most of the links to get it to work. |
According the list-items rule (that sublists need to be indented to the column of the first non-whitespace character after the list marker), the following Markdown:
Represents a single non-nested list:
Which seems wrong, because using a 2-space indent is enough to have the list rendered correctly with marked, redcarpet (& therefore GitHub), the original Markdown implementation, and PHP Markdown (see comparison on Babelmark).
I haven't gotten any stats yet on how popular 2 space indents are among people who write Markdown, but since there's at least one styleguide recommending it, I think it's more than an edge-case.
For people who are thinking about indentation in terms of the number of spaces before the list marker, it's quite strange that you can use 2 spaces to nest a list within an unordered list, but need at least 3 spaces to nest within an ordered one. The absurdity of this rule is illustrated further when you have ordered lists in the 2-3 digit range:
The tutorial at http://commonmark.org/help/tutorial/10-nestedLists.html says:
...But that doesn't work in the above example because once you get above 100 you need to switch to 5-space minimum indents (see comparison on Babelmark).
I've read the "motivation" section of the spec discussing this rule, but I'm unconvinced because cases like:
...Are already handled perfectly by all parsers. And cases like:
...Probably should be read as a list item with a subparagraph.
A few other discussions have covered the same topic:
PS: The "changing the bullet or ordered list delimiter starts a new list" rule is an awful thing to put in the standard. No other parsers do that.
The text was updated successfully, but these errors were encountered: