Crissov
January 3, 2018, 12:23am
13
Overall, this idea is seen favorable upon. Maybe, however, we should really ask a related, more general question:
Should link reference definitions completely vanish?
Mainly to support extensions (e.g. for footnotes, abbreviations, definitions/glossaries, bibliographies), I believe they should be kept at least in the AST and perhaps even invisibly in HTML output:
[foo]: foo
[bar]: <>
[baz]: "baz"
[quuz]:
.
<a id="foo" href="foo"></a>
<a id="bar" href=""></a>
<a id="baz" title="baz"></a>
<a id="quuz"></a>
The example does not address the problem of DOM clobbering mentioned before.
https://github.com/commonmark/CommonMark/issues/172
opened 12:56PM - 18 Dec 17 UTC
closed 08:32PM - 10 Jan 20 UTC
The spec v0.28 clearly states that [link destinations](http://spec.commonmark.or… g/0.28/#link-destination) inside angular brackets can be the empty string:
> A link destination consists of either
>
> - a sequence of zero or more characters between an opening `<` and a closing `>` that contains no spaces, line breaks, or unescaped `<` or `>` characters …
[Dingus]/Commonmark.js and cmark do not support this yet, while markdown-it does. The specified behavior may be beneficial for future extensions, e.g. footnotes or info strings for links or general inline markup.
[Dingus]: http://spec.commonmark.org/dingus/?text=%5Blink%20text%5D%5Blabel%5D%0A%0A%5Blabel%5D%3A%20<>%20"title"
When a link reference definition does not match any link reference, it is still treated as a link reference definition, but because there is no matching link reference, it will not appear in the output.
I agree that it would be worth being explicit about this in the spec. Could you put up an issue on jgm/CommonMark so I won’t lose track?
https://github.com/commonmark/CommonMark/issues/454