Hacker News Reader

Comment by dukoid | Hacker News Reader

I think most of these issues should really be fixed in browsers though... And when they are, people will probably still point to this page for years... Hope this helps to bring visibility to the problems though...

View on HN

I think the thing to remember here is that inputs should only be `type=number` where the semantic value is best represented with a numeric scale, not just where it is a number only field.

> A simple way of determining whether to use type=number is to consider whether it would make sense for the input control to have a spinbox interface (e.g. with "up" and "down" arrows). Getting a credit card number wrong by 1 in the last digit isn't a minor mistake, it's as wrong as getting every digit incorrect. So it would not make sense for the user to select a credit card number using "up" and "down" buttons.

I don't think browsers can infer the semantic intent enough for this to be a fixable problem without some distinction in syntax.

> e.g. with "up" and "down" arrows

I never used those except for testing to see what they do. They are always useless to me.

Depending on browser, they can be used with a scroll wheel as well. And of course, on mobile they will have different UI elements. But yeah I don't get the tiny up/down arrows either.

> with a scroll wheel as well

This happens to me accidentally while scrolling. Then I order the wrong quantity and such.

Yeah exactly, a phone number or credit card number may look like a number, but they're not. input type number will also discard leading zeroes, for example.

That said, I feel like the organizations behind HTML gave up too fast; they should have continued with input types for phone numbers (that e.g. phone manufacturers could then integrate with contacts without revealing anything to the website in question), credit card numbers (supporting all formats and with built-in format validation), etc. But they seem to have stopped 10+ years ago with HTML5's broken number input.

Enumerating types might be cool for semantic web, but what I'd love as a dev is a system for enumerating valid characters, so I can put digits and dashes, or only Latin letters, and the device figures out the best keyboard to use

The article gives two reasons for the choice:

> 1. Accessibility

Here I agree with you that it feels like a workaround. Well, technically, it is not the browsers that need fixing, but rather Dragon Naturally Speaking and the NVDA screen reader.

> 2. Incrementable numbers (the fact that long series of digits get reinterpreted as large numbers, which causes all sort of issues, like them being reformatted in scientific 1.23e+45 notation)

Here instead it feels more like a legitimate things both on gov.uk's part and on the browser's part. "Numbers" and "long series of digits" are fundamentally different things, and it seems normal that they would be described with different input fields. (Now how those input fields should be named, that I am not qualified to have an opinion on.)

A workaround can just as easily become tacitly expected domain knowledge that serves to obfuscate both the problem, and its solution, sadly :/

All the while SOME people use the browsers' implementation, and the browsers become an ever-increasing spaghetti of complexity and security holes that everyone is mandated to use.

I wonder if Gov.UK works with browser makers?

They do pretty extensive usability testing, and if I was a browser maker I'd listen to what they had to say.

Yes, in a way. When I worked for GDS, I was their representative to the W3C. There are still a number of people there who are on various W3C committees where - I assume - they regularly interact with browser makers and other interested parties.

> I wonder if Gov.UK works with browsers?

You mean works with browser developers? Otherwise I can't see the reason why their site wouldn't work on modern browsers. Especially given the lengths they'll go to make sure it's as accessible as possible.

Edit: formatting

Agree with you, but also, for how many decades should they wait for browsers to get their shit together? It's not as though input type="number" is particularly new.

In retrospect, they should have left all these special input types out and let application developers handle it with Javascript. There are too many real world cases they cannot handle, and real world knowledge probably shouldn't be hard coded into web browsers in the first place. The date entry is an example of something that is particularly useless - it is not flexible enough.

I don't want the browser to know or dictate what date format to use, that is the application's job, and the date input doesn't even let web applications specify the format. So you have a substantial engineering effort half implemented across a handful of browsers that approximately no one can use.

Reply on news.ycombinator.com