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.
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.
Even with intl.regional_prefs.use_os_locales set though, the date field still shows "dd/mm/yyyy" in the placeholder despite my locale/region settings telling it to use ISO (yyyy-mm-dd).
At least on macOS, I have not checked how it appears on Linux yet.
And as the other poster says: Basing locale decisions on display language is entirely incorrect and ignorant, it would only be acceptable as a fallback if no specific locale/region settings are available.
It seems that in Firefox, they have decided that date and time formatting follow the browser's language instead of the OS settings
I find it incredible that this kind of thing is not being standardized by WHATWG. Today Mozilla decides one thing, tomorrow Chrome another, then whatever Brave is doing. As a webdev i'd stick with the JS date picker even if each vendor's decision was reasonable.
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.
Firefox has a setting to ignore target=_blank. However it will break a few sites (but that is quite rare) and I don't think is officially supported. I love it because I always know where a link will open. (and it's my choice!)
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.
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.
(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
This sounds shockingly similar to an old post I have on the subject. For a second I thought it was a rip-off, but turns out that it is just a common concern 🙂
Things seem to be getting better on average, but still too often I see "links" that I can't open in a new tab.
Nicd | a day ago
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.
I tried the picker on the website in two browsers and they both show me
mm/dd/yyyyformat 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:configto editintl.regional_prefs.use_os_localesso 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!).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).
motet-a | 23 hours ago
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.Sharparam | 23 hours ago
Until the browser date fields/pickers properly respect the OS locale settings I don't foresee any big adoption.
Nicd | 22 hours ago
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.lonjil | 20 hours ago
But language and locale are two totally distinct concepts, that's silly :/
Sharparam | 18 hours ago
Even with
intl.regional_prefs.use_os_localesset though, the date field still shows "dd/mm/yyyy" in the placeholder despite my locale/region settings telling it to use ISO (yyyy-mm-dd).At least on macOS, I have not checked how it appears on Linux yet.
And as the other poster says: Basing locale decisions on display language is entirely incorrect and ignorant, it would only be acceptable as a fallback if no specific locale/region settings are available.
untitaker | 15 hours ago
I find it incredible that this kind of thing is not being standardized by WHATWG. Today Mozilla decides one thing, tomorrow Chrome another, then whatever Brave is doing. As a webdev i'd stick with the JS date picker even if each vendor's decision was reasonable.
JulianSildenLanglo | a day ago
The color picker on Firefox Android is utter shite.
mariusor | a day ago
I think it respects the
prefers-darkcss media selector, not the site's theme.chrismorgan | a day ago
It’s supposed to follow the CSS
color-schemeproperty, which is appropriately set todarkhere. Every platform I know of does this; not sure what’s up with Nicd’s report, unless it just got fixed.Nicd | 13 hours ago
On my Ubuntu system today, Vivaldi showed the date picker as dark and Firefox as light. On macOS both Vivaldi and Firefox followed the site's theme.
fleebee | 23 hours ago
diktomat | a day ago
… 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.
kevincox | 16 hours ago
Firefox has a setting to ignore
target=_blank. However it will break a few sites (but that is quite rare) and I don't think is officially supported. I love it because I always know where a link will open. (and it's my choice!)https://kevincox.ca/2023/04/24/browser-link-open-newwindow/#enforcing-your-choice
hongminhee | 23 hours ago
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
hrefand add anonclickhandler that callspreventDefault()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.
adam_d_ruppe | 21 hours ago
Try
auxclickevent. I made a little demo webpage for youhttps://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
clickandauxclickevents 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
#evilin 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
JulianSildenLanglo | 21 hours ago
Oh, that's how websites do that. Thanks I hate it.
But seriously thanks for showing me how though.
hongminhee | 16 hours ago
Thanks, I didn't even know
auxclickexisted. I'll try it on Hackers' Pub, and the two-links idea is worth a look too. The cannon icon made me laugh.graph_ | 9 hours ago
Could you perhaps, display two links? One for the mirror-post and one for the remote-post? No fancy machinery required and no complaining power users.
reezer | 23 hours ago
I think on lobste.rs it's a bit preaching to the choir. ;-)
juliethefoxcoon | 10 hours ago
A bit of preaching is nice on a friday, isn't it?
sincerely, the choir
kevincox | 15 hours ago
This sounds shockingly similar to an old post I have on the subject. For a second I thought it was a rip-off, but turns out that it is just a common concern 🙂
Things seem to be getting better on average, but still too often I see "links" that I can't open in a new tab.