Short version – neither of these produce a code-ized rendering of an autolink:
`<http://foo.bar/>` (1)
<`http://foo.bar/`> (2)
I think that rendering URLs in a code font is a popular, yet it is impossible to do with the current spec (and with cmark, which I’m playing with ATM). It at least bothers me as someone who’s used to the tt-font-indicates-computer-stuff.
Some obvious ways to deal with it:
Make (1) render as a code-font link. This is bad since it makes backquotes have an exception to the rule of “the contents is left as-is”.
Make (2) render as that, and more generally any URL in the backticked text gets rendered as an autolink. This seems to me to be a bit better, but there is a similar expectation for the contents of angle braces to be left as-is.
Add a single exception to make (2) work, so that <`...`> essentially becomes another form of an autolink, only rendered as code. This is harmless for existing functionality since the allowed URL schemes are limited (even more than “alphabetic”), and changes to existing texts seems minimal. [The only problem I can imagine is some exiting text that has a convention of code in angle braces, and some code happens to look like a URL.]
I hope that #3 makes enough sense, but if not, and if things are left as they are now, it would be good to add this as an explicit example for something that cannot be done.
(Labeled as “Spec” since it seems to me too minor to be considered an extension.)
and you can use CSS to make links with the “uri” class render with a monospace font…or not. (In the case of cmark, I’d favor adding something to the API that indicates whether a link is an autolink; renderers could use this information as they see fit.)
I don’t like the idea of treating either your (1) or your (2) as an autolink. Adding exceptions makes things more complicated and harder to remember, and should only be done if there’s no good alternative.
That (the class= thing) is limited in that you get it for everything, so no control over specific instances… (BTW, wouldn’t class="autolink" make more sense?)
As for (1) and (2) – I’m sorry, I should have been clearer… Yes, I don’t like them, just specified them as non-solutions.
I prefer (3), or something else that I haven’t thought about, but if (3) is unacceptable and there’s no other way, then I think that (4) the spec should say that explicitly, as it does provide negative examples for many things already.
(Also, apologies for the bad formatting. I can never remember the specific rules in each site’s markdown, and I’m composing text off-browser in Emacs… That’s why I like the idea of standardizing the damn thing…)
That (the class= thing) is limited in that you get it for everything, so no control over specific instances… (BTW, wouldn’t class="autolink" make more sense?)
I can see the rationale for wanting all autolinks to be formatted monospaced, but I don’t see the rationale for wanting some to be formatted that way, and others not.