Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

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.



> 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.


> 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_i...


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.


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.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: