Live data from Hacker News

Why the Gov.uk Design System team changed the input type for numbers

technology.blog.gov.uk

21–30 of 177 posts

Re: Why the Gov.uk Design System team changed the input type for numbers

#21

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?

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.

Re: Why the Gov.uk Design System team changed the input type for numbers

#22

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?

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 minimize…

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

Re: Why the Gov.uk Design System team changed the input type for numbers

#23
post #17

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?

What makes you think they don't? But they still want good UX for entering the data.

Insistence on (EDIT: having used) using type=number.

Given the choice of bad UI vs. (accidentally) modified data, I'd pick bad UI any day.

Insistence on using number makes me suspect they require sanitation to be done client-side.

EDIT: Normally, I wouldn't assume a website run by a government wouldn't be doing this, but wasn't there some scandal recently in the US about the Dems and some web-app, and that it was woefully amateuristic? Suffice to say, that has kinda changed my perception about governments and IT. Then again, "gov.uk" has a tech blog, so I'm probably misplacing my skepticism.

EDIT2: Updated tense.

Re: Why the Gov.uk Design System team changed the input type for numbers

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

Re: Why the Gov.uk Design System team changed the input type for numbers

#25
post #5

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

Desktop support is also almost moot, though, right? What's the "desktop with virtual keyboard" use case?

Re: Why the Gov.uk Design System team changed the input type for numbers

#26
post #4

In summary the main issue is that, according to the spec, ` ` 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. Th…

[deleted]

Re: Why the Gov.uk Design System team changed the input type for numbers

#27

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…

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

Re: Why the Gov.uk Design System team changed the input type for numbers

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

Re: Why the Gov.uk Design System team changed the input type for numbers

#29
post #4

In summary the main issue is that, according to the spec, ` ` 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. Th…

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!

Re: Why the Gov.uk Design System team changed the input type for numbers

#30
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

Post reply on HN