4 ms·

For text inputs and select dropdowns, yes, we take them for granted because the simple case is simple -- but there really is so much complexity in keyboard navi

For text inputs and select dropdowns, yes, we take them for granted because the simple case is simple -- but there really is so much complexity in keyboard navigation and interaction. Reaching parity in a JS implementation would be a serious undertaking and would usually not be the right thing to do. However, there are some controls, like date and color inputs, whose browser implementations are both inconsistent and severely UX-challenged such that no professional web site/app would really be able to use them in production. For these, in 2022, we still have no choice but to build custom implementations in order to meet usually expectations.

julianlam 5y ago
I don't understand this sentiment. Why would it matter whether the UX is different between browsers for a date or colour input? In the end, if it inserts a date, or a hex colour representation, then I am happy. Although now that I think about it, there's a chance a date input would return `mm-dd-yyyy` or `dd-mm-yyyy` depending on locale. To have it return a unix datetime would probably be easier for everybody.
- grenoire 5y ago
  The browser date pickers will always return YYYY-MM-DD to your server when they send a request. What's exposed to the user is usually localised. This is the behaviour you want.
- p49k 5y ago
  > I don't understand this sentiment. Why would it matter whether the UX is different between browsers for a date or colour input? It’s not just a question of consistency: some of HTML UI elements are still in pre-alpha stage in modern browsers, almost completely broken, despite being part of the standard for many years. It’s a joke. For an example, check out the RANGE element; you will find no shortage of articles complaining about how ridiculously broken and unusable it is.
  - tentacleuno 5y ago
    > For an example, check out the RANGE element; you will find no shortage of articles complaining about how ridiculously broken and unusable it is. Could you shed some more light on this? I couldn't find anything from a cursory search. Looking at the W3Schools demo[0], it doesn't look too bad (other inputs set the bar really low). Is it not very friendly with styling? I hear that a lot when people talk about native browser controls. [0]: https://www.w3schools.com/tags/tryit.asp?filename=tryhtml5_input_type_range https://www.w3schools.com/tags/tryit.asp?filename=tryhtml5_i...
- 9dev 5y ago
  Tangent: I wonder why, after having standards like ISO 8601 for decades, stuff like this is something we even have to think about. On a technical level, there's a need for exactly two date time formats: Monotonically increasing integer timestamps, and ISO 8601 style date time with timezones.
Karellen 5y ago
A native date input might be inconsistent between different browsers, or different OSs, but it will be consistent with the native date input on every single other website the user goes to. If they're lucky, it will be consistent with the date input field on every other application on their OS. The only intuitive interface is the nipple. Everything else is learned. If the user has leaned how to use the native date picker on their browser, they know how to use the date picker on your website. If you make them learn how to use a new date picker for your website, it's very unlikely they'll thank you for being able to transfer this unique knowledge to that one website of yours on the very unlikely chance they choose to switch browsers. I mean, who does that regularly? And if the native date picker in their browser doesn't work for them - maybe because aesthetics, maybe because accessibility - they can either pick a different theme for their browser, or pick a different browser. (Or a different OS!) That has the advantage of fixing the native date picker on every single website they go to. Except for the annoying websites which implement their own, where if the custom date picker doesn't work for them, they're fucked. If someone's using a browser with an date picker you happen to dislike, that's their choice. Let them have it.
- dmitriid 5y ago
  > And if the native date picker in their browser doesn't work for them - maybe because aesthetics, maybe because accessibility - they can either pick a different theme for their browser, or pick a different browser. Or, you know, if aesthetics or accessibility doesn't work with a native picker I might just use a third-party one instead of requiring my users to switch browsers and OSes. Native date input have horrendously/hillariously bad implementations in all desktop browsers. I can't even begin to imagine thinking about using them for anything.
  - Karellen 5y ago
    Someone with particular accessibility needs might not be using a popular desktop browser - they'll already be using a user-agent which is adapted to their own needs. If you use native input elements, then whatever accessibility needs a user might have can be accommodated by a user-agent which caters to those needs. And you get that to take advantage of that for free. If you roll your own, you can't cater to people with disabilities that you haven't considered.

julianlam 5y ago

I don't understand this sentiment. Why would it matter whether the UX is different between browsers for a date or colour input? In the end, if it inserts a date, or a hex colour representation, then I am happy. Although now that I think about it, there's a chance a date input would return `mm-dd-yyyy` or `dd-mm-yyyy` depending on locale. To have it return a unix datetime would probably be easier for everybody.

grenoire 5y ago
The browser date pickers will always return YYYY-MM-DD to your server when they send a request. What's exposed to the user is usually localised. This is the behaviour you want.
p49k 5y ago
> I don't understand this sentiment. Why would it matter whether the UX is different between browsers for a date or colour input? It’s not just a question of consistency: some of HTML UI elements are still in pre-alpha stage in modern browsers, almost completely broken, despite being part of the standard for many years. It’s a joke. For an example, check out the RANGE element; you will find no shortage of articles complaining about how ridiculously broken and unusable it is.
- tentacleuno 5y ago
  > For an example, check out the RANGE element; you will find no shortage of articles complaining about how ridiculously broken and unusable it is. Could you shed some more light on this? I couldn't find anything from a cursory search. Looking at the W3Schools demo[0], it doesn't look too bad (other inputs set the bar really low). Is it not very friendly with styling? I hear that a lot when people talk about native browser controls. [0]: https://www.w3schools.com/tags/tryit.asp?filename=tryhtml5_input_type_range https://www.w3schools.com/tags/tryit.asp?filename=tryhtml5_i...
9dev 5y ago
Tangent: I wonder why, after having standards like ISO 8601 for decades, stuff like this is something we even have to think about. On a technical level, there's a need for exactly two date time formats: Monotonically increasing integer timestamps, and ISO 8601 style date time with timezones.

Karellen 5y ago

A native date input might be inconsistent between different browsers, or different OSs, but it will be consistent with the native date input on every single other website the user goes to. If they're lucky, it will be consistent with the date input field on every other application on their OS. The only intuitive interface is the nipple. Everything else is learned. If the user has leaned how to use the native date picker on their browser, they know how to use the date picker on your website. If you make them learn how to use a new date picker for your website, it's very unlikely they'll thank you for being able to transfer this unique knowledge to that one website of yours on the very unlikely chance they choose to switch browsers. I mean, who does that regularly? And if the native date picker in their browser doesn't work for them - maybe because aesthetics, maybe because accessibility - they can either pick a different theme for their browser, or pick a different browser. (Or a different OS!) That has the advantage of fixing the native date picker on every single website they go to. Except for the annoying websites which implement their own, where if the custom date picker doesn't work for them, they're fucked. If someone's using a browser with an date picker you happen to dislike, that's their choice. Let them have it.

dmitriid 5y ago
> And if the native date picker in their browser doesn't work for them - maybe because aesthetics, maybe because accessibility - they can either pick a different theme for their browser, or pick a different browser. Or, you know, if aesthetics or accessibility doesn't work with a native picker I might just use a third-party one instead of requiring my users to switch browsers and OSes. Native date input have horrendously/hillariously bad implementations in all desktop browsers. I can't even begin to imagine thinking about using them for anything.
- Karellen 5y ago
  Someone with particular accessibility needs might not be using a popular desktop browser - they'll already be using a user-agent which is adapted to their own needs. If you use native input elements, then whatever accessibility needs a user might have can be accommodated by a user-agent which caters to those needs. And you get that to take advantage of that for free. If you roll your own, you can't cater to people with disabilities that you haven't considered.