Space between link destination and link title in link reference definitions

[ScottAbbey]

Section 4.7, Link Reference Definitions, specifically states the following:

an optional link title, which if it is present must be separated from the link destination by whitespace

When both the C and Javascript CommonMark implementations are presented with the following input:

[a]

[a]: <te>(st)

They produce this output:

<p><a href="te" title="st">a</a></p>

It can't be correct to consider (st) a link title here, because it isn't separated from the link destination by whitespace. I would have expected the <te>(st) fragment to be treated as a link destination of the non-<...> variety with one set of unescaped, balanced parentheses.

I am reporting this here since both reference implementations disagree with the spec, so perhaps the spec requires modification. If the spec is indeed correct as written, we can file the same issue at both reference implementation repositories.

After some careful consideration, it appears this requirement may have been intended to make implementation of link reference definitions easier, avoiding the need to handle special cases like:

[a]

[a]: te(st
)

when still trying to figure out whether this is a link reference definition or just a piece of text.

Some variations on the above examples are here to show that they apply to various versions of the link destination and text. Note that for examples j and k, the C reference implementation disagrees with the Javascript one.

I have not thoroughly read the section of the spec about link destinations and link titles that are inlines rather than in link reference definitions, but in one quick test, it appears that the rule requiring whitespace between a link destination and a link title is enforced in those cases. That leads me to believe that the spec in this case is correct and both reference implementations are incorrect.

Does anyone have more insight?

[jgm]

I think you're right, this is an implementation bug.

[jgm]

Reopening because we should have an example like this in the spec.