4 ms·

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 dat

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.

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.