Parentheses in link destination of link reference definition

I believe there is a mismatch between the behavior defined by the spec and the dingus reference implementation with regards to the link destination of a link reference definition.

According to the spec, a link destination can, “includes parentheses only if (a) they are backslash-escaped or (b) they are part of a balanced pair of unescaped parentheses.”

For example, the following does not qualify as a proper link destination because it has an unescaped, unmatched left parenthesis.


It should be parsed as a paragraph with no link, which is what the dingus outputs.


So far so good. Now let us look at the spec’s definition for a link reference definition.

A link reference definition consists of a link label indented up to three spaces, followed by a colon (:), optional whitespace (including up to one line ending), a link destination…

Given that the definition of a link destination is shared between inline links and link reference definitions, I would expect the following to not produce a link.


[abc]: a(

Yet sure enough, it does in the dingus!

<p><a href="a(">ref</a></p>

To me, this seems like a deficiency in the spec, a bug in the reference implementation, or both. Am I missing something here?

The implementation makes sense and if the specification does not reflect that it should indeed be fixed. Compare with link titles: they can be put inside double quotes "", single quotes '' or parentheses () and which characters need to be escaped inside depends on the delimiters used.

Commonmark is not really internally consistent, though, when it comes to syntax restrictions that are only required for one syntactical variant but not the other. Someone restrictions are applied consistently throughout, e.g. absolute URLs required inside angle brackets even when not free standing autolinks but inside a online link or a link definition, and sometimes they apply selectively, e.g. nested links allowed in image references but not in textual links.

1 Like