It may be a big change, but could I argue in support for duplicate links being supported? That is,
Go check out [link].
go check out [link].
would produce two unique links.
The rationale is that Markdown documents should be composable. That is, if I concatenate two Markdown documents and compile them, it would be ideal if the output was roughly similar to just concatenating the output. (Mathematically,
markdown(a) + "\n\n" + markdown(b) ~= markdown(a + "\n\n" + b)). This is ideal, because when copying and pasting various documents together, it would be ideal to not need to make global changes to the document. The current spec means that the links in the second document will be broken in the presence of duplicate label names.
An additional rationale is that allowing duplicate labels allows users to have short, “anonymous” labels for links, such as “1”, “2”, etc. This prevents users from having to either: (1) always use inline links or; (2) always invent globally unique labels for their links.
The [foo] is rather [bar].
The [baz] is still [zapped].
This proposal will introduce some challenges, such as “in the fact of duplicates, which link should be attached to which label?”. I don’t think there is a fully composable solution to this. I humbly suggest the following algorithm, however:
- A link uses the first label defined after it appears.
- If no label appears after a link, the link uses the closest label defined above.
For example, the following markdown:
using this spec should compile to:
The rationale for this algorithm is that in my survey of Markdown documents, people tend to define labels after the corresponding link. Rule (2) provides backwards compatibility for documents that define links before, and don’t currently use duplicates.
Thoughts on this proposal would be appreciated.