Change of behaviour in link parsing - a breaking change?
Closed this issue · 3 comments
I've been using email links like the following in my raw markdown
[info@website.com](<mailto:info@website.com?subject=Turf Availability Enquiry>)
these worked up till commit 3b46d71 where behaviour has changed. I now have to encode the subject part, encoding the spaces in the subject, prior to this commit the library correctly parsed and output a correctly formed mailto link.
I don't mind encoding where I have to, but ultimately this raw markdown will be entered and maintained by end users whom I don't expect to understand or know about encoding.
This matches the specification (see try.commonmark.org, though you might need to refresh the page after loading).
This was changed in CommonMark specification 0.24, the release notes mention two related discussions:
Disallow spaces in link destinations, even inside pointy braces. Discussion at http://talk.commonmark.org/t/779 and http://talk.commonmark.org/t/1287/12
Thank you, I thought that might be the case, the spec took a bit to decipher and wasn't sure if I read it right.
If I were to undo that commit so as to allow spaces in <> links, do you know if there would be any implications to the library correctly parsing other markdown? Or even better how could I go about implementing (an extension?), spaces in query parameters for <> links?
I would probably advise against that since that would go against the goal of CommonMark which means that the same markup can be used everywhere. By the way, the spaces in the links are supported only in a few parsers: http://johnmacfarlane.net/babelmark2/?normalize=1&text=%5Bfoo%5D(%3Casd+asd%3E)