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

171–177 of 177 posts

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

#171

Post by dragonwriter »

lolc wrote: post #165
dragonwriter wrote: post #143

Earlier quoted context omitted.

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.

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

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

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

#172

Post by robocat »

thirty6degrees wrote: post #153
robocat wrote: post #45

Earlier quoted context omitted.

inputmode=”numeric” and inputmode=”decimal” have different quirks between Android and iOS. inputmode also acts differently on iPad and iPhone, and the keyboard shown varies from that for pattern=, and support for inputmode is missing from iOS11 (or iOS12?). Tread carefully! Note that type="number" is particularly horrible on iOS because it allows typing non-numeric values and then input.value just returns zero. Inste…

Those iOS issues with type="number" are really interesting – thanks for sharing. Support for inputmode was added in iOS 12.2, but initially it used the 'numeric keypad with punctuation' – is that what you mean by 'the keyboard shown varies from that for pattern='? iOS 13 updated this behaviour, so it now uses the 'correct' numeric keypad, without the punctuation keys. The pattern attribute is still provided in order…

> iOS 13 updated this behaviour, so it now uses the 'correct' numeric keypad, without the punctuation keys

The iPhone shows the 0-9 keyboard. The iPad shows the punctuation keyboard. This is not obvious, and one of the places where Mobile Safari acts differently between the two device types.

Try jsbin.com/necuzoj

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

#173

Post by lolc »

dragonwriter wrote: post #171
lolc wrote: post #165

Earlier quoted context omitted.

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

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

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.

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

#176

Post by thirty6degrees »

robocat wrote: post #172
thirty6degrees wrote: post #153

Earlier quoted context omitted.

Those iOS issues with type="number" are really interesting – thanks for sharing. Support for inputmode was added in iOS 12.2, but initially it used the 'numeric keypad with punctuation' – is that what you mean by 'the keyboard shown varies from that for pattern='? iOS 13 updated this behaviour, so it now uses the 'correct' numeric keypad, without the punctuation keys. The pattern attribute is still provided in order…

> iOS 13 updated this behaviour, so it now uses the 'correct' numeric keypad, without the punctuation keys The iPhone shows the 0-9 keyboard. The iPad shows the punctuation keyboard. This is not obvious, and one of the places where Mobile Safari acts differently between the two device types. Try jsbin.com/necuzoj

That is odd. However, it looks like this matches the behaviour of (both trigger the punctuation keyboard).

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

#177

Post by Rudisimo »

BrianB wrote: post #95
BrianB wrote: post #78

Earlier quoted context omitted.

> Or remember what car websites used to look like vs what they look like now. lingscars.com ?

Did you check the source code yet?

That's a glorious Ling ASCII banner. But the video referenced in the commented YouTubePlayer widget is a first for me, and absolutely hilarious: [Drugos (Despacito) LINGsCARS website promo][1]

[1]: https://youtu.be/L2GlWaeNNoU

Post reply on HN