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

141–150 of 177 posts

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

#141

Post by rocqua »

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

It would be cool if more languages had support for fixed-point fractional numbers. Rolling your own requires re-implementing display and multiplication code, which is a decent reason for people to just use floats instead.

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

#142

Post by rocqua »

calibas wrote: post #117
eat_veggies wrote: post #104

Earlier quoted context omitted.

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

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.

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

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

#143

Post by dragonwriter »

lolc wrote: post #134
egdod wrote: post #123

Earlier quoted context omitted.

It gets promoted to a fractional type.

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

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.

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

#144

Post by radiowave »

monadgonad wrote: post #137
OJFord wrote: post #110

Earlier quoted context omitted.

No more than I can explain 'electrodreams' or 'mackem sex', I'm afraid!

A mackem is someone from Sunderland.

And Sunderland is where the Nissan Qashqai is manufactured.

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

#145

Post by 2038AD »

mc3 wrote: post #124
DonHopkins wrote: post #80

Earlier quoted context omitted.

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

Gen Z are the ones born on MM or later.

Nope! Late 90s get rolled in too. Exact dates depend on who you ask and I'd avoid using generational names altogether.

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

#146

Post by hibbelig »

bcrosby95 wrote: post #135
DonHopkins wrote: post #81

Earlier quoted context omitted.

Not to mention that some countries use . as a decimal point and , as a digit grouping separator, and others do it the other way around.

Yes, I'm rather glad I haven't had to deal with localizing decimal inputs, just displaying them. I have had to deal with localizing date inputs though. Ugh.

Why is this "ugh"? The way I see it, we're building software for users, and we try to make it useful for them. And part of that is trying to come up with a pleasing and easy to understand design language. And another part of it is catering to different cultures and languages.

For example, afaik, the standard way Chinese dates are written is something like "2020Y02M28D" but with the Chinese characters (words) for year, month, and day, instead of Y, M D. I find this totally beautiful: it doesn't take up more space than "-" or "/" or "." as a separator, and it totally disambiguates the meaning. (Well, there is the trailing "day", so we are losing one character.). It is such a wonderful use of the fact that Chinese is using ideographic characters. Isn't it?

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

#147

Post by patio11 »

dmix wrote: post #51
airstrike wrote: post #46

Earlier quoted context omitted.

> a good interface will accept leading, trailing, or interior spaces Won't pattern="[0-9]*" do the exact opposite of what you're suggesting?

Yes, you're right, this isn't a great solution for credit card inputs either. They should be able handle dashes and other spacing characters and the site should be able to filter/format it automatically either on the front-end before submission or with some server-side processing. And no we don't need four different input boxes to enter a credit card numbers either. Flexibility is key here and since many websites han…

A fun edge case, of the million edge cases for credit cards:

If you have Japanese users, their browser/input method editor may send full-width characters by default, such as 4321 instead of 4321. You should probably honor those, but unless you wrote code to do this, you almost certainly won't. Even most Japanese sites are user-hostile here, either failing to detect them as numbers or telling the user "You wrote your number in full-width characters; please try again in half-width characters" despite them being trivially convertable.

(Disclaimer: this is professionally relevant to me and yes, Stripe Elements / Checkout do do the right thing here.)

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

#148

Post by joelanman »

andreareina wrote: post #118
joelanman wrote: post #84

Earlier quoted context omitted.

Important to note that in the article we mention we only use pattern to trigger the right keyboard in old iOS. We actually turn off HTML validation in favour of doing server side validation, we'll soon be publishing guidance on that too. Disclaimer - I work on the team.

Why are you going to server-side only? I've always held that client-side validation is important for UX as it provides instant feedback and doesn't need any extra work to preserve the other data that's already been input. Obviously the inputs still need to be validated on the server e.g. to protect against things that get past (or bypass) the client-side checks, or perform more expensive validation.

We'll be publishing soon on the GOV.UK Design System, but in summary we can't make browser validation consistent with our Design System, or guarantee it's always accessible.

In our research it's commonly most often helpful to validate when the user submits as that's when you can be sure they're 'done'. There are cases when realtime helps so it's fine to add it in those situations.

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

#149

Post by gwillz »

downerending wrote: post #29
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…

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!

Also, the expiry date should never be a date picker. I'm not trying to _choose_ a date, I'm just dumping the exact numbers from my card. I want to type, tab, type, tab, type, enter, and be done.

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

#150

Post by mikro2nd »

gwillz wrote: post #149
downerending wrote: post #29

Earlier quoted context omitted.

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!

Also, the expiry date should never be a date picker. I'm not trying to _choose_ a date, I'm just dumping the exact numbers from my card. I want to type, tab, type, tab, type, enter, and be done.

But wait! It gets worse: Date-of-birth fields where they use a date picker, and the default/starting date is today.

I'm a bit older than the average HM demographic, so using a date picker to scroll back many years might take hundreds of clicks. Then I made a mistake (details long forgotten) and the whole thing reset and I had to start again. On the third time around I just quit.

Post reply on HN