commonmark/commonmark-spec

blockquotes violate principle of uniformity

vassudanagunta opened this issue · 5 comments

principle of uniformity: if a chunk of text has a certain meaning, it will continue to have the same meaning when put into a container block (such as a list item or blockquote).

The following:

List with sublist:

- a
  - b

Exact same lines put in a blockquote container block:

>- a
>  - b

is rendered by CommonMark 0.29 as

bq0

Please compare the above with the example given in the spec just below the definition of the principle of uniformity

A plurality of markdown implementations, including the original Gruber, correctly follow the principle in this regard (I'm counting all the CommonMark implementations as one).

Another example of the issue:

     indented 5 spaces
    indented 4 spaces
     indented 5 spaces

The above lines, in a blockquote:

>     indented 5 spaces
>    indented 4 spaces
>     indented 5 spaces

is rendered as:

bq2

Though in this case, all the implementations except MultiMarkdown get it wrong. I would say this latter case is esoteric and unimportant. The first case, the handling of nested lists as demonstrated in the first example, should determine the proper course of action.

This issue has common cause (double entendre intended) with #421 and #460, both of which are currently attached to the 0.30 milestone.

I think the many proposals considered under #466 should also be evaluated against at least the first example above.

The spec should really disallow blockquote markers without a single space following it,

>- a
>  - b
<p>&gt;- a
&gt;  - b</p>

but since that would break backwards compatibility, they should tu least not be mend together in a single blockquote, cf. different bullet list markers.

Then, this Commonmark input

>- a
>  - b

would be identical to

>- a

>  - b

and both would yield the same (normalized) HTML output:

<blockquote><ul><li>a</li></ul></blockquote>
<blockquote><ul> <li>b</li></ul></blockquote>

That interpretation, @Crissov, to me is very counterintuitive and runs counter to Markdown's design principles.

jgm commented

Yeah, this is a problem for sure. As noted in my comment on #460, it's a tricky one.

@vassudanagunta Blockquote markers are the only line prefixes that do not require a space following them, since hash-sign headings have been fixed.

PS: Blockquotes - whitespace after > thread in the CM Discourse