Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

technology.blog.gov.uk

Post reply on HN
Print view View original

31–40 of 177 posts

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

#31

Post by pwdisswordfish2 »

ChrisSD wrote: 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…

To put it more succinctly and without unnecessarily referring to JavaScript semantics, type="number" is for quantities, not mere strings of digits.

It's an unfortunate accident of the English language that both are commonly called ‘numbers’. We might not have had this confusion if some other language were the lingua franca of computing.

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

#32

Post by yazboo »

klingonopera wrote: post #23
jkrems wrote: post #17

Earlier quoted context omitted.

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

The article is recommending against using type=number.

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

#33

Post by pwdisswordfish2 »

vitaliyf wrote: post #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

Some are yet to get the memo. Not so long ago, I've seen a TypeScript course that demonstrated union types with an example of representing zip codes as either strings or numbers…

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

#34

Post by klingonopera »

yazboo wrote: post #32
klingonopera wrote: post #23

Earlier quoted context omitted.

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

The article is recommending against using type=number.

...which they're only doing, after having it done.

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

#35

Post by [deleted] »

klingonopera wrote: post #22
thawaway1837 wrote: post #21

Earlier quoted context omitted.

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

[deleted]

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

#36

Post by emayljames »

shakna wrote: 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…

There needs to be a website to see if you can use caniuse website on your mobile browser. The site is unusable on mobile Firefox. The irony.

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

#37

Post by hombre_fatal »

klingonopera wrote: post #22
thawaway1837 wrote: post #21

Earlier quoted context omitted.

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

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.

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

#38

Post by oldmanhorton »

chrisweekly wrote: post #25
shakna wrote: 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?

Touchscreen pcs? Surface Pro users in particular would see this.

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

#39

Post by reggieband »

globular-toast wrote: post #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 i…

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

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

#40

Post by klingonopera »

hombre_fatal wrote: post #37
klingonopera wrote: post #22

Earlier quoted context omitted.

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

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.

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

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

Post reply on HN