14 ms·
Why the Gov.uk Design System team changed the input type for numbers (2020)
- dukoid 5y agoI 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 5y agoI 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 5y 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 5y agoYes, 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 5y agoI 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 5y 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_ 5y agoDepending 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 5y ago> with a scroll wheel as well This happens to me accidentally while scrolling. Then I order the wrong quantity and such.
- deleted 5y ago[deleted]
- Cthulhu_ 5y agoYeah 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 5y agoEnumerating 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 5y agoA workaround can just as easily become tacitly expected domain knowledge that serves to obfuscate both the problem, and its solution, sadly :/
- danuker 5y agoAll 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 5y agoThe 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 5y agoAgree 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 5y agoIn 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.
- ldoughty 5y agoThis is very interesting... I'm really happy to see this kind of information published as a blog post, with reasons and explanations... I read through and forwarded a link to it to our UI team, and all the data is there justifying the change.
- tontonius 5y agothis was on just a while ago..? https://news.ycombinator.com/item?id=22433654 https://news.ycombinator.com/item?id=22433654 I hereby coin the term "pseudo déjà vu" – when something feels like a déjà vu but its actually for real.
- pxeger1 5y agoThat's over 2 years ago now. A bit more than "just a while ago", and perfectly fine to repost IMO.
- Jaruzel 5y agoThat's over two years ago and I don't recall reading it at the time. I think there's some sort of 'soft' rule about dupes though, if its less than a few months.
- notRobot 5y ago> when something feels like a déjà vu but its actually for real. ...isn't that just remembering?
- zxcvgm 5y agoThe article shows an example of a credit card field being a "number". Having made several online purchases, I realized I'm now frustrated by a CC number field that doesn't allow any spaces or dashes, or doesn't format it visually this way for you. They should just allow dashes/spaces then strip it using JS or at the backend. There is a reason that the number printed on the credit card is grouped into 4 digits, and I believe that it makes human parsing easier. When I submit the form and it says "invalid card number", trying to figure out which digit I mistyped into the form while scanning that long string of digits with my eyes, gazing at the card and back at the screen is just stupid.
- masklinn 5y agoPreach. Any input which might as well be random (CC, phone numbers, keys, fingerprints, …) should allow for formatting otherwise anything beyond 4 characters gets very hard to validate and correct. If it auto-formats that may be fine, although lots of these have very culturally dependent formattings (phone numbers are a prime example here) so freeform formatting is definitely better. It’s also important to realise that lots of things which are numerical (sequences of digits) are not semantically numbers e.g. leading zeroes are relevant in a phone number or CC number, and incrementing or decrementing either is nonsensical.
- joosters 5y agoSame goes for phone numbers too. When I enter a phone number into a field, only to be told on pressing submit that 'phone number cannot contain spaces', I despair for technology. So your form accepts spaces, and you made your website check for spaces, but simply removing them is beyond the capabilities of your code? Websites suck.
- twic 5y agoIn the UK, bank accounts have a thing called a sort code, which is six digits, conventionally grouped into three pairs, separated by hyphens (eg 08-92-73). It seems to be completely random whether an input for these will be a text box which requires hyphens, a text box which forbids hyphens, three tiny text boxes which you have to tab between manually to enter each digit pair, or three tiny text boxes where JavaScript automatically moves the focus to the next after you have entered two digits. Naturally, you cannot reliably paste into any of them. But then, my bank has disabled copying everywhere sort codes are displayed anyway!
- pwdisswordfish9 5y agoThe phrasing in the standard they quote: > The type=number state is not appropriate for input that happens to only consist of numbers but isn't strictly speaking a number. sounds like silly self-contradictory nonsense, probably written by someone who didn’t know words like ‘digit’ or ‘quantity’, which would help tremendously to disambiguate this. (Ideally, it would have been <input type="quantity"> from the start, so that nobody would even think of using it for digit-based identifiers.) Seriously, thesauri can be occasionally useful for something beyond sounding smug. (Not that it isn’t an advantage in itself…)
- foreigner 5y agoRelated: I've been struggling for a long time to figure out the best way to implement a currency amount input. In my case I only need to support a single currency (USD), e.g. $9.99. Should it be type=number? type=text? Should I add an input mask? I haven't been able to find a clean answer I'm happy with.
- the_gipsy 5y agoTry the combination of the article - it is what you want.
- foreigner 5y agoBut that won't show the dollar sign ($). It would also allow bogus fractional-cent values like 9.999. And it would display values like 9.9 (one decimal place) instead of the correct $9.90 (two decimal places).
- pas 5y agocan't you use regex to only allow two decimal places?
- the_gipsy 5y agoMaybe take out the dollar sign from the input-value. Or just adjust the regex. Or just validate with js/serverside.
- 568ml 5y agoIf you’re only supporting USD, I would prefix the input with the dollar symbol, I.e. so that it appears to the left of the input rather than as a part of the input itself. This signals the website is accounting for the fact that the given value must be a quantity of USD. You can use a type=number input and prevent bogus fractionals by setting the ‘step’ attribute on the input to ‘0.01’. This will do two things: the up/down clicker buttons will increment/decrement by 0.01, which IMO is all they’re useful for, and the browser should restrict values to two decimal spaces. Of course you still need to validate this on the backend.
- Lior539 5y agoOn a side note, the Gov.UK site is one of the best sites Ive come across, especially for a government. It's incredibly simple and easy to navigate. It's easy to find any information you're looking for and all information is explained in very clear and simple english (unlike many other government sites, which are convoluted and fill of jargon). IMO this is the gold standard for government websites
- pbhjpbhj 5y agoOne failing, which I think it's significant, is that pages which are written as authoritative do not specify where they derive their authority from. Specifically, what I'm thinking of is finding information that says something is obligatory or forbidden but doesn't say what laws/rules/customs/departments make this the case. More links to legislation.gov.uk would improve the democratic status of the website.
- twic 5y agoAgreed. Only yesterday i wanted to know what the actual legal rules about working time are; starting here, the top Google result, it's a dead end: https://www.gov.uk/maximum-weekly-working-hours https://www.gov.uk/maximum-weekly-working-hours
- switch007 5y agoAbsolutely. This is an excellent point. I’m sure it’s no accident either. And it only got worse during the pandemic when the Gov purposefully tried to conflate their word with the law, using gov.uk to do so.
- bombcar 5y agoThe IRS does this too; you can ask the IRS for their opinion on a tax matter, and they can give you a letter that states their position; which is a defense if you follow it, but it's not necessarily how the courts would rule. Many times it is worth following the letter of the law and being ready to defend it in court.
- 5y ago
- spaniard89277 5y agoI really like the effort gov.uk puts on it. IIRC there's a similar thing getting traction in Italy. Why can't we have anything similar in Spain? Some regional governments already have with more or less success but central state services are a complete mess. No consistence at all, and some websites are so badly made that if feels like it was the intent. AFAIK there isn't a lowest bid system anymore, so why is everything so difficult? Just imagine being able to worry because some stuff doesn't work with screenreaders...
- pbhjpbhj 5y agoThere are some negatives too. The design pattern doesn't work well for some specialist websites that get jammed into the gov.uk mould. Overall though, it's better than the mish-mash of styles and the duplication of effort across many different departments and levels of government.
- swiftcoder 5y agoI feel this in my bones. Working on my Spanish tax return, and agencia tributaria's site has some of the most diabolical form validation I've ever encountered. They validate onblur and clear the field + popup an error dialog whenever validation fails - which triggers every single time I alt-tab out to my financial statements... grr
- spaniard89277 5y agoAnd Hacienda is one of the most widely used interfaces. Wait till you have to use some obscure system. Luckily some other level of government made another interface for the same system cos they got tired of it.
- aynsof 5y agoWe had a similar thing in Australia - the Australian Government Design System: https://designsystem.gov.au/ https://designsystem.gov.au/ It is in use across a huge number of Australian government websites - the Australian Cyber Security Centre, Services Australia, Department of Health, Department of Veterans' Affairs to name just a few. The agency that owned it had a huge amount of funding cut from its budget, and now it's being supported by an (admirable!) open source effort: https://designsystemau.org/ https://designsystemau.org/ It's wonderful that there is this level of community support, but so disappointing that the government couldn't recognise the importance and usefulness of continued funding.
- Svip 5y agoAnother problem with `type="number"`, that this blog post does not mention - although for good reason (it's British) - is that different versions of Android will provide either "." or "," decimal pointer, depending on locale or not at all. Some phones - regardless of how much you insist on a comma-locale - would still provide "." as the only option. Eventually, we had to switch to `type="text" inputmode="numeric"` and interpret both "." and "," as a decimal separator. Most people won't bother to enter thousand separators anyway. These numbers were amounts, i.e. actual numbers, and not text fields with only digits, so `type="number"` doesn't even work for actual numbers, as soon as you move beyond English.
- ht85 5y agoIf you handle the data programatically parseFloat will always work as expected. No good solution for native submit though :/
- tgv 5y agoSpinning can be prevented (by attaching event handlers), and the spinner buttons can be hidden. The disadvantage of the proposed solution is the lack of (automatic) feedback. Browsers tell you when the a number input exceeds the min/max range, in the browser's default language. If you want to validate a text input field and tell the user the number is too low or too high, you'll need to provide your own translated text.
- ezfe 5y agoYes...but that has a flipside: "Credit card number must be less than 9999999999999999" is completely useless, and you can't customize that.
- tgv 5y agoI'm not saying that you should use a number input for credit cards. That's an identifier that happens to consists of digits, not a number. But for things like age, or number of items?
- jfoster 5y agoWhat's very disappointing about many of these problems is that it's browsers being really dumb & hostile to users. Chrome suddenly changing the number format, Safari trying to "auto-correct" numbers. No one asked for these "features".
- kijin 5y agoMany of the (relatively) newfangled HTML input types exhibit this kind of half-baked behavior, coupled with a surprisingly stubborn lack of extensibility. type="number" doesn't support thousands separators in any meaningful way. type="date" and type="time" only display their values in the user's system locale, not the locale of the page. There's no way to change the format. type="color" doesn't support RGBA and can't be in an empty state. If you try to unset its value, it always defaults to #000000, even in dark mode. type="email" and similar text-like types don't offer any feedback for invalid values until you try to submit the form. No wonder people are just using type="text" and relying on Javascript to achieve reasonable behavior.
- ezfe 5y agoWhile true that they don't show the feedback, you can use `.validationMessage` to retrieve it and show it yourself. Also, input type=email has been in Firefox, Chrome, and Safari for over a decade. It's not exactly new.
- mattlondon 5y agoTIL about inputmode="number" - this is great! https://developer.mozilla.org/en-US/docs/Web/HTML/Global_attributes/inputmode https://developer.mozilla.org/en-US/docs/Web/HTML/Global_att... I wish more sites used appropriate inputmodes - it is often a pain in the backside to enter numeric information on mobile.
- yohannparis 5y agoExactly! This is an amazing attribute.
- brundolf 5y agoMidway through the article I was just thinking, "they should add something to the standard that lets you control which native keyboard is used for a field without all this other semantic baggage" Lo and behold! Probably going to use this at work today :)
- codedokode 5y agoI'd like to note that identifiers like passport number, phone number, or a credit card number, are not really numbers (despite the word "number"). Number is something the represents a quantity (for example, 3.5 km). Credit card number or phone number is not a quantity, it is just an identifier, a string made of digits. For example, there are phone numbers that start with zero (like 02), and the leading zeros would be lost if you try to convert it into an integer. So if you need a database field or a variable for such identifier, you should choose a string type, not numeric.
- silvestrov 5y agoMy proposal: * a type=count which is used for specifying a "count of things". This is the only type that should display arrow up/down as the current type=number does. The arrows must be easy to remove because sometimes add/remove 1 does not make sense. To avoid problems with rounding, browsers must restrict min/max to be +/- 1e15 so the value always fits safely into a double (due to javascript numbers). Some people will have an objection to this, but how many times do you specify a count that is bigger than 1e15? Browsers could present an optimized UI (e.g. a dropdown) when e.g. min=0 and max=10. * a type=digits which as default allows for digits, dashes, spaces. Useful for creditcard numbers. Having this as distinct type makes it easier to get good keypad on mobile. * a type=price which is optimized for input for money as the general type might not be good at giving good error responses for "too many decimals". Could have currency as attribute for display on mobile input for countries which use multiple currencies and therefore having this displayed is important. * a type=int which is used for integers to make it easy to make sure the number is an integer. Current html requires too many attributes for this common task. * a type=number which is used for any other kind of number.
- sangeeth96 5y agoI had submitted a proposal [1] to add type="digits" last year, when I was faced with similar issues designing TOTP/PIN controls. Didn't gain much traction though. [1] https://github.com/whatwg/html/issues/5209 https://github.com/whatwg/html/issues/5209