Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

blockquotes violate principle of uniformity #634

Open
vassudanagunta opened this issue Feb 3, 2020 · 5 comments
Open

blockquotes violate principle of uniformity #634

vassudanagunta opened this issue Feb 3, 2020 · 5 comments
Milestone

Comments

@vassudanagunta
Copy link

vassudanagunta commented Feb 3, 2020

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.

@vassudanagunta
Copy link
Author

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.

@Crissov
Copy link
Contributor

Crissov commented Feb 3, 2020

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>

@vassudanagunta
Copy link
Author

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

@jgm
Copy link
Member

jgm commented Feb 3, 2020

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

@jgm jgm added this to the 0.30 milestone Feb 3, 2020
@Crissov
Copy link
Contributor

Crissov commented Feb 3, 2020

@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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants