# Link reference definitions woes

**URL:** <https://talk.commonmark.org/t/link-reference-definitions-woes/4338>\
**Category:** Spec\
**Created:** [November 30, 2022, 3:06pm UTC](https://talk.commonmark.org/t/link-reference-definitions-woes/4338 "2022-11-30T15:06:12Z")\
**Posts on this page:** 1\
**Showing post:** 3

<div class="post-metadata">

**Author:** ![dbuenzli](https://cdn.commonmark.org/user_avatar/talk.commonmark.org/dbuenzli/32/2353_2.png) [@dbuenzli](https://talk.commonmark.org/u/dbuenzli)\
**Post date:** [November 30, 2022, 4:56pm UTC](https://talk.commonmark.org/t/link-reference-definitions-woes/4338/3 "2022-11-30T16:56:17Z")

</div>

Thanks for our answers.

> [@jgm](#):
>
> The empty `<p>` in the JavaScript implementation can be regarded as a bug.

Apparently there’s already an [issue filed for it](https://github.com/commonmark/commonmark.js/issues/262).

> [@jgm](#):
>
> The `cmark` behavior is to treat the following lines as they’d be treated if parsed as continuation lines in a paragraph  
> […]  
> I think this is reasonable behavior and maybe it should be enshrined in the spec.

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](https://talk.commonmark.org/t/example-126-confusion-autoclosing-fence-blocks/4335) 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.

---

_[View the full topic](https://talk.commonmark.org/t/link-reference-definitions-woes/4338)._