When you write example.com in a post it automatically works as a link in a post. (meaning it looks like a link and clicking on it takes you to that site).
It looks like a link but there is in fact no link (meaning clicking on it does nothing).
Did this change recently? Someone on our forum noticed that we have a bunch of links like this that are (now?) not working.
NOTE: My example above is when using the Markdown editor (if that wasn’t obvious). When I use the rich wysiwyg editor and just paste example.com in the link dialog box, the link works.
Are you sure that e.g. [link](example.com) ever worked? I know markdown containing relative links, e.g. [link](/u) to link to the user list on a site, does work.
I am not! The only clue I have, if you can call it that, is that I have been frequently posting links like that to a site in that way (i.e. without the https://) and this is the first time anyone has ever mentioned it. Maybe no one was ever clicking on my links!
Would you agree that one should not have to include the https:// in a markdown link?
I don’t see anything in the common mark standard that mentions it: CommonMark Spec
Pedantically speaking, I think this the behaviour is acceptable. There’s not enough information by itself to distinguish between relative or a hostname.
A link contains link text (the visible text), a link destination (the URI that is the link destination)
example.com is not a valid URI by itself, even though if you type example.com by itself it’ll get turned into a link. That’s convention not specification though, since pineapple.belongson.pizza is also a valid hostname (well, it was until I let the domain expire) but doesn’t get auto-linked.
relative URI (with or without ./) these are valid markdown, but our parser forbids it [relative](../../386082) relative [relative](./386082) relative [relative](386082) relative
absolute URI [absolute](https://www.example.com/foo.html) absolute
schemeless URI (similar to relative, but explicitly relative to only the scheme) [schemeless](//www.example.com/foo.html) schemeless
Arguably, this is the correct behaviour. Without any sort of anchoring at the front, it’s a path relative to the current location, same as [link](./example.com).
Yeah, that was my (hopeful!) justification for why the markdown links should also do that. But I’m slowly accepting the fact this isn’t going to happen (and that it never did).
I just tried on Reddit and without the https:// it doesn’t even make it a link at all.
I guess the only thing I would still have to suggest is that it not look like a link if it isn’t going to be a link (which is the current behaviour). This seems to be the least helpful of all options, although better than being a relative link. I think the Reddit behaviour of not being a link at all might be best, unless it can detect that it should be a relative link to something on the site itself.
Hmm… Not that it’s a huge deal, but I’ve also gotten used to using something like[foo]() for illustration purposes which renders as foo.
I feel like the problem here is the mismatch in expectations given the “linkify” site setting. Not sure how best to untangle this one, but I’ll share it with folks thinking about these edges cases in the composer to that it’s at least on their radar to consider.
I wouldn’t have that mismatch, but I understand it.
I expect markdown to do exactly what I’m saying: [link] means render the following as a link; it’s up to me to put a valid URL in there.
I expect the composer to do a bit of magic: this looks like it’s meant to be a URL so I’ll mark it up as a link.
This has become natural to me, but I certainly see potential for confusion. Maybe similar magic could be applied to validate the format of markdown links before linkifying them.
Sure. But I think that most users would expect [link](example.com) to create a link to example.com. Putting example.com in the browser url bar works. And just typing it into a post also works.
these are valid markdown, but our parser forbids it
