6 ms·
This reminds me of another HTML input type that's really poorly implemented across browsers. Namely, date and time input fields. In that case, it varies so muc
by CM30 10y ago
This reminds me of another HTML input type that's really poorly implemented across browsers. Namely, date and time input fields.
In that case, it varies so much across browsers to be almost unusable. Some (like Firefox) don't seem to support the calendar aspect, some have a terrible calendar UI, some fallback to the device calendar UI, some let you select invalid dates despite greying them out and that's before you get to the actual data, how it's formatted or the lack of any events associated with the fields.
Honestly, it seems like today's browsers just can't seem to handle any of the newer input types in any reasonable way.
- nattaylor 10y agoI think this is because its so difficult to support all the different options, like languages and different calendars ...but you're right: getting English + Gregorian consistently right would be a start!
- kuschku 10y agoThat alone is hard. I’ve got a version of Chrome here that, if you query with .value from JS the value of a datetime-local field, returns you a String in "MM/DD YYYY" format. Despite the user’s locale being de_DE. I’ve also discovered one browser only supporting ISO8601, and another only support it if one removes the time section of it. Another only if you have a time section, but remove the time zone part at the end. It’s such a horrible mess.
- jstanley 10y ago> Despite the user’s locale being de_DE. Surely you're not suggesting that the representation of the date that is returned by the browser should be locale-dependent? That would be a nightmare.
- kuschku 10y agoWell, it’d be less of a nightmare than returning it in a random locale! At least when it’s locale-dependent I can use a look up table and parse it somehow, but getting it back in MM/DD YYYY? I’d love to just get ISO8601 ideally, btw, but who knows if that will ever happen. (Also, you should check out Microsoft Excel, its date type and CSV converter are both locale-dependent. Locale of the program opening the file, not the file itself. A file created in de_DE will be unusable in en_US)
- TeMPOraL 10y agoOne would think it should be simple in principle. User side: just show/accept whatever the site owner wants, or if it's too difficult, stick to ISO 8601 (it's the standard, damn it). JS side: just ISO 8601.
- skrebbel 10y agoWhy ISO? JavaScript has had a Date type since forever.
- TeMPOraL 10y agoSo Date type, then, but if we're talking input fields, they're also meant to be used with forms submitted without all that JavaScript cruft on top. So if you have to convert the date input to text for sending (or direct retrieval in code), I'd say just stick to ISO. Why? Because it's a standard.
- skrebbel 10y agoAhyes, I'm so stuck in JS-o-world that I forgot there's an actual text format called HTML. Thanks :-)
- hibbelig 10y agoWhy the format the site owner wants? Why not the format the user wants?
- TeMPOraL 10y agoThat could be a reasonable default, but you need to give the programmer control over the format, or else everyone will keep using JS-powered replacements.
- adrianratnapala 10y agoWPF Datagrids have a "currency" format. This defaults to dollars regardless of your locale.
- janci 10y agoNot only date/datetime/time fields are broken. Also type=number does not work consistently across different locales and different browsers. Some don't let you type decimal comma.
- adrianratnapala 10y agoIs a "decimal comma" a thausands separator, or is it a decimal-point for locales where that is expressed by a comma?
- heinrich5991 10y agoIt's the separator between the whole and fractional parts of the number.
- rhizome 10y agoI'm not sure this is universal, but locales which use a period for a thousands separator use a comma as a decimal point, and vice-versa.
- m_t 10y agoIt's not universal, that wouldn't be complicated enough!
- edoceo 10y agoIE doesn't understand max attribute. Sometimes marks an error with large (but inconsistent) value. Id est: use max="100000". Then on one IE/Edge 16000 is an error but 15000 is OK. Different IE/Edge box its 18000 cap. I have to make a custom UI component to make this work (riotjs)
- freditup 10y agoAlso with type=number fields: some support showing a leading "0" while others don't. Seems like a small detail, but it all adds up to death by a thousand cuts and custom implementations of everything.
- 10y ago