Section 5.1 gives the rules for blockquotes.
Consider (a) this input text:
1. top level - sub level - sub level 2. top level
and (b) this input text:
> 1. top level - sub level - sub level > 2. top level
Reading the description of the “basic case”, together with the details for “laziness”, it seems to me that (b) is a block quote wrapping (a) as content. The reference implementation (announced as version 0.21.0 in BabelMark) produces—as expected—a nested list for the input text (a); but for input text (b) it insists on seeing the two
sub level lines as a code block, producing:
<blockquote> <ol> <li>top level</li> </ol> </blockquote> <pre><code>- sub level - sub level </code></pre> <blockquote> <ol start="2"> <li>top level</li> </ol> </blockquote>
The implementation does the same even if two spaces are removed © from each of the
sub level lines’ indent (to account for the absence of the “
>␣” block quote marker, so to say).
The (presumably, as there’s no version indication) current
commonmark.js implementation, available as the dingus, sees neither a code block nor an unorderd list in inputs (b) and ©, which is still not what I would expect [this matches the result produced by
<blockquote data-sourcepos="3:1-6:15"> <ol data-sourcepos="3:3-6:15"> <li data-sourcepos="3:3-5:19">top level - sub level - sub level</li> <li data-sourcepos="6:3-6:15">top level</li> </ol> </blockquote>
- Is this the behavior intended by the specification?
- If so, how can it be inferred from the wording in section 5.1 (and/or elsewhere)?
- Do authors have to write explicit block quote markers in front of the two
sub levellines here?
- If so, what is the rationale for this?