qpixel
qpixel copied to clipboard
codidact
Can we be more conservative when generating links to things that could be URLs?
https://meta.codidact.com/posts/284033
Our markdown code creates links for things that look like URLs. But it does so inconsistently (example.com and example.info linkify, but example.test doesn't). And there's no way short of code formatting to bypass it if you were really just trying to refer to some SE site on meta as something.SE.
The post here asks to turn off linkification, but I don't think we want to do that when the user clearly did type a URL. Can we create links when a URL scheme is present and not if it isn't? If you type http://example.com that should be a link, but plain old example.com shouldn't be. Maybe it's a post about configuring your email, after all; a naked domain name isn't always a web page.
On one hand the auto-linkify is overzealous; on the other, it's there so that you can just type a bare domain without a scheme and have it link correctly, which can be helpful for non-technical users.
What if we added some pre-processing instead, such that if you type something.se it will link (because it should, because .se is a ccTLD), but if you type {something.se} it won't link (probably by adding a zero-width space before sending it for MD processing)?
That sounds like a good approach -- leave the linkifier alone, but provide some markdown syntax that prevents it from firing. What do you think about using parens instead of braces, so that the syntax is "MD link but without the link text = no link" -- i.e. a normal link would be [some text](URL), so we're saying that if you reduce that to just (URL) you don't get a link. That might be easier for people to remember? It does mean that if somebody meant to put a URL by itself in parens and wanted a link, that won't work, but that seems uncommon.
I think in some markdown variants there's also the syntax <URL> to mark text to be linkified (and not linkifying plain URLs). Given that that is already somehow "common", I'd prefer such a solution instead of developing a new one...
@luap42 Slightly different - <text> marks text that should be linked. My thought is that {text} marks text that shouldn't be linked.
@cellio I'd be slightly cautious of using regular parens, since they could be used in normal text too - you might be providing an example link in parens and suddenly it doesn't link and you're not sure why. On a similar line to <> for not linking, {} are also very rarely used in normal text.
Err... probably my bad for writing that message in the morning on my mobile phone.
Here's what I mean: When we already have the commonly accepted pattern of <URL> being converted to an link at broader criteria than normal text, then we should just raise the bar for normal text to be linkified.
So here's my proposal: If something is not 99%-ly an URL (aka very likely to be one), we should only linkify it if
- the URL is written in formal link style (
[text](url)) or - the URL is enclosed by
<and>.
This would be compatible to other Markdown implementations and wouldn't introduce new, special syntax.
@luap42 Problem is that we don't have that much control over the linkifier. It comes from our markdown gem, so the only options are on, off, or fork the gem and write the functionality ourselves (which is a massive PITA).
@luap42 I wasn't aware there was a convention in some markdown flavors already. I'm a big fan of being consistent with known conventions when we can.
In the versions that linkify <url>, what do they do with plain URLs in text -- treat them as text? I'd be fine with that, actually. That is, we would support two ways to get links: [text](url) as now, and <URL>, and anything else that looks like a URL we wouldn't try to linkify. If people were expecting links and didn't get them, there's an easy edit that fixes it. @ArtOfCode- , is that consistent with the options you listed for the linkifier? Or do you mean that if we don't want naked URLs to linkify then we would also lose the explicit links in [...](...), which would be bad?
The only issue I see there goes back to what I was saying earlier about schemes: <text> requires a scheme to create a link. <example.com> won't link to anything; <https://example.com> will link there and display as https://example.com - the only way to generate a link that displays as a domain is to use [example.com](https://example.com). It's not a massive issue, but for non-technical users it's a slight barrier.
@ArtOfCode- given that for the {plaintext} proposal we'd have to add some filters/regexps too, would it be too complex to detect <url> codes that are not auto-linkified and then convert them to the [url](url) format?
@luap42 Yes, unfortunately - <text> could be a HTML tag, which is also valid Markdown.
@luap42 Problem is that we don't have that much control over the linkifier. It comes from our markdown gem, so the only options are on, off, or fork the gem and write the functionality ourselves (which is a massive PITA).
You aren't actually using the markdown gems though? All of the rendering is done client-side via. markdown-it, last I checked.