6 ms·

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 thi

by dukoid 4y ago

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

londons_explore 4y ago
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.
- mimsee 4y ago
  > 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
- edent 4y ago
  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.
benjaminjosephw 4y ago
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.
- danuker 4y ago
  > 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.
  - Cthulhu_ 4y ago
    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.
    - danuker 4y ago
      > with a scroll wheel as well This happens to me accidentally while scrolling. Then I order the wrong quantity and such.
      - deleted 4y ago
        [deleted]
- Cthulhu_ 4y ago
  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.
  - avereveard 4y ago
    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
JetAlone 4y ago
A workaround can just as easily become tacitly expected domain knowledge that serves to obfuscate both the problem, and its solution, sadly :/
- danuker 4y ago
  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.
stncls 4y ago
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.)
jfoster 4y ago
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.
- butlerm 4y ago
  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.

by dukoid 4y ago

londons_explore 4y ago

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.

mimsee 4y ago
> 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
edent 4y ago
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.

benjaminjosephw 4y ago

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.

danuker 4y ago
> 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.
- Cthulhu_ 4y ago
  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.
  - danuker 4y ago
    > with a scroll wheel as well This happens to me accidentally while scrolling. Then I order the wrong quantity and such.
    - deleted 4y ago
      [deleted]
Cthulhu_ 4y ago
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.
- avereveard 4y ago
  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

JetAlone 4y ago

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

danuker 4y ago
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.

stncls 4y ago

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

jfoster 4y ago

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.

butlerm 4y ago
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.