List item requires too much spaces for nesting

[gfx]

v0.28 of List Item spec is too complex to understand.

http://spec.commonmark.org/0.28/#list-items

See the rendered result of the code:

100. foo
    * bar

babelmark: https://babelmark.github.io/?text=100.+foo%0A++++*+bar

which is not nested but flatten in commonmark, as the spec says. This is the spec, but whoever wants this behavior? I don't know the editor that can make a nest with a single TAB key. I think it is a specification problem because it is a too complex rule compared with other markdowns.

Why didn't the spec define "nesting lists require 2 spaces" (or "4 spaces")?

[mity]

Also when adding 100-th list item into a list with nested lists, it may require deeper nesting then in the previous 99 items, so author may need to edit all the preceding items to get visually nice document in the raw form.

[jgm]

+++ FUJI Goro [Aug 28 17 09:17 ]:

Why didn't the spec define "nesting lists require 2 spaces" (or "4 spaces")?

This is explained in the spec itself. See [5.2.1 Motivation](http://spec.commonmark.org/0.28/#motivation).

[gfx]

But as a result, only CommonMark does not make nested lists.

I disagree with the spec that CommonMark is not compatible with commonly-used markdown parsers such as pandoc, redcarpet, or even markdown.pl.

[aidantwoods]

It's perhaps worth noting that the parsers which produce the desired indent do not support a perhaps useful feature of starting the list at item 100.

I disagree with the spec that CommonMark is not compatible with commonly-used markdown parsers such as pandoc, redcarpet, or even markdown.pl.

Just because lots of parsers do something, I'm not sure it makes it better? The whole point in CommonMark is to establish a spec that conforming parsers should follow – eliminating this exact type of problem. I'll bet that all of the parsers listed disagree frequently elsewhere, especially if they're attempting to follow the original Markdown implementation.

For example, pandoc and redcarpet don't agree on how to parse the following

100.    foo
    * bar

https://babelmark.github.io/?text=100.++++foo%0A++++*+bar

[mity]

Even if we take CommonMark specification as given and reject seeing it as a nested list, it is very unclear how to interpret it. Because it is long and because I see this issue more as a request to change the spec., I have created #497 to address it within the bounds of current spec wording.