I have also noticed this apparent inconsistency. Maybe only the creator of Markdown knows the answer.
Anyway, I guess that the optional spacing of [link text][link label] cannot be removed from the spec because it would break compatibility.
As to your last example, I think the spec now resolves the ambiguity (but probably not when you asked the question).
By the way, shortcut reference links are new to me. I think they weren’t in the original Markdown syntax, so I guess they are a common extension in Markdown variants.
By the way, shortcut reference links are new to me. I think they weren’t in the original Markdown syntax, so I guess they are a common extension in Markdown variants.
They were introduced by John Gruber and were supported in Markdown.pl 1.0.2b8 from 2004. The only Markdown implementation I know of that doesn’t support them is Markdown.pl 1.0.1.
I bumped to this issue many times in my texts. I like references. In my texts, I add a lot of references: to chapters, to Wikipedia articles, to glossary at the end of a document, to 3rd-party sites, etc. After all, I am writing for www, and links is a core feature of web. Most of my links are “shortcut reference links”, If one shortcut reference links follows another ([a] [b]), markdown processor (I usually use pandoc) interprets it as one reference link with text a and label b.
It is very confusing. I have submitted a bug, but jgm said it is a feature — it is the way the original markdown works.
However, I do not see rationale for such interpretation. To me it looks inconsistent.
I understand jgm argument about backward compatibility, but I believe allowing a space between link text and label is a mistake. It hardly possible to fix it in original markdown, but it can be fixed in CommonMark.
I’d actually be in favor of fixing this. Shortcut reference links have been standard for a decade now, and I doubt there are many texts out there with reference links separated by a space. So my guess is that the pain of this slight break from backwards compatibility would be minimal. And the advantages would be large: it’s very common to want to have two consecutive links, so this quirk (should we keep it) will bite a lot of people going forward.
I’ve been using the following markdown to render email links with a prepopulated subject line. [info@website.com](<mailto:info@website.com?subject=Turf Availability Enquiry>)
this worked until I updated the library I was using, the author said this change was due to the spec having been changed.
Whilst I understand that there is a requirement for different characters to be encoded in query strings, the entry and editing of the markdown content will be done by end users with no knowledge of what needs to be encoded. To me, this encoding is something quite fundamental and something that could easily be handled automatically by the spec and libraries, and transparent to users.
Your comment really belongs in a separate thread, as it has to do with whether whitespace should be allowed in a URL in a link. This thread is about something else.
One reason for not allowing unescaped spaces is to avoid ambiguities with the URL and title fields.