# Spec section 5.1: Ref-impl bug and/or unclear spec? **URL:** \ **Category:** Spec\ **Created:** [January 10, 2016, 5:46pm UTC](https://talk.commonmark.org/t/spec-section-5-1-ref-impl-bug-and-or-unclear-spec/1974 "2016-01-10T17:46:51Z")\ **Posts on this page:** 6\ **Page:** 1
**Author:** ![tin-pot](https://cdn.commonmark.org/user_avatar/talk.commonmark.org/tin-pot/32/810_2.png) [@tin-pot](https://talk.commonmark.org/u/tin-pot)\ **Post date:** [January 10, 2016, 5:46pm UTC](https://talk.commonmark.org/t/spec-section-5-1-ref-impl-bug-and-or-unclear-spec/1974/1 "2016-01-10T17:46:51Z")
[Section 5.1](http://spec.commonmark.org/0.23/#block-quotes "CommonMark spec, section 5.1 "Block quotes"") gives the rules for _blockquotes_. Consider (a) this [input text](http://johnmacfarlane.net/babelmark2/?normalize=1&text=%0A1.++top+level%0A++++-+++sub+level%0A++++-+++sub+level%0A2.++top+level%0A "Input text (a) in BabelMark"): ``` 1. top level - sub level - sub level 2. top level ``` and (b) this [input text](http://johnmacfarlane.net/babelmark2/?normalize=1&text=%0A%3E+1.++top+level%0A++++++-+++sub+level%0A++++++-+++sub+level%0A%3E+2.++top+level%0A%0A "Input text (b) in BabelMark"): ``` > 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: ```
  1. top level
- sub level
- sub level
  1. top level
``` The implementation does the same even if _two spaces_ [are removed (c)](http://johnmacfarlane.net/babelmark2/?normalize=1&text=%0A%3E+1.++top+level%0A++++-+++sub+level%0A++++-+++sub+level%0A%3E+2.++top+level%0A%0A "Input text (c) in BabelMark") 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](http://spec.commonmark.org/dingus/ "CommonMark spec - Dingus"), sees **neither** a _code block_ **nor** an _unorderd list_ in inputs (b) and (c), which is still not what I would expect [this matches the result produced by `cmark` 0.22]. ```
  1. top level - sub level - sub level
  2. top level
``` * * * 1. Is this the behavior intended by the specification? 2. If so, how can it be inferred from the wording in section 5.1 (and/or elsewhere)? 3. Do authors _have_ to write explicit _block quote markers_ in front of the two `sub level` lines here? 4. If so, what is the rationale for this? ---
**Author:** ![jgm](https://cdn.commonmark.org/user_avatar/talk.commonmark.org/jgm/32/1360_2.png) [@jgm](https://talk.commonmark.org/u/jgm)\ **Post date:** [January 10, 2016, 6:41pm UTC](https://talk.commonmark.org/t/spec-section-5-1-ref-impl-bug-and-or-unclear-spec/1974/2 "2016-01-10T18:41:15Z")
> [@tin-pot](#): > > 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. No. The laziness rule defines a possible transformation: it says that in some cases you can move from ```auto > text1 > text2 ``` to ```auto > text1 text2 ``` But whether you can do this depends on whether text2 is a “paragraph continuation line,” that is, on whether in the original case it would be parsed as a continuation of a preceding paragraph. You don’t have that in this case, because the relevant line would be parsed as a list item. Current (dev) versions of cmark and commonmark.js both parse your text (b) as: ```auto
  1. top level - sub level - sub level
  2. top level
``` So does the dingus. I have just updated the version of commonmark.js in BabelMark2. ---
**Author:** ![tin-pot](https://cdn.commonmark.org/user_avatar/talk.commonmark.org/tin-pot/32/810_2.png) [@tin-pot](https://talk.commonmark.org/u/tin-pot)\ **Post date:** [January 10, 2016, 7:48pm UTC](https://talk.commonmark.org/t/spec-section-5-1-ref-impl-bug-and-or-unclear-spec/1974/3 "2016-01-10T19:48:07Z")
> But whether you can do this depends on whether text2 is a “paragraph continuation line,” that is, on whether in the original case it would be parsed as a continuation of a preceding paragraph. You don’t have that in this case, because the relevant line would be parsed as a list item. Errrm. Okay. A _blockquote_ can’t have a _lazy continuation line_ which is also a _list item_ then, but only if this is the _first lazy continuation line_? Otherwise, a _lazy continuation line_ will be recognized as a list item: ``` > 1. top level foo - sub level - sub level > 2. top level ``` * * * > Current (dev) versions of cmark and commonmark.js both parse your text (b) as: [not a unordered sub-list] That’s what the dingus did, and `cmark` 0.22 too. * * * So, trying to answer my own questions based on the information you gave: > 1. Is this the behavior intended by the specification? Yes (not the _code block_ output, but the _no unordered sub-list here_ output is intended, yes). > 2. If so, how can it be inferred from the wording in section 5.1 (and/or elsewhere)? By “simply” checking whether in the original case it would be parsed as a continuation of a preceding paragraph. The summary rule is: A _list item line_ (without a _block quote marker_) will be recognized as such - _everywhere_ - in any block that - started “vanilla”, - or as a list item, - or as a heading, - or as a blockquote, but **not** if the preceding line has a _blockquote marker_. > 3. Do authors have to write explicit block quote markers in front of the two sub level lines here? Because you don’t have that in this case, my guess is: Yes. > 4. If so, what is the rationale for this? I still don’t know. My guess would be the _“uniformity principle”_ at work again. Compared with other parsers’ results, and with the maybe not quite so unfounded expectation of seeing an _unordered list_ output, the stress seems to be on “principle”, not “uniformity”. 😛 ---
**Author:** ![jgm](https://cdn.commonmark.org/user_avatar/talk.commonmark.org/jgm/32/1360_2.png) [@jgm](https://talk.commonmark.org/u/jgm)\ **Post date:** [January 11, 2016, 12:16am UTC](https://talk.commonmark.org/t/spec-section-5-1-ref-impl-bug-and-or-unclear-spec/1974/4 "2016-01-11T00:16:19Z")
> [@tin-pot](#): > > Otherwise, a lazy continuation line will be recognized as a list item: > > \> 1. top level > foo > > - sub level > - sub level > \> 2. top level No, in your example the third and fourth lines _aren’t_ lazy continuation lines. Note that the unordered list is not inside the block quote. Think about it this way. Laziness is a convenience for the writer (not the reader – for the reader it’s better to avoid laziness). So the way to think of it is from the writer’s point of view. Laziness is a transformation you can perform on a non-lazy document that creates a document with the same meaning. The transformation is this: if you’ve got paragraph continuation lines with block quote markers in front of them, you can remove the block quote markers. On lines with indicators of new block structure (i.e., non-paragraph continuation lines), you can’t remove the block quote markers. That would just cause too much confusion. Note that [current implementations disagree about this](http://johnmacfarlane.net/babelmark2/?normalize=1&text=%3E+1.+one%0A%23+two%0A). ---
**Author:** ![tin-pot](https://cdn.commonmark.org/user_avatar/talk.commonmark.org/tin-pot/32/810_2.png) [@tin-pot](https://talk.commonmark.org/u/tin-pot)\ **Post date:** [January 11, 2016, 12:57am UTC](https://talk.commonmark.org/t/spec-section-5-1-ref-impl-bug-and-or-unclear-spec/1974/5 "2016-01-11T00:57:51Z")
> [@jgm](#): > > No, in your example the third and fourth lines aren’t lazy continuation lines. Note that the unordered list is not inside the block quote. Yes, yes: that’s in the spec, [example 186][ex-186] is an example for such an example illustrating this … > Laziness is a transformation you can perform on a non-lazy document that creates a document with the same meaning. That’s precisely how I think of it. > The transformation is this: if you’ve got paragraph continuation lines with block quote markers in front of them, you can remove the block quote markers. That’s precisely what I want to do—I’m _that_ lazy. > On lines with indicators of new block structure (i.e., non-paragraph continuation lines), you can’t remove the block quote markers. That would just cause too much confusion. To be honest, I find the pre-condition for removing the _quote block marker_, not exactly “non-confusing”: > If a string of lines Ls constitute a block quote with contents Bs, then the result of deleting the initial block quote marker from one or more lines in which the next non-whitespace character after the block quote marker is paragraph continuation text is a block quote with Bs as its content. Paragraph continuation text is text that will be parsed as part of the content of a paragraph, but does not occur at the beginning of the paragraph. Could it be that much of the cause for confusion (which the _lazy continuation line_ rule is supposed to _avoid_?) stems—again—from allowing _nested constructs_ to begin right in the middle of an ordinary block? I’ll have to think about this; for now I’d like to recap: - I find the _lazy continuation_ rules for _blockquote_ pretty unintelligible: both hard to understand, and even harder to relate to a rationale; - There’s quite some variation in the handling of this issue in other implementations. Thanks for your explanations, though! [ex-186]: [CommonMark Spec](http://spec.commonmark.org/0.23/#example-186) (CommonMark spec, ex. 186) ---
**Author:** ![tin-pot](https://cdn.commonmark.org/user_avatar/talk.commonmark.org/tin-pot/32/810_2.png) [@tin-pot](https://talk.commonmark.org/u/tin-pot)\ **Post date:** [January 11, 2016, 1:46am UTC](https://talk.commonmark.org/t/spec-section-5-1-ref-impl-bug-and-or-unclear-spec/1974/6 "2016-01-11T01:46:48Z")
> [@jgm](#): > > Note that current implementations disagree about this. The disagreement you point to seems to be about _ATX headings_ right in the middle of a block, and not so much about _blockquote_. Try [this—simple—one](http://johnmacfarlane.net/babelmark2/?normalize=1&text=%0A%3E+1.+one%0A2.+two%0A "BabelMark example 1"): ``` > 1. one 2. two ``` Is see **much** less disagreement here: - _Parsers that include the_ “`two`” _line in the list:_ showdown 0.3.1; marked 0.2.6; Markdown.pl 1.0.1; Markdown.pl 1.0.2b8; lunamark 0.2; pandoc (strict) 1.16; RedCarpet 2.1.1; RDiscount 1.6.8; PHP Markdown Extra 1.2.8; Python-Markdown 2.6.5; PHP Markdown 1.0.2; Minima 0.8.0a3\_20140907; kramdown 1.2.0; Parsedown 1.6.0; s9e\TextFormatter (Fatdown/PHP) ; cebe/markdown GFM 1.1.0; cebe/markdown 1.1.0; cebe/markdown MarkdownExtra 1.1.0; pandoc 1.16; Blackfriday. - _Parsers that exclude the line, and close the blockquote before it:_ commonmark 0.21.0; cheapskate 0.1.0.1; league/commonmark 0.12.0; markdown-it 4.1.0; Gambas 3.8.90 [edit: forgot Maruku 0.7.2; Maruku (Math-Enabled) 0.7.3.beta1]. Note that \*commonmark\* is (twice!) in this list, among crap like Gambas (excuse me, but look at its output!). That’s no substitute for a decision and a clear and useful rule, of course. But I don’t think there can be any doubt what is “common”, and what a “highly compatible” specification should specify in this case. Therefore in my view the question is rather: what rule or set of rules would imply this result, while being simple, general, etc.