Ordered sublists must start with 1. or they don't embed?

Spec
1

(This could be an Implementation question – it’s Spec insofar as I’m not sure if what I’m seeing in the implementations follows the spec or not. I don’t think they do.)

As a Markdown editor author, I’m finding the treatment of embedded ordered lists problematic.

For instance, this Markdown…

1. item one
2. item two
    3. item three

Will create this html source:

<ol>
<li>item one</li>
<li>item two
3. item three</li>
</ol>

… where 3. is within the same list item as 2.

Rendered (actual):

  1. item one
  2. item two 3. item three

Because the numbers don’t matter beyond saying we’re in an ordered list (technically a lie; see below), I would expect this to render as…

Source (desired):

<ol>
<li>item one</li>
<li>item two
<ol>
<li>item three</li>
</ol>
</li>
</ol>

Rendered (desired):

  1. item one
  2. item two
    1. item three

To make things a little more interesting, if 3. item three starts with 1., it renders how I’d expect. (I speculate a little about why, below.)

Markdown:

1. item one
2. item two
    1. item three

Source (actual):

<ol>
<li>item one</li>
<li>item two
<ol>
<li>item three</li>
</ol>
</li>
</ol>

Rendered (actual):

  1. item one
  2. item two
    1. item three

That looks good. But I don’t believe the spec requires resetting to 1. with each indent to create a sublist.

Practical use case

The use case here is that I’ll often have someone with an existing list (with numbers 1, 2, 3, 4 inserted by an auto-numberer) select & “tab over” (hit tab while the lines are selected) one or more items to create a sublist, and if I don’t parse & renumber that selection, I get the run-on line rather than a sublist.

List without indents.

1. item one
2. item sublist
3. item sublist
4. item two

Then select the second and third, and "tab them over…

1. item one
    2. item sublist
    3. item sublist
4. item two

Ick…

<ol>
<li>item one
2. item sublist
3. item sublist</li>
<li>item two</li>
</ol>
  1. item one 2. item sublist 3. item sublist
  2. item two

I’ve started renumbering an ol if users are mid-list and tab a line over. At some point, I’d like to add logic to fluidly renumber any ordered list, from top to bottom, as indents are made, but this seems more like a nicety than something that should have to happen for the Markdown to be rendered elegantly.

Unordered list behavior

I would argue what we see here with ordered lists isn’t consistent with the treatment of unordered lists, where…

- foo
  - bar
    - baz
      - boo

… evaluates to nested, unordered sublists…

<ul>
<li>foo
<ul>
<li>bar
<ul>
<li>baz
<ul>
<li>boo</li>
</ul>
</li>
</ul>
</li>
</ul>
</li>
</ul>

Here’s the ordered list from above as an unordered list.

* item one
* item two
    * item three

Nice:

<ul>
<li>item one</li>
<li>item two
<ul>
<li>item three</li>
</ul>
</li>
</ul>
  • item one
  • item two
    • item three

Quacks like a paragraph?

Though I haven’t checked the code, I’m going to guess that the parsers, including the dingus, are treating the first example’s nested 3. item three as part of the previous line because of some misapplication (?) of the spec logic for examples 267 and following (linking to 266 to back up before the discussion).

Since it is well established Markdown practice to allow lists to interrupt paragraphs inside list items, the principle of uniformity requires us to allow this outside list items as well. (reStructuredText takes a different approach, requiring blank lines before lists even inside other list items.)

In order to solve of unwanted lists in paragraphs with hard-wrapped numerals, we allow only lists starting with 1 to interrupt paragraphs.

I’m don’t think that rule should apply here, where no paragraphs are being created (check the HTML pane in the dingus).

Any pointers what’s up? It’s certainly awkward behavior.

Thanks!

2

I looked into this behaviour a bit. Technically, each list item contains a paragraph. Hence:

1. item one
2. item two
    3. item three

"3." is considered interrupting the paragraph that started with "item two\n", and so it’s not parsed as a list item. One way to avoid this is to add an extra newline:

1. item one
2. item two

    3. item three

This does, however, result in the list not being “tight”.

3

Commonmark differs from all preexisting implementations here. I believe the intention is to make blocks identified the same regardless of nesting. Alas, it doesn’t.

1. one
2. two
    3. three

one
two
 3. three

Without the first three characters in each line, one and two become part of the same paragraph regardless whether three is also in it.

When the current parsing context is a list, each line of source text should first be tried for being the next list item, second a nested block, then finally considered either a continuation of the block inside the last item or a new block after the list.

Note what happens if the list item contains a blockquote. Commonmark parsers other than Markdig now see an embedded list there.

1. one
2. > two
    3. three
4

That was my guess, but is that in the spec? (Asking; I’ll go take another look.) There are certainly no p tags in the generated source.

And then I’d ask if that’s the best behavior. I’d submit that the spec should privilege that you’re within an ordered list over standard paragraph behavior. I mean, if 1. can have special behavior, why not a list context?

I understand that…

* item one
* item two
    * item three

… is a little like…

1. item one
1. item two
    1. item three

… which would render how I’d want, but that’s not a great construct. A one-line list item should not be primarily considered a paragraph that requires a 1. to create a new or sub- list.

<ol>
<li>one</li>
<li>
<blockquote>
<p>two</p>
</blockquote>
<ol start="3">
<li>three</li>
</ol>
</li>
</ol>

:astonished: Great.

5

It is; whether p tags get output is according to whether the list is tight or not (see spec), but they are there in the AST in either case.

I totally agree! :+1:t2:

7

Please refer to Blank lines before lists, revisited