commonmark-spec icon indicating copy to clipboard operation
commonmark-spec copied to clipboard

Example 62 needs clarification

Open nojb opened this issue 7 years ago • 6 comments

Hello, Example 62 says

The setext heading underline cannot be a lazy continuation line in a list item or block quote:

But the example seems to contradict that:

> foo
bar
===

gives

<blockquote>
<p>foo
bar
===</p>
</blockquote>

But shouldn't the === start a new paragraph? Am I missing something?

nojb avatar Oct 18 '18 17:10 nojb

The line === is a lazy continuation line in the block quote. That is why it doesn't make bar into a setext header.

jgm avatar Oct 18 '18 23:10 jgm

Hi, thanks for the reply. But doesn't what you say contradict the spec:

The setext heading underline cannot be a lazy continuation line in a list item or block quote:

?

nojb avatar Oct 19 '18 05:10 nojb

No, there is no heading underline. There are just three equality signs which do not form the heading exactly because of the rule you are quoting.

mity avatar Oct 19 '18 05:10 mity

Since it is no heading underline, it is a normal line of text. With dashes instead, it could be a bullet list or thematic break as well, but with equals signs, the possibilities end there.

Crissov avatar Oct 19 '18 05:10 Crissov

@jgm

If you read just the rule

The setext heading underline cannot be a lazy continuation line in a list item or block quote

then you can interpret it indeed in two ways, if you are inside a blockquote and you see a line === (without leading >):

  1. you should enforce ending of the blockquote so that you can see the === as a heading underline; or
  2. you should degrade the equality signs and see them as ordinary chars.

Of course the example 62 says the 2nd interpretation is the right one.

But I remember that when I was implementing MD4C, it took me also some time to understand it. Maybe this issue shows human mind can easily choose the wrong interpretation 1 and then just see the example 62 in a prejudiced semi-blind way, as just something different then expected after reading the rule, ergo concluding there is something wrong with the specs.

Maybe some clarification of the rule should be considered?

mity avatar Oct 19 '18 05:10 mity

Thanks people, I understand now 😄

nojb avatar Oct 19 '18 06:10 nojb