Link reference definitions woes

The specification talks a bit what can or cannot come before a link reference definition, but less about what can come after.

For example I fail to understand this rendering:

[foo]: /ha 
    bla

which is (and consistently with cmark and md2html):

<p>bla</p>

I would have expected an indented code block to be rendered. Similarly this rendering:

[foo]: /ha
---

Yields in the dingus:

<p></p>
<hr />

I would have expected a simple <hr />. Also both cmark and md2html render this as:

<p>---</p>

(my impression is the cmark and md2html’s behaviour is an artefact of their implementations, which is to gather a paragraph, peel any initial sequence of link reference definitions and treat the remains as a paragraph).

So what are the rules that govern the behaviour for what comes after a link reference definition ?

Yes, you’re right, these things are a result of an implementation shortcut:

I agree that the spec doesn’t define this precisely enough. The cmark behavior is to treat the following lines as they’d be treated if parsed as continuation lines in a paragraph. So e.g.

% cmark
ha
 1. blah
^D
<p>ha</p>
<ol>
<li>blah</li>
</ol>

but

% cmark
[foo]: ha
 2. blah
<p>2. blah</p>

(Remember that only ordered lists starting with 1 can interrupt a paragraph.)

Similarly in

[foo]: /ha
    bla

we don’t have a code block for the same reason that we don’t in

foo
    bla

I think this is reasonable behavior and maybe it should be enshrined in the spec. But comments welcome. The empty <p> in the JavaScript implementation can be regarded as a bug.

Thanks for our answers.

Apparently there’s already an issue filed for it.

I have a conflict of interest in being for this so I’ll refrain from commenting :–) but I think it would be nice if there was a common behaviour for parsers on these (likely) corner cases.


P.S. I forgot to add the spec tag when I posted this other topic but it is also a request for clarification of the spec. If you have time to have a look at it that would be great.