
Why the Gov.uk Design System team changed the input type for numbers - joelanman
https://technology.blog.gov.uk/2020/02/24/why-the-gov-uk-design-system-team-changed-the-input-type-for-numbers/
======
ChrisSD
In summary the main issue is that, according to the spec, `<input
type="number">` is only for numbers that are going to be parsed into a
Javascript number. It has to make sense to increment, decrement or do other
numerical operations on it. It's not to be used for strings or identifiers
that just so happen to be numbers, e.g. credit card numbers. I'll admit this
is slightly surprising to me but it does make a certain amount of sense.

The solution is to use `<input type=”text” inputmode=”numeric”
pattern="[0-9]*">`.

~~~
downerending
One good reason for this is that for things like credit card numbers, a good
interface will accept leading, trailing, or interior spaces. Sites that make
me type in values in exactly their own weird format are an abomination.

Site A: _Ah ah ah! You put a slash in your date! No soup for you!_

Site B: _Ah ah ah! You didn 't put a slash in your date! No soup for you!_

~~~
DonHopkins
I hate it when they have drop-down menu for entering your year of birth, so
the older you are, the further you have to scroll, but only infants and
toddlers can select the year they were born without scrolling.

A non-numeric text field is so much easier, and you should also be able enter
your birth year as Roman numerals (which is even easier for millennials).

~~~
mc3
Gen Z are the ones born on MM or later.

~~~
DonHopkins
OK, MMer! ;)

~~~
mc3
I'm closer to MTV than MM

~~~
DonHopkins
So OK MMMBopper? ;)

------
signalsmith
This is off-topic, but I _really_ like the current GOV.UK (several years old
now). I don't really have opinions on the visual stuff, but I find it really
pleasant to use.

Filing my self-assessment tax return (only required because I run a side-
business) is a fantastically straightforward experience. Step-by-step
information entry, pre-filled with what they already know (e.g. main
employer's salary), then they give you a number at the end which you pay by
card.

Having done the paper version exactly once before moving over to doing them
online, I feel grateful every time I see that distinctive custom font.

~~~
jackdeansmith
As a US guy, I've never looked at this site before. The extreme clarity of
pages like [https://www.gov.uk/vat-rates](https://www.gov.uk/vat-rates) is
really refreshing.

~~~
lioeters
Indeed, that's a nice example. I felt the design could even improve public
relations. If I were a UK citizen, I'd be relieved to find the information so
well-designed and presented.

I've read here and there about the UK Government Digital Service, and have a
very good impression. Reading a recent related article, it sounds like they
have their priorities right!

[https://gds.blog.gov.uk/2019/11/05/transforming-gov-uk-
the-f...](https://gds.blog.gov.uk/2019/11/05/transforming-gov-uk-the-future-
of-digital-public-services/)

~~~
dmix
The UK has long been an early adopter of proper web design for government
websites.

Seeing the average Canadian gov website, and hearing stories from people
who've worked on some at the federal level, makes my head hurt.

~~~
frosted-flakes
The Canadian and provincial governments are getting better though. See the
OSAP (Ontario Student Assistance Program) application page, which is fully
mobile and vastly simplified from the hot mess it used to be. Also, just look
at [https://ontario.ca](https://ontario.ca) in general, which is clearly
inspired by Gov.UK.

~~~
dmix
All it takes is one group to do it right and everyone wants to copy them.

Good job UK, this Ontario site looks like a semi rip-off of the gov.uk sites
(which is a good thing).

Everything slowly gets better online, it just takes time.

------
vitaliyf
Similarly, here is your reminder than US Zip Codes aren't numbers, because
many of us here in the Northeast have them start with a zero (or even two). So
don't store them as integers, because Boston is 02108, not 2108.

See
[https://en.wikipedia.org/wiki/List_of_ZIP_Code_prefixes](https://en.wikipedia.org/wiki/List_of_ZIP_Code_prefixes)

~~~
drstewart
My general rule is if you can't add two values together then they shouldn't be
represented as number types.

~~~
pwdisswordfish2
So a temperature is a number only as long as it's expressed in kelvins?

~~~
elcomet
you can add farenheihts or celcius.

~~~
lmkg
You can meaningfully add or subtract degrees to a temperature reading, but you
can't meaningfully add two readings together (unless you're averaging them!).
There's a subtlety here: A temperature _difference_ is actually a different
data type than a _temperature_. Dates and times have similar issues: You can
add 2 hours to 3 hours, and you can add 2 hours to 3 o'clock, but you can't
add 2 o'clock to 3 o'clock.

A better litmus test is whether you can _subtract_ values. The difference
between two times, or two dates, or two temperature readings is something that
is meaningful and commonly used in everyday life. The difference between two
ZIP codes is nonsensical.

~~~
kaoD
> unless you're averaging them!

Nitpicking, but that seems like a great case for them being numbers. You will
never average credit cards or zip codes. Averaging times is meaningful too
(e.g. the mean arrival time).

I think op meant "adding" as generally doing math on them. Each quantity will
have its own natural operations.

I see what you mean though, subtraction seems like a good heuristic by virtue
of difference being mostly (always?) meaningful.

------
alexrage
It's good to see UX design problems analyzed from a technical perspective.
Designers working on the web should be proficient at understanding the medium
on which they work, and look beyond generating static images to toss over the
wall for implementation.

------
shakna
> However the inputmode attribute is now supported by all the mobile browsers
> we test in.

This isn't extensive, which might be a tad misleading if you don't double
check. They test on Chrome & Samsung for Android, and iOS is only the one
engine.

And those three browsers seem to be the only mobile browsers that have
implemented it. (Well, Opera Mobile as well). [0]

Desktop support is also extremely spotty.

This seems like it might be leaping the gun on expecting this standard to pick
up the slack.

Whilst they might feel the support is there for their particular audience
after 2019, I wouldn't, and would suggest that you need to check your
particular audience closely before following this advice for your own site.
(Which is fairly generic advice, but appropriate.)

[0] [https://caniuse.com/#feat=input-
inputmode](https://caniuse.com/#feat=input-inputmode)

~~~
joelanman
The article covers quite a few issues with type=number, including some pretty
bad accessibility ones. On balance I think even if inputmode doesn't have 100%
support, those users will simply get a normal keyboard, which isn't so bad.
Disclaimer - I work on the team.

~~~
vidarh
Yeah, for my current work app we've just unceremoniously dropped type=number
for most things, without inputmode or anything, and the experience is overall
so much better even then.

~~~
samatman
I wish you'd use inputmode.

I find it vaguely unsatisfying when I'm asked to input a pure string of digits
using a full keyboard on mobile. It feels half-baked, and my estimation of the
quality of the software goes down.

------
globular-toast
Using "numeric" types for strings that look like base 10 numbers is an
incredibly common mistake. It's one of those mistakes that works 99% of the
time, which means it can become deeply embedded in architectures. We've
recently seen this problem when a database for the first time for a non-
numeric system in its ids and downstream systems that converted that to an
integer started to fail.

My rule of thumb is that if it doesn't make sense to do arithmetic on it then
it's not a number, it's probably a string.

~~~
reggieband
> We've recently seen this problem when a database for the first time for a
> non-numeric system in its ids and downstream systems that converted that to
> an integer started to fail.

I can add another anecdote to that list. In my case it was some code in a
consuming system that expected u16 sized int which broke when the producing
system increased to 32 bit sized int. I mean, no code change just the auto
increment on the database finally exhausted 16 bits.

Tangentially, this is why my first thought when designing a new system is to
use uuid/guid stored as a string in hyphenated hexadecimal. It prevents any
downstream consumer from even attempting to store it as an int. I'm now wary
of things that look like int but aren't actually integers since people will
often mistakenly treat them as such.

------
aglionby
The Government Digital Service does all kinds of cool work around
accessibility for both users using assistive technology and users who are less
technically able. Interesting talk here from 2014
[https://www.youtube.com/watch?v=CUkMCQR4TpY](https://www.youtube.com/watch?v=CUkMCQR4TpY)

------
maxcbc
This is the sort of thing I love about the accessible tech team at gds. They
learn something, then they share it in such an accessible way.

------
gatvol
Quite strange that propriety systems like dragon are mentioned as motivation,
surely they should fix the product or standardise.

~~~
leokennis
I guess that, as a government, they are required to cater for people with
accessibility issues (in this case: people who cannot type but need to dictate
to enter text).

If you then cannot support the most popular dictating application, that’s not
a good look.

~~~
petepete
This is absolutely the case. There are other areas where 'standards' aren't
used because of accessibility reasons; a prime example being the HTML5 built-
in validations. They just aren't reliably accessible enough across
browsers/platforms.

The GOV.UK Design System is extremely well thought out, there's reason and
sound arguments behind every decision - and the best part is that it's all
developed in the open.

------
rini17
This is another reminder that floating point numbers are just a hack that
should never be used by default. We have enough CPU, memory and bandwidth that
we are able to transmit/store exact representation of numeric user input, and
convert it to float only when necessary, as designed by programmer.

~~~
ivanbakel
Indeed. Just like 32-bit integers, having fixed size floats as the default
representation of numbers with a decimal component is a bad holdover from days
of limited hardware.

Let programmers use floats when they have the performance analysis to justify
it. Before then, it's just another kind of premature optimisation - and high
level languages should be avoiding it.

~~~
lolc
Then what do you propose happens when one writes 1/3 in Javascript?

~~~
egdod
It gets promoted to a fractional type.

~~~
lolc
Ok, what would happen if one then multiplies by Math.PI?

~~~
dragonwriter
Ideally, to maintain maximal correctness, it would be in a symbolic
representation until an inexact rendering was called for, but simply resorting
to floats for irrationals is not entirely unreasonable though it's still a
premature optimization, but not as bad as resorting to it for rationals.

~~~
lolc
Maintaining symbolic values could quickly blow up. For example when using
iterative methods. Are you aware of any languages doing symbolic
representation with standard types?

I don't see how irrationals as floats is premature optimization. If you
already know symbolic representation is going to blow up quickly and cause
downstream headaches the measures you take are not premature. Though now I do
wonder how the headaches stack up against the float headaches :-)

Don't get me wrong I like the idea of symbolic representation. It's just that
in everyday use it seems very impractical to me. Granted, limited forms of it
like the fractional type don't have the complexity problem. But in many cases
things devolve to floats quickly anyway. The people that care can use
libraries and deal with the complexity.

~~~
dragonwriter
> Maintaining symbolic values could quickly blow up.

It could, in certain circumstances.

> I don't see how irrationals as floats is premature optimization.

It is, when it is because “could” and not because “does”.

> If you already know symbolic representation is going to blow up quickly and
> cause downstream headaches the measures you take are not premature

Sure, if you know that's going to happen. When you do it because it might
happen, or because it happens to be the language’s default representation of
irrational (or even exact decimal, or in JS’s case exact _integer_ ) numbers,
that's a different story.

~~~
lolc
So can you name a language that does symbolic representation? It sounds like
one of those things which are great in theory but hellish in implementation.

------
TazeTSchnitzel
<input type=number> for things that are like telephone numbers and not like
quantities is such a common mistake. It can be hilarious when, for example, a
login form uses such a field for a Swedish personal identity number. I just
need to click the up arrow ~1.996×10¹¹ times!

------
OisinMoran
Really interesting article, and as with everyone else I also really admire
their commitment to accessible design.

One interesting this I noticed in this piece was the text (not quoted for
reasons that will soon become clear):

Using <input type=”text” inputmode=”numeric” pattern="[0-9]*"> allows for a
degree of separation between how the user enters data (“input mode”), what the
browser expects the user input to contain (type equals number), and
potentially how it tries to validate it.

Which has incorrectly used closing quotes and correctly used straight quotes
in the same code section, and then proper opening and closing quotes in the
text section. I wonder how that happened.

------
mirekrusin
Gov UK has some great, Jakob Nielsen style UI. It’s fantastic to use, love it.

------
nimish
Javascript not having proper integers strikes again! Kind of surprised they
hadn't run into more issues parsing string-ids-with-numerals into numbers.

~~~
notriddle
If JavaScript used 32-bit integers, then it would've just rolled over. Not
much of an improvement.

------
Fej
Does anyone know what's going on with the Firefox implementation of inputmode,
especially for Android? There isn't much on Bugzilla about it.

------
calibas
FYI, there's a few features available with the number input type that don't
work with this method. Things like min, max and step attributes.

~~~
eat_veggies
min, max, and step don't make sense for things like account numbers or credit
cards!

~~~
calibas
Well yes, in those cases it doesn't make sense, but the article mentions
things like date fields, where you might want a min of 1 and a max of 31. It
can also make sense to use step="0.1" if you need value to include tenths.

Just saying there's advantages and disadvantages to each approach. I do agree
with the article, their approach is better in most cases.

~~~
rocqua
In fact, the article does recommend using 'numeric' for dates!

------
BurningFrog
This number type is fine. It serves a purpose.

The real problem is that there is no type for other "numeric" cases.

------
ArchReaper
EDIT: removed my inaccurate comment, misread article

~~~
calibas
How is the "tel" type a solution? According to the standard
([https://html.spec.whatwg.org/multipage/input.html#telephone-...](https://html.spec.whatwg.org/multipage/input.html#telephone-
state-\(type%3Dtel\))), it accepts every character except line feeds and
carriage returns.

Without any pattern specified, the code you posted will accept emojis as
input, it's not a good choice for a numeric only field. It's also intended for
phone numbers...

~~~
ArchReaper
Woops, for some reason I read the title as "Why the GOV.UK Design System team
changed the input type for phone numbers" \- removed my comment since it
doesn't apply.

------
throwaway-q2233
Better option is graceful degradation, just Target those specific problematic
UAs for the other input type.

~~~
shakna
As with most accessibility problems... Checking my User Agent won't tell you
how I'm interacting with the site.

How do you detect I'm using NVDA? It'll still look like Firefox. Or Chrome if
I'm bypassing a broken UA detection.

Nowhere will you see NVDA, even though it is the problem.

------
klingonopera
I'm no web-dev, but shouldn't these things be sanitized server-side? In which
case, except for the mobile keypad issue, all these problems would solve
themselves?

And shouldn't they be doing this anyway?

~~~
thawaway1837
These recommendations are irrespective of server side sanitisation.

Server side sanitisation doesn’t address any of the accessibility concerns.
Server side sanitisation doesn’t address the silent dropping of characters
concern. Server side sanitisation doesn’t address the
incrementing/decrementing the value accidentally concern.

That’s because the issues being discussed here are about creating a good UI
that minimizes errors, and has little to do with sanitisation.

~~~
klingonopera
Yeah, but in-/decrement and silent dropping would've been a non-issue with
type=text.

All I'm saying, they could've used text all this time, and never had all these
problems to begin with, with the slight exception of a slightly-clunkier UI.

Well, now they're text anyways, so, yeah.

EDIT: If JS was an option, they could've also used text and then use "<form
onsubmit=SanitizeInput()>".

~~~
hombre_fatal
Seems to me like you're missing the point.

They want to give their users a numeric keyboard but without the downsides of
a numeric textfield. Your solution seems oblivious to their goals and TFA.

~~~
klingonopera
...at the risk of modified data? With things like credit card numbers?

I think I'm just not chill enough for that.

