Lazy quoteline after empty quoteline #406

Closed
opened 2026-01-29 14:35:54 +00:00 by claunia · 6 comments
Owner

Originally created by @generateui on GitHub (Oct 3, 2020).

>
p

should be parsed as one quoteblock, yet it is parsed as a quoteblock and then paragraph block after.

See also: https://babelmark.github.io/?text=%3E%0Ap%0A. Note that about half of markdown parsers have this bug. I conclude this is a bug because of two examples in the spec:

Originally created by @generateui on GitHub (Oct 3, 2020). ``` > p ``` should be parsed as one quoteblock, yet it is parsed as a quoteblock and then paragraph block after. See also: https://babelmark.github.io/?text=%3E%0Ap%0A. Note that about half of markdown parsers have this bug. I conclude this is a bug because of two examples in the spec: - https://spec.commonmark.org/0.29/#example-202 - https://spec.commonmark.org/0.29/#example-209
claunia added the invalid label 2026-01-29 14:35:54 +00:00
Author
Owner

@xoofx commented on GitHub (Oct 3, 2020):

Well, the spec is maybe unclear on that particular case, but all CommonMark implementations are behaving the same. Lazyness ness (so continuing a blockquote on the following paragraph) can only happen if the starting blockquote has already a content paragraph.
If you disagree with this rule you should ask to the commonmark forum as it is a edge case that might need a clarification in the specs (but I think the lazyness description in the spec should cover this part).

@xoofx commented on GitHub (Oct 3, 2020): Well, the spec is maybe unclear on that particular case, but all CommonMark implementations are behaving the same. Lazyness ness (so continuing a blockquote on the following paragraph) can only happen if the starting blockquote has already a content paragraph. If you disagree with this rule you should ask to the commonmark forum as it is a edge case that might need a clarification in the specs (but I think the lazyness description in the spec should cover this part).
Author
Owner

@generateui commented on GitHub (Oct 3, 2020):

According to babelmark, there's a roughly 50% split in Markdown implementations. Will do your suggestion, as the 50/50 interpretation clearly shows ambiguity/unclarity here.

@generateui commented on GitHub (Oct 3, 2020): According to babelmark, there's a roughly 50% split in Markdown implementations. Will do your suggestion, as the 50/50 interpretation clearly shows ambiguity/unclarity here.
Author
Owner

@generateui commented on GitHub (Oct 3, 2020):

See discussion in markdown spec forum: https://talk.commonmark.org/t/unclear-paragraph-after-empty-quoteline-in-quote-block/3652

@generateui commented on GitHub (Oct 3, 2020): See discussion in markdown spec forum: https://talk.commonmark.org/t/unclear-paragraph-after-empty-quoteline-in-quote-block/3652
Author
Owner

@xoofx commented on GitHub (Oct 3, 2020):

According to babelmark, there's a roughly 50% split in Markdown implementations. Will do your suggestion, as the 50/50 interpretation clearly shows ambiguity/unclarity here.

Yes, and all the 50% implementations are not CommonMark, so that explain why there is this split. All 100% CommonMark implementations are following the same rule.

@xoofx commented on GitHub (Oct 3, 2020): > According to babelmark, there's a roughly 50% split in Markdown implementations. Will do your suggestion, as the 50/50 interpretation clearly shows ambiguity/unclarity here. Yes, and all the 50% implementations are not CommonMark, so that explain why there is this split. All 100% CommonMark implementations are following the same rule.
Author
Owner

@xoofx commented on GitHub (Oct 3, 2020):

If the specs make it clear in a future version, we will fix it. For now, we are all following the specs.

@xoofx commented on GitHub (Oct 3, 2020): If the specs make it clear in a future version, we will fix it. For now, we are all following the specs.
Author
Owner

@generateui commented on GitHub (Oct 3, 2020):

Ah, that makes sense. I assumed all implementation on babelmark implemented the commonmark spec.

@generateui commented on GitHub (Oct 3, 2020): Ah, that makes sense. I assumed all implementation on babelmark implemented the commonmark spec.
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/markdig#406