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]*">`.
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!
That's one of the reasons I love Stripe's checkout being used everywhere and designers elsewhere basically copying them.
The internet is constantly getting better and I don't think we give that progress we've made in web design over the last few decades enough credit.
Just imagine how bad it used to be to just purchase a simple thing on an ecommerce site in the mid 2000s. Or remember what car websites used to look like vs what they look like now. Even newspaper websites like NYT are leaders with quality design.
It's easy to complain about those who still don't get it, but I feel like we've also made massive progress from the early wild-west days of the internet.
Still, I'm all for shaming those sites who still make inserting credit card numbers a pain in the ass.
This might be the best website ever. It is over the top, but the theme is consistent. It reminds me of a myspace page, but if someone just wanted to be ridiculous, not unsightly.
Side note: anyone remember "I knows me some ugly myspace" from Ze Frank?
Ze Frank. Now there’s a name I haven’t heard in quite some time. What an early internet vlog pioneer. I wondered what happened to him and looked him up a while back. Turns out he’s some bigwig at BuzzFeed so I guess he made out okay, but part of me misses that early enthusiasm and wonder of early internet 2.0.
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]
It's interesting to see how many people take certain things in web design for granted. I'd be interested to know how many readers here were in the neighborhood of 10 or 12 years old in the mid 2000s.
We've reached a point where it seems like the amount of people who know react looks pretty close to the amount of people who know CSS. CSS wasn't even a thing when I built my first site, and now the phrase "web design" isn't even really in the vernacular today.
I'm not asking anybody to get off my lawn or anything, it's just interesting.
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).
I think you're joking about Roman numerals, but millennials birth years are anything but easy to type in as a Roman numeral. For example, my birth year of 1987 is MCMLXXXVII.
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 handle things differently (and since many of the physical cards have literal dashes on them, which they are looking at when inputting the numbers), you should be able to guide your user into the right format without them having to get error messages or other nonsense.
Not enough web designers appreciate the anxiety of having to input a credit card number or other format-varied content into input boxes.
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.)
For reference by others: You want to apply NFKC or NFKD Unicode normalization to collapse full-width Latin letters and digits to their usual form. This also widens half-width kana.
Part of the problem is that inputs don't necessarily reflect the specific intent behind the use of certain symbols. For 99% of people using US keyboards when they input a dash in a credit card number they are using the exact same key as one would use for the minus when inputting a negative number. If you asked them to verbalize their inputs they would probably use different words for the same symbol, signifying that the meaning or intent isn't the same but even that isn't entirely reliable.
You can attempt to infer intent or meaning based on the context of the input field but often the least-problematic method is to provide instruction/hints with the field, examples of correctness, and real-time validation with specific syntax errors when invalid or unexpected data is provided. I'd argue that it would also be worthwhile to request clarity from the user when an input hits a filtering rule so that they can make clear their intent... e.g. if you assume that they're using "-" as a symbol for separation rather than simply follow that assumption, ask if that's the case and list other optional valid contexts for that symbol so they can be explicit. If they choose None of the Above or a context that is inappropriate for the field, inform them of that.
The 4-box credit card form, while pretty terrible in many ways, at least made explicit the expectations. Often we now hide the expectations and either auto-reformat what was put in the field (which can be surprising to the user or worse can modify their input to mean something other than what they intended) or do hidden filtering, which can have the same problems but doesn't even bother to inform the user of the changes.
> when they input a dash in a credit card number they are using the exact same key as one would use for the minus when inputting a negative number
So what? I can't imagine any possible way it would be unclear whether someone entered a credit card number or a negative number. They have different numbers of "-" in completely different places. Am I missing something?
> I'd argue that it would also be worthwhile to request clarity from the user when an input hits a filtering rule so that they can make clear their intent... e.g. if you assume that they're using "-" as a symbol for separation rather than simply follow that assumption, ask if that's the case and list other optional valid contexts for that symbol so they can be explicit. If they choose None of the Above or a context that is inappropriate for the field, inform them of that.
That sounds like such bad usability I'd assume you were joking if the rest of your post didn't sound so serious.
Note that my post isn't limited to credit card inputs, nor do I say that the request for clarity is mandatory in all fields.
What I'm advocating is a focus on ensuring the user's explicit intent rather than attempting to infer intent or making hidden assumptions that either could be wrong or exist to make things easier for the developer.
Too many times I've had to deal with data that someone optimistically sanitized or filtered client-side and then stored, only to discover the sanitizing/filtering rules were wrong and the original data provided by the user was lost because the only thing stored was the result of those rules.
> Note that my post isn't limited to credit card inputs
Not your entire post, but the part about the '-' key was pretty specific and narrow-scoped.
> What I'm advocating is a focus on ensuring the user's explicit intent rather than attempting to infer intent or making hidden assumptions that either could be wrong or exist to make things easier for the developer.
'explicit intent' sounds like a nice goal but asking the user inside the form is not going to give you good info, and it will very often annoy them.
> only to discover the sanitizing/filtering rules were wrong and the original data provided by the user was lost because the only thing stored was the result of those rules
It wouldn't hurt to store the original. Even if the user told you what they meant, they might have said the wrong thing.
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?
But it goes beyond "this is what they do". Users tend to do a wide range of things when entering dates and you kinda have to guess what they mean. Throw in guessing what localization should be used (it's not always clear) on top of that fuzzy system and it can become a frustrating experience for everyone involved.
> Not enough web designers appreciate the anxiety of having to input a credit card number or other format-varied content into input boxes.
I feel most of these things should be solved by browsers, not designers...
Problem is for something like credit card every single browser vendor will try to plug their own service in one way or another (think Apple Pay and Android Pay).
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.
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.
Exactly. Good control UX should be very liberal in what it accepts and normalize it to whatever form they want. Same goes with editing, it should allow temporary invalidity (extra or fewer digits) turn red/disable submit and then return to green when fixed.
Don't make hundreds to millions of users do extra work that could've been automated with a little more care.
It would be the same markup. It just wouldn't do anything on desktop. Which is fine because desktops generally have physical keyboards.
I apologize if you already know this, but to make sure we're on the same page: what "inputmode" does is tell phones to display the onscreen keyboard as a numpad, instead of a full set of QWERTY letters and numbers. Outside of a few edge-cases, you don't generally need that on desktop.
TBH I went on autopilot looking at MDN's browser compatibility list. Also as a user of Firefox on Android I was interested in something that works there, but type="tel" doesn't behave any better. The only advantage to not using inputmode is getting rid of an HTML validator warning, so you're right.
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.
A sequence of numbers could be called, with a little approximation, a barcode. Which makes me wonder why credit cards don’t have an actual barcode to easily enter it on the computer.
> We might not have had this confusion if some other language were the lingua franca of computing.
Interestingly enough, I can confirm as a native speaker of one such language (🇸🇮Slovene), that outside of discrete mathematics and tech, the words are often used interchangeably. This suggest that the lack of a word in English isn't the cause but the effect. The distinction was likely not necessary before the modern era, so old (==all) languages never created/adopted proper terminology.
You can't entirely avoid referring to JavaScript semantics here, type="number" is for values appropriate to represent and work with as IEEE 754 doubles.
That covers a lot of ground, by design. But a 'number' it isn't.
Technically, number (a quantity) vs numbers (a series of numbers) would suffice. "Numeric" (as an input mode vs a number type) makes sense, too.
I think it's just an evolution of our education, preferred input devices, and specs all catching up with each other. On a desktop I just start typing numbers from the keyboard. On a smartphone I click on a credit card field, if the field expects "text" I have to click "123" then input the number using a number row with smaller target sizes. I would greatly prefer to directly show me a number pad.
That's a good rule of thumb there :) More pedantically, credit card numbers _aren't_ numbers in the first place. They are identifiers that happen to use numerical digits. Same as phone numbers. Treating them as numbers at any point in a system is an error. My dream is this detail of the HTML spec forces people to rethink their schema design while they're at it.
I've come across this problem a number of times. The same applies in, for example, passing IDs across in JSON where I use strings if at all possible.
Even money amount are typically challenging to treat as numeric as often that drops them into a float when you shouldn't be processing money amounts as floats.
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. Instead you must check input.checkValidity(), and perhaps use the CSS :invalid pseudo-selector to show the user that their entry is not valid. You cannot read the actual invalid value AFAIK on iOS (although you could simulate it by looking at key events, if you ignore selection and cut/paste).
Data entry with HTML is one area where you really want a native app, and you can get severely burnt trying to use a WebView. I have wasted months dealing with a variety of quirks over the years trying to make time entry friendly in HTML: all solutions have terrible compromises, and different browsers act quite differently (and can have nasty bugs).
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 to trigger the numeric keypad on older versions of iOS. Once traffic from older iOS devices drops off we'll likely remove it.
> 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.
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.
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!
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 in general, which is clearly inspired by Gov.UK.
Fantastically straight forward? I strongly disagree. I've done the SA many times, and trying to find out your balance or payments list or anything useful is now a kafka-esque nightmare. Last time I knew they must owe me money but they didn't say at the end, and it took me about 15 minutes to find out how much, with no indication of when it would arrive. At the end of the SA they even had some sort of message saying make sure you pay what you owe, which turned out to be nothing. This is all complicated because you pay on account, paying the next year's tax 15 months before you submit your return (they guess your next tax bill based on the previous one, as you don't submit the return for 9 months after the end of the tax year, so you don't get in too much credit).
The new SA process is no different from the old one, with minor cosmetic enhancements, but they've made it almost impossible to get to the old account sections.
Notice how there's no login button. On a website that relies on logging in. Now search for "self assessment login" or "self assessment account" or "self-assessment balance".
See any login button? See anything resembling a login? last year you could still get to the old account screen after some hunting, but that's gone now. The new account screen is a mass of text with links sprinkled through out, where the old one was a compact menu.
Plus, when you finally do find your accounts, you can only see one year at a time, have to use a drop down to change year, the amounts you owed are on one page, they amounts you paid are on another, some of these figures are still provisional, and nothing adds up.
As for submitting your company accounts, what a joke that used to be when they re-did it. I knew exactly what type of account I needed to submit. But to get to that form, I think they had a labyrinth of 16 web pages, each just one question per page, that you had to answer while they unhelpfully tried to pick the form you needed for you. Get the wrong form? No way to go back to see what answer you got wrong, no way to fix it, you just had to start again. It meant I had to go through it 3 or 4 times before I finally got the right form.
Before they "renovated" it, you just picked the form you needed.
They even did a whole blog post about how great the one page per question concept was, which turned out to be utterly bullshit.
I've lost all faith in the gov.uk team, I feel they're trying too hard to be cool and "innovative". They have thrown out convention, and are often making poor UIs and user journeys because of it.
The lack of a ‘login’ button is a huge issue IMHO, but the main blocker to it isn’t the tech teams, its at the ministerial/senior civil service level.
The problem isn’t the button itself but the infrastructure behind it. I.e. it requires a single database of users (i.e. a national register of citizens).
This needs doing, but politicians come out in hives because it involves setting up a system similar to national ID cards (politically difficult). Senior civil servants dislike it because its a question of which department owns it, if its GDS its the cabinet office, and that means the Home Office, DWP, HMRC surrendering some control (i.e. being increasingly dependent on external systems), which is something departments seem to dislike.
It’d save millions (billions probably) in the long run, but there isn’t the political will to do it. It would need an influential cabinet minister to push it through and would take 3-5 years to get properly embedded.
Finding where to login for SA is the one frustration I have with SA right now. Everything else works really smoothly, but I have to resort to Googling "self assessment login" every time.
Solving this doesn't require a unified login - it needs proper signposting within gov.uk of the most likely user flows. Right now, finding the login for SA is something like 5 levels deep within the hiearchy of pages, and even then it's not well signposted.
gov.uk -> "Money and Tax" -> "Self Assessment" -> "Register for and file your Self Assessment tax return" -> Sign In
Having to choose "Money and Tax" and then "Self Assessment" is fine. But then you're faced with an enormous menu of choices, only the 19th of which leads to a login prompt. Once you've reached that page, "Sign In" isn't even at the top of the page - it's below the fold on my 1440 pixel high screen!
Just putting common tasks at the top of the list, with everything alphabetised underneath for when you're looking for something specific would make a huge difference.
I get what you’re saying I have the same problem with SA, but the key is better personalisation, which login can help with.
Gov.uk provides hundreds of services, like SA, which each user will only use a small subset of. That subset will be different for each user. I now need SA whereas 5 years ago prominently signposting that would have been useless to me. For others education services, welfare services and health should be highlighted. All this is quite difficult without knowing who is accessing the site.
Though In the specific case of SA, I think its not as well conceived a service as it can be. 95% of the time i’m not ‘registering for self assessment’ or ‘filing a self assessment tax return’ , i’m ‘checking what tax i owe’
> it involves setting up a system similar to national ID cards
No it doesn't. We have a register of everyone resident or tax paying here in Norway and no ID cards. The government keeps on trying to make ID cards happen but the relevant departments always seem to be dragging their feet.
You already have a national register in the UK: National Insurance numbers. The difficulty is that it is simply not properly joined up with taxes, banking, etc.
I very much doubt that there is any serious political objection to joining these databases amongst the general public; as you say the civil service departments feathering their own nests is the biggest problem.
Its seen as setting up a system similar to national ID cards.
Weirdly National Insurance numbers are not always unique, and people can have more than one. Also while they are used by for tax and benefits (HMRC and DWP) other departments have a different ID number, the biggest being NHS numbers, military service numbers, passport numbers and driving license numbers (DHSC, MOD, Home Office, Department for Transport).
So you’d need to unify it, under one of these, effectively creating a ‘National ID Number’, even if you don’t call it that it’d be spun as that by opponents (libertarians, big brother watch etc).
You’re probably right in that the public probably aren't too worried about it, and would probably be appalled to see the waste that goes on as a result of it not existing. But politicians and parts of the media will get riled up by it.
> would probably be appalled to see the waste that goes on as a result of it not existing.
There's no probably about it. I breath a sigh of relief every time I get back home to Norway after visiting family in the UK (which I left 34 years ago). So much is just simpler here.
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.
I once saw an integer overflow impact production because someone was concatenating primary keys together as strings to form new primary keys (and storing them as an integer type).
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.
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.
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…
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.
> 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.)
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.
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.
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.
In this case, the fallback is still a plain-text field, into which the user should enter numbers. Perfectly usable, but without the keyboard hint, so it seems like a graceful fallback to me.
Arguably it's less important there if one of the main motivations is that on mobile browsers will display a numeric keypad instead of full keyboard (which is my impression from skimming the article)
Trying this out in the latest Desktop Firefox, the numberinput and pattern attributes seem to have no effect, and it behaved exactly like a regular type="text" input.
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.
> 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.
They were using it to get a numeric entry pad on mobile devices because users preferred that. They knew the types weren't "numbers". Now that inputmode=”numeric” has better browser support they recommend that.
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
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.
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.
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.
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.
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 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.
> 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.
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.
"could" is the operative word. How many programs do enough calculation to make the tradeoffs of floats worthwhile? Conversely, how many programs need correctness more, and get caught out by float gotcha?
This is the definition of premature optimisation - not knowing the impact, you're suggesting a performance change anyways. The point is, for programmers that don't care, inefficiency is good enough.
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.
<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!
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.
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.
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...
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.
Unless I'm missing something, the graceful degradation is the `pattern="[0-9]"`. Certainly `input type="text"` is about as "degradation friendly" as you can get in HTML land...
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?
The point is that giving the user a number input is a bad user experience. For example, users don't need or want up and down spin buttons to enter a phone number. That's long before it gets to a server.
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.
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()>".
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.
Avoiding clunky UI is the raison d'être of gov.uk. You shouldn't have to deal with an awful user experience for things you are legally required to do to go about your life.
You always should validate server side but this is to make it easy to use and accessible for users, PayPal has a custom input type that looks fancy but for example the Delete key is not working for it(no idea if is accessible or if you can type in it via speech)
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.
> Insistence on using number makes me suspect they require sanitation to be done client-side.
Why when they explicitly state that it was done for getting the proper input UX on mobile? The whole article is about finding a good UX for inputting numbers, taking different device types and accessibility concerns into account. It doesn't mention using these for validation at all afaict. Somewhere in this thread one of devs showed up and explicitly stated that they disable all HTML validation on the pages.
The solution is to use `<input type=”text” inputmode=”numeric” pattern="[0-9]*">`.