Please don't mess with links
48 points by gavinmorrow
48 points by gavinmorrow
The article says not to roll your own date picker and I want to sympathize, because on mobile it generally does work in my experience. On desktop the experience is not terrible anymore, but there are a couple of statements that I would not be so absolute about.
This will always used the user's preferred date format
I tried the picker on the website in two browsers and they both show me mm/dd/yyyy format and a calendar that starts the week on Sunday, even though my time format is set to Finnish time.
In Firefox I had to go to about:config to edit intl.regional_prefs.use_os_locales so that it would inherit my OS time format (why on earth do I have to do this?) to fix the date picker. You might say this is a browser issue, but by using the standard widget you inherit such browser issues. So I don't wonder why site developers might opt for more control (just give me the native one on mobile!).
also, it's one line of code that works with dark mode by default.
Firefox shows me a white date picker even when using the site's the dark theme. It might be affected by my OS setting of a light theme, but that means another point of incompatibility with the rest of your site design (I might want to keep some sites in dark theme).
Moreover <input type="date"> is widely supported since 2021 or so, this wasn’t a long time ago. This explains why a ton of websites are still using JavaScript date pickers.
Until the browser date fields/pickers properly respect the OS locale settings I don't foresee any big adoption.
It seems that in Firefox, they have decided that date and time formatting follow the browser's language instead of the OS settings (source: https://superuser.com/a/1804828), and since the browser language is only a single setting, you can't change the different formats separately. There is the preference I mentioned (intl.regional_prefs.use_os_locales) to control this, but I feel like this shouldn't be needed. Being able to control language and other locale formats separately should be basic functionality.
the site's the dark theme
I think it respects the prefers-dark css media selector, not the site's theme.
It’s supposed to follow the CSS color-scheme property, which is appropriately set to dark here. Every platform I know of does this; not sure what’s up with Nicd’s report, unless it just got fixed.
However, with a real <a target="_blank"> link, I can:
… not open the link in the same tab. So please refrain from using both js abominations and target blank, to allow me to choose the target myself.
I run Hackers' Pub, an ActivityPub social network, and I ended up on the other side of this argument.
Like many fediverse servers (Mastodon included), Hackers' Pub shows remote posts on a mirrored page of its own. The timestamp on a remote post in the timeline links to that mirror, which is where you can reply to or like the post from your account. Those interactions only work from our side. The catch is that someone who wants to share the post and uses the browser's “copy link” on the timestamp gets the mirror URL, not the original permalink on the remote server. I didn't like that, since the canonical URL is what people actually want to pass around.
My workaround was to put the original permalink in href and add an onclick handler that calls preventDefault() and navigates to the mirror instead. Copying the link yields the original URL, and a plain click still lands on the mirror. I was fairly pleased with it for a while.
It is exactly the kind of thing the article complains about, though, and some of our users have said so. Open the link in a new tab (Ctrl + click, middle click) and the handler never runs, so they land on the original page on the remote server. Reading works there, but they can't reply or like, which was the reason they wanted the mirror in the first place.
I haven't found a clean fix. Part of it is a limitation of the fediverse today: the remote server's page knows nothing about your account here. Still, I sometimes wish a link could carry one URL for copying and another for navigating. I'd expect that to be abused within a week, so I'm not seriously asking for it.
Try auxclick event. I made a little demo webpage for you
https://arsdnet.net/auxclick.html
It also adds an event ("contextmenu") for right click, but you might not want to keep that one since a lot of your users might right click to copy link target, and that defeats the whole point. But the click and auxclick events are both solid maybes for you to consider.
Note that ctrl+click and middle click often do the same thing, but the events might not be the same; I see ctrl+click triggering the "click" event here and middle click is "auxclick". Keyboard triggering of a link does just trigger the "click" event though.
see also: https://developer.mozilla.org/en-US/docs/Web/API/Element/auxclick_event
(tbh i called it #evil in the demo link cuz i also don't like this, i think my preference would be to have two links, like your logged in link then a sharable link next to it or something (if i wanted to be cute, i'd use a little picture of a cannon as its icon, lol blast out that canonical link) but that might be hard to make space for it so meh.)
My demo does NOT use preventDefault because the event handler is run before the defalt event. You can rewrite the link then let the default handler run and it will navigate normally to the new link, observe how you land on #evil instead of #good.
But the downside of this specific approach is if you middle click to open in new tab, then copy/paste, you'll get the evil link. You could preserve the original link somewhere like in another property/attribute of the node, then on a blur and/or mouseout event, reset it to the original. That might work for you but you can experiment from here, breakfast time for me lol
Oh, that's how websites do that. Thanks I hate it.
But seriously thanks for showing me how though.