A well-written design system is a godsend for end-user consistency, especially for people who use assistive technologies and are easily forgotten about by inexperienced teams. It also means that teams can focus in on the problem they’re actually trying to solve, and stop obsessing over the common components.
I was only around for the first six months or so of this project, but I’ve taken so much of what I’ve learnt into my current design system, and I continue to reference GDS’s continuing work as the gold standard for researched user interface patterns.
Some of UX guidance is really good and should be in fact part of the HTML spec.
> Do not use <input type="number"> unless your user research shows that there’s a need for it. With <input type="number"> there’s a risk of users accidentally incrementing a number when they’re trying to do something else - for example, scroll up or down the page. And if the user tries to enter something that’s not a number, there’s no explicit feedback about what they’re doing wrong.
> Do not set the inputmode attribute to decimal as it causes some devices to bring up a keypad without a key for the decimal separator
Also, sad to realise that some of core UX features for HTML, like entering numbers, is so broken three decades later.
> The type=number state is not appropriate for input that happens to only consist of numbers but isn't strictly speaking a number. For example, it would be inappropriate for credit card numbers or US postal codes. 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. When a spinbox interface is not appropriate, type=text is probably the right choice (possibly with an inputmode or pattern attribute).
I think browsers messed up the implementation of number by adding increments and spin box things. I wish they would just show a numeric keypad on mobiles, and on desktop restrict input to 0-9, optionally 1 decimal point and an optional '-' prefix, and otherwise present as a normal text box.
If it makes sense for an increment button, it's pretty easy to add with JS, or it could be an optional attribute. I can't remember a case where the increment buttons were useful.
However, after reading it several times, I don't like it. The heuristic "consist of numbers but isn't strictly speaking a number" isn't useful.
If HTML5 describes information semantics, labels should reflect the term's common usage rather than jargon for specific heavily caveated use cases— Credit card numbers and phone numbers aren't exactly edge cases.
I guess that means text is wrong, too? It seems like the current definition of text is "the type of input you'd put in a text input even if it's only numerals" and the definition of "number" is "incrementable or decrementable." Seems like it should be "general" and "quantitative" or something. Weird slightly counterintuitive instances such as "date fields are the quantity of days, months, or years since X" make more sense than "social security, credit card numbers, phone numbers, id numbers, etc. aren't numbers" to my eye.
> If HTML5 describes information semantics, labels should reflect the term's common usage rather than jargon for specific heavily caveated use cases— Credit card numbers and phone numbers aren't exactly edge cases.
Ideally, yes, we'd have better semantics, but I wouldn't really blame HTML5. In all of computing we don't really have a succinct term for a data type that happens to contain mostly or only numerical digits but isn't actually referring to a numerical quantity (or ordinal, etc.). I see this mistake in software all this time. Someone will add a "social security number" field somewhere as a numerical data type, and some frontend somewhere will format it with delimiters like "123,456,789". Incidentally, that's my goto way to explain the distinction: if you would want to format the number with comma delimiters, it's probably actually a number. Credit cards and phone numbers aren't edge cases, but they're very clearly examples of data that should not be modeled as numbers.
> "Credit cards and phone numbers [...] should not be modeled as numbers."
Agreed that they shouldn't be modeled as a numeric data type. The actual field behaviors are also appropriately implemented for their respective data types in the browsers. I wouldn't so quickly absolve HTML5, though.
The type field describes the purpose of the data, not its 'data type'. Most people consider the term "number" very general and treating it as a special type of value with specific uses and properties is an artifact of software development. HTML isn't a templating language that processes data, and in my experience, many creators and consumers of HTML are not software developers.
The rest of the values are consistent with that intent, maybe except text and to some extent local date and time: Hidden, Text, Telephone, URL, Email, Password, Date, Month, Week, Time, Local Date and Time, Number, Range, Color, Checkbox, Radio Button.
What are the really common uses of "numbers?" Product quantities? Currency? I can't think of much else— certainly nothing people would normally label using the word number. What are very common fields that aren't numbers? Credit card numbers, phone numbers, social security numbers, account numbers, ticket numbers, reference numbers, confirmation numbers...
The label makes sense to people who write application logic using variables where whether something is or isn't a number is really important. To everyone else, labelling a phone number 'text' makes much less sense than labelling a telephone number a number.
> To everyone else, labelling a phone number 'text' makes much less sense than labelling a telephone number a number.
In some jurisdictions there’s a strong culture of having phone numbers represented as text - so they’re easier to remember. Especially popular for toll free numbers.
I presume that this culture has lead to the popularity of overlaying the alphabet over numeric keypads, for banking machines and payment terminals. As a result, I remember some of my associated pass codes as words, not as numbers.
So there are some real world scenarios where a human thinks a word, while the data item is a number.
Good call. Definitely all the more reason to avoid using the word "number" to approximate the limiting, specific way developers use it when that doesn't line up with general usage.
I don't think anyone is suggesting that a user interface should refer to a phone number field as "type: text" or whatever. Of course that would be confusing.
This entire thread is about the type= property of an HTML input field. Nowhere did I or anybody suggest that this be presented on the webpage. The users in question are users of HTML markup, not users of the webpages written in that HTML.
One category I can think of is called "code". Credit card, SSN, could be the same category as zip code. Anything number that does not in calculable semantic (e.g. index, id)
> Credit cards and phone numbers aren't edge cases, but they're very clearly examples of data that should not be modeled as numbers.
"Clearly" is debatable. Regardless of how you input the data itself, nothing is stopping you from parsing and encoding it to a valid number of a certain type in a certain range.
Encoding it as something different than numbers seems even more dangerous and I have not seen yet an argument for it that goes beyond the input.
Some places have phone numbers that are variable length and can start with a zero. If you store these as numbers, this will drop the leading zero and result in an incorrect phone number.
Phone numbers aren’t numbers. Numerical values can be written as sequences of digits, but not all sequences of digits are numerical values.
Maybe a better, clearer heuristic is if leading zeroes change the meaning. For a credit card number, 0002 != 2 therefore a credit card “number” is really a string. For a linear regression calculator, 0002 = 2, meaning you can use the number field here.
I think the real problem is that the heuristic needs to exist. The label "number" makes sense to developers because we have a mental model for the type of data that goes in those fields. However, it excludes many things most non-developers would call numbers, and they are far more common uses for HTML inputs. I don't think it makes sense for that to be a facet of HTML5 when a more appropriate label would do the job.
I'm not saying they are. I proposed using different labels for fields containing data types we treat as numbers and another for fields containing other strings, even if they only contain numerals and aren't really 'text.'
People writing HTML shouldn't need to know about data types— they're describing the semantics of data and not instructions for handling it. That the label number does not apply to the vast majority of input fields with number in their name— cc number, phone number, account number, etc.— is a naming failure. It's an implementation detail that opposes common usage and it should be changed.
`number` also unlocks the ability to use a numerical input on a mobile phone. In fact, I imagine this is why there's so many websites using it inappropriately on desktop: because it makes the mobile experience better.
If I was maintaining the HTML spec, I'd do two things:
- Deprecate the use of spinboxes on `number` input. Browser vendors would be free to remove the spinbox or only support it in certain circumstances
- Add an explicit `interface` attribute (or equivalent CSS properties and psuedoelements) for specifying the kinds of input UI the form author expects to be available to the user. You'll be able to apply multiples of these and to any form input type (including <select> and <textarea>) without changing their validation rules. The browser picks out options that make sense for the current platform and input type and implements those.
Interface hints themselves would be things like:
- `keyboard` - widget should support virtual input and/or IMEs (on a select, this would also trigger a combobox)
- `numeric` - implies `keyboard`, plus virtual input should be optimized for numbers (on a phone, this means give the user a numeric keyboard)
- `text` - implies `keyboard`, plus virtual input should be optimized for text of the input widget, document, or user's current language
- `nokeyboard` - widget should not support virtual text input of any kind
- `increment` - widget should have numeric increment/decrement buttons (e.g. use a spinbox)
- `noincrement` - widget should omit numeric increment (no spinbox)
- `content` - contents of the field should be visible to the user (even if the field is type=password; this would allow a "show password" box that does not expose the password to predictive text input)
- `obscured` - obscures the text input like type=password
- `nocontent` - contents of the field are entirely hidden, would allow hiding even the length of a password
- `predict` - widget should participate in predictive text
- `nopredict` - widget should NOT participate in predictive text, and should not have it's input be fed back into the predictive text system, like type=password
- `passwordrecall` - widget should support password recall through a password manager
- `nopasswordrecall` - widget should NOT support password managers
The only time I can think of when you'd want to block a password manager / form filler is when it gets the heuristic wrong. It's why autocomplete=one-time-code exists.
Things like an admin form in a web app - I might be setting the password for a new user account, but it's not my password, so I don't want my browser to store it.
One-time codes or temporary passwords are another example where the password manager may think it's worth saving, despite being used once.
This is good advice in practice but I don’t think the HTML spec should be concerned with bad browser implementations. Writing semantically incorrect HTML in order to coax the browser to behave in a certain way should be discouraged by the spec, I would say. Instead, browser vendors should be encouraged to fix their UI.
I was only around for the first six months or so of this project, but I’ve taken so much of what I’ve learnt into my current design system, and I continue to reference GDS’s continuing work as the gold standard for researched user interface patterns.