Hacker News Reader

Comment by CM30 | Hacker News Reader

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.

View on HN

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

Is a "decimal comma" a thausands separator, or is it a decimal-point for locales where that is expressed by a comma?

It's the separator between the whole and fractional parts of the number.

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

It's not universal, that wouldn't be complicated enough!

IE 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)

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

Hi, I'm one of the engineers working on date/time fields [0] (you can see the design document for them here[1]) for Firefox. We're on the way to support them and hopefully support them well.

Now, I also happen to be working on refactor of our Intl code, so I should be able to help with the number field being inconsistent. If you can file a bug and prepare a minimized testcase, I'd be happy to fix it! :)

[0] https://bugzilla.mozilla.org/show_bug.cgi?id=888320 [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1069609

Hey @zbraniecki, thanks for the work you're doing. I use type=number cautiously for self-built tools for my own use, but so far have avoided it in production code. Thanks to your effort maybe someday I'll be able to use this 'for real'!

I 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!

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

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

Well, 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)

Do not look at Excel when thinking about appropriate handling of dates and times.

It makes a fantastic checklist of things you shouldn't do while handling dates though!

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

Why ISO? JavaScript has had a Date type since forever.

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

Ahyes, I'm so stuck in JS-o-world that I forgot there's an actual text format called HTML. Thanks :-)

Why the format the site owner wants? Why not the format the user wants?

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

WPF Datagrids have a "currency" format. This defaults to dollars regardless of your locale.

Reply on news.ycombinator.com