The article shows an example of a credit card field being a "number". Having made several online purchases, I realized I'm now frustrated by a CC number field that doesn't allow any spaces or dashes, or doesn't format it visually this way for you. They should just allow dashes/spaces then strip it using JS or at the backend.

There is a reason that the number printed on the credit card is grouped into 4 digits, and I believe that it makes human parsing easier. When I submit the form and it says "invalid card number", trying to figure out which digit I mistyped into the form while scanning that long string of digits with my eyes, gazing at the card and back at the screen is just stupid.

Same goes for phone numbers too. When I enter a phone number into a field, only to be told on pressing submit that 'phone number cannot contain spaces', I despair for technology. So your form accepts spaces, and you made your website check for spaces, but simply removing them is beyond the capabilities of your code? Websites suck.

In the UK, bank accounts have a thing called a sort code, which is six digits, conventionally grouped into three pairs, separated by hyphens (eg 08-92-73). It seems to be completely random whether an input for these will be a text box which requires hyphens, a text box which forbids hyphens, three tiny text boxes which you have to tab between manually to enter each digit pair, or three tiny text boxes where JavaScript automatically moves the focus to the next after you have entered two digits.

Naturally, you cannot reliably paste into any of them.

But then, my bank has disabled copying everywhere sort codes are displayed anyway!

Honorable mention for microsoft windows where entering an IP address/netmask in the ipv4 adapter config screen requires you to enter digits into four tiny text boxes where tab moves your cursor to the next IP address instead of selecting the next part of the current IP address.

The "." key does move the cursor to the next byte though, so you can quickly type an IP just like you would anywhere else.

Oh that's good to know, thanks!

Just look at this hot mess they are planning to replace it with:

https://imgur.com/a/bRlIpao

UX galore yet I feel we've gone backwards. The damn thing has so much padding it doesn't even fit on my full-HD monitor. Except it should, but they capped the height and made it so I have to scroll. I just don't have the words, I'll let you guys decide further from that image.

... but not if you type dot instead!

Best of all is the three boxes+javascript option when it responds too slowly and drops some of the digits you typed. And then the "automation" interferes with your attempts to correct the number. Aargh!

I'm shocked at the performance of some large websites on mobile. Apparently whatever JavaScript they use makes it impossible to type in the search box for at least 10 seconds after the page finishes loading.

I often have exactly this problem with IDEs trying to be clever. I'm typing the bits of the code in my own way, the IDE's trying to fill out bits in its own way, and the whole thing's a mess.

I've seen one which is a single text box with grey placeholder text that has hyphens ("12-34-56") yet does not accept hyphens, so you need to type in the format "123456"...

This is basically how Excel works when you use custom number formatting. You can set a number format to display numeric data in a specified way (e.g. "00-00-00" for a sort code, or "0000 0000 0000 0000" for a CC number).

Excel will store the data as a number, and display it with the selected format, but you can't type it in with the spaces etc. - it needs to be input as just a number.

I think this way of doing things is quite common.

I've seen similar issues with postcodes as well, though it seems to have got better:

Type "LS29JT" and get an error because it does not like that you did not add the space "LS2 9JT"

Or even, type "LS2 9JT" and get an error because it does not like that you did add the space.

There’s a special place in hell for people who enforce space/no space in a postcode

The official postcode format insists on the space between the outward and inward.

I'm not sure why. The Inward code is always Number-Letter-Letter. The outward code can be variable length and format. The space is certainly beneficial for visually parsing, but why W11AA isn't valid when W1 1AA is valid is confusing.

I think its to help with manual sorting.

Letters received need only have the W1 part read, to see where they should be sent.

When they reach Westminster, the 1AA part is read to sort them for final delivery.

Yes the official format includes a space. But since the postcode is unambiguous whether the space is there or not, from an UX point of view just accept either and add the space correctly in the parsing code.

Sometimes you can feel that the code has been written by an engineer who is following the 'spec' to the letter instead of thinking of UX.

If you were to type

W111AA

One letter at a time, auto-inserting the space

W / W1 / W11 / W11 1 / W11 1A / W11 1AA

But for W1, you'd do

W / W1 / W11 / W1 1A / W1 1AA

Which would be jarring - you don't know when the inward code ends without typing a space, so you have to infer.

That said there's no reason not to allow [a-zA-Z0-9 ] and format after typing is finished (onBlur or even after submission).

(Poorly implemented address validation in the UK was behind the change in BFPO addresses 10 years ago -- https://fetchify.com/latest-news/lets-talk-about-bfpo-addres...)

Auto-inserting while typing is not a good option, IMO, for the reason you mention, and I tend not to like forms that do this sort of thing.

Let the user type in the postcode and when they submit you can parse it as a whole maybe just in the backend, insert the space and display with the space from then on. Simple.

Probably the SO post I visit the most:

https://stackoverflow.com/questions/164979/regex-for-matchin...

That was an absolute delight of a read. I learned a few things. GIR OAA and SAN TA1 are wonderful postcodes.

I used to have a post code like W1F 9XX. That was fun

In Australia we have an account number and a BSB - Bank State Branch number which, unsurprisingly, represents the bank, state, and branch.

These are almost universally displayed as two groups of three digits, that's seven characters, count them... separated by a hyphen and almost universally have to be entered in to a six character field, non-numeric characters not accepted.

Definitely one or my favourite minor annoyances.

Ha! Oops. I meant to put that bit about seven characters after the hyphen, thereby making seven characters. Doh.

Metro Bank has a great feature for transfer amounts. When you type an amount, commas are added automatically.

However, if you paste a number with commas in it, it will display correctly, but on the next screen you will discover it is transferring a different amount, as if it parsed the number up to the first comma.

(As an aside, this is one of the underrated things about best-practice React: that kind of bug can never ever happen. What is displayed is fixed by the rendering of the data model, never the other way around.)

What annoys me (unreasonably) is when the website then blames me by saying something like "You entered an invalid phone number." No, the phone number I entered is perfectly valid, it's that your crappy software can't parse it! <bangs head on table repeatedly>

we need a system like we have for email whereby it doesn't matter if the letters are uppercase or lowercase, as long as the information is there (email alphanumerical, credit card and phone numbers numerical). sadly there are still a few people who say or question capital letters in their email address, but that's better than being outright rejected as valid input

Some of my customers get upset if i don't enter their email exactly as written by themselves.

Even though they got the email.

Get better customers :-)

Incidentally: how do your customers know how you entered their email address? That's a matter that is at the discretion of the mailserver software; it can be automatically rewritten.

What you typed into your mailer isn't guaranteed to be reflected in any of the headers the recipient sees. Far from it.

It's honestly really important NOT to treat a credit card "number" as a number. It is an essentially text string made out of digits. It doesn't have any of the equalities or operations a number has. 01234 != 1234 and so forth.

IMO here you are mixing up what a 'number' is from a programmer's perspective, to what a number is from a User / UX perspective.

We want a user to just be able to input numbers and not letters. Yes, that is a string, but from a user experience perspective we are going to ask them to input numbers / sets of numbers.

This is important, because if they just make it a regular text field then mobile phones will show the full keyboard which makes inputting long numbers very difficult.

Yes but entering 0123 and 123 results in something very different if it's a string and exactly the same if it's a number.

Anything that can have and needs to retain leading zeros is a string. That string can be restricted to 0-9 and would benefit from the numeric keypad.

https://stackoverflow.com/questions/6178556/phone-numeric-ke...

even worse, sometime 011 and 11 is very different even as a number. Some function from php if it converts strings to numbers, considers a trailing 0 as octal representation. Probably intval without base: https://www.php.net/manual/en/function.intval.php

That would be a leading 0, not a trailing 0! :)

of course!

> That string can be restricted to 0-9 and would benefit from the numeric keypad.

Yes, that’s the whole point of the original article - that up until now browser support was insufficient to roll this out on a government website.

I’m aware of what happens if you save a string of numerics into an integer. It’s still entering a number from a user / ux perspective.

Does it hurt anything for the system to add the leading zeros?

(e.g. a CC number input and stored as "1" and displayed as "0000 0000 0000 0001" - an extreme example I know)

Some credit card issuers don't use 16 digits (American Express uses 15). And the first digits indicate the card issuer, so if you haven't stored those correctly you don't know how many zeroes to pad with.

In practice, the Wikipedia list of issuer prefixes doesn't show anyone using leading zeroes, so as long as you don't use separate inputs for each number cluster this specific issue probably won't bite you, though others might. IMO it's better to preserve verbatim user input than to capture malformed data and fix it after the fact.

Yes because if you need a 16 digit number and the user entered 15 - it's very likely they just missed a number in the middle instead of the system attempting to correct it with a prepended zero.

Yes, the commenter you're replying to is specifically talking to programmers, and tell them, from a programming perspective, not to treat a credit card number as a number. They're specifically trying to draw people's attention to the distinction you're saying they "mix up". The point is—even if you might call it a number, you cannot use HTML's "number" type or any numeric types in popular programming languages for storing or processing this data. That's the entire point of the article

IMO there ought to be a specific entry field type for credit card numbers. Plus possibly also one for CVV/CVNs. Security implications plus formatting implications make it neither "a number" nor "plain text". In a card number, the 4 digit grouping should be automatic, like it is on some of the fancier custom input fields.

What security implications do you have in mind? Hiding the number is evil for the 16-digit CC number and still dumb for the expiry date and security code. Also, autocomplete for those fields is something many people want, and is a browser feature. I can’t see anything else security-related that makes any sense to have for CC numbers specifically.

Having them scraped, or auto memorized and dug out of cache with a tricksy autofill form, or peeked out of RAM, or I dunno... in general being treated as something other than the highly sensitive personal information they are. Financial businesses acting according to the rules of PCI DSS are not allowed to store credit card numbers or CVVs in the clear anywhere. But browsers shrug and treat them like any old text.

Graphically I was thinking of the opposite of hiding the number, but rather making it clear to see by automatic digit grouping and stuff.

It's not strictly true to say a credit card number is not a number. It can be validated by Luhn's algorithm which is numeric in nature, but not in such a way that you would treat it as an integer.

It's a sequence of single-digit integers, not a number

That's true for the mathematical definition of number, but not for the commonly used definition of number as "a numeral or combination of numerals or other symbols used to identify or designate" (4b at [0]). A common example would be a document number, which may often be alphanumeric.

[0] https://www.merriam-webster.com/dictionary/number

That's great. We're clearly talking about the definition of number used by HTML and all major programming languages. Whether a dictionary counts it as a "number" or not is entirely besides the original point—don't use integer or numeric types for storing or processing this data.

That is to say it's a numeral

Yeah. I'd say it's numeric, but doesn't represent a quantity.

Are any credit cards issued with numbers beginning zero?

I would bet this sort of pragmatic workaround is taking place.

Credit Card numbers start with a BIN (Bank Identification Number) that is 6 or 8 digits. The first digit of the BIN is the MII (Major Industry Identifier). The MII of 0 is indeed valid, but seems to be reserved for use by the committee managing the spec? In any case, it's perfectly valid to have a CC# starting with a 0.

And this is the kind of thing that can get you if you get "too smart" about verifying the number, by assuming that 0 is reserved and will never be used.

We see this with IP addresses where hardcoded assumptions that were wrong or became wrong blow things up. For example, many people didn't realize that 172.* isn't entirely reserved for internal IPs.

Also: IBAN (International Bank Account Numbers, 20-40-character account ids used mostly in Europe) - I just love it when I copy an IBAN (which legally can contain whitespace for grouping), paste it into a (length-constrained) input field, and the last third of the number is being cropped away.

IBAN fields should NEVER be length-constrained. Every country uses different lengths, and if you have a max length, chances are you are locking out some users from other countries (which actually is in violation of European law [Article 9, Regulation No 260/2012]).

Just be grateful you can paste it. chase.com blocks copy/paste on IBAN fields which is just incomprehensible to me. Absolutely infuriating.

Apparently someone somewhere thinks you're more likely to get your account/routing number correct if you type it in by hand than if you paste it in; it's absolutely infuriating and insane.

....seven consecutive zeros.

Preach. Any input which might as well be random (CC, phone numbers, keys, fingerprints, …) should allow for formatting otherwise anything beyond 4 characters gets very hard to validate and correct.

If it auto-formats that may be fine, although lots of these have very culturally dependent formattings (phone numbers are a prime example here) so freeform formatting is definitely better.

It’s also important to realise that lots of things which are numerical (sequences of digits) are not semantically numbers e.g. leading zeroes are relevant in a phone number or CC number, and incrementing or decrementing either is nonsensical.

This is a pet peeve of mine. If you aren't performing mathematical operations with it, it's not a number, even if it has digits in it. ID numbers, social security numbers, phone numbers, credit card numbers, etc these are text identifiers that happen to use numerals. They're not numbers.

Yes! Always annoys me that Google Maps navigation reads the codes for roads as if they were numbers. In the UK I only ever here, for example, A2179 spoken as "ay twenty-one seventy-nine. GMaps reads it as "ay two thousand one hundred and seventy nine". That extra time taken and slight extra mental processing when you're driving, it exacerbates it beyond annoyance.

(There are exceptions, of course, A6000 would be read as "ay six thousand").

Presumably this is USA-ism noone bothered to fix.

Similar to when I ask Siri to play the radio station WINS/New York, which has a frequency of 1010 AM, and is known as "Ten ten wins."

Siri: "Now playing one thousand and ten wins."

Or even worse, when I ask her to play the radio station 2GB in Sydney, known as "two gee bee, eight seven three."

Siri: "Now playing two gigabytes eight hundred and seventy three."

I've had google maps navigation read a road used by two routes such as "US-91/89" like a fraction, "Exit onto US ninety-one eighty-ninths."

Not number related, but this reminds me how I've had it erroneously pronounce a street name containing "Vly" (an uncommon word [0], but not an abbreviation, a whole word) as "valley". Since other street names use the former as an abbreviation for the latter, I guess it's part of a standard lookup (like how "mt" and "mtn" expand to be pronounced "mount" and "mountain") without means for an exception.

[0] https://en.wiktionary.org/wiki/vly

I would pronounce that "ay two one seven nine". A505 would be "ay five oh five" but A610 would be "ay six ten".

But I wonder if that's because I'm from a part of England where the first digit is large (>4). I can see A1066 is more likely to be "ay ten sixty-six".

Your pronunciation seems better, in retrospect.

No, not a USA-ism, we'd likely pronounce it the same way, although I can't think of any highway numbers that are that high. An example would be I-440 in North Carolina, it gets pronounced "eye four forty", or I-195 would be "eye one ninty-five".

The interstate system is a bit of an oddity numbering wise as well.

"Four forty" is a better way to say it than "Four hundred forty" because the hundreds place is used to denote branches off the main interstate. I440 should attach to I40 in at least two places based on its number. And checking it on a map, it does look like I440 is a beltway through Raleigh.

Also, I can see an I540, which means a spur off of I40 that. And you can see that I540 connects to I40 in one spot and deposits you near I87.

sure not a usa-ism, but just bad software. We'd probably say the A6 or the A6thou or something short. or the 21-79. whatever's shortest and not a mouthful.

true 'mericans don't even know how to pronounce-out numbers that bigly

here in california there is this delightful local custom to give the freeway some random place name that changes every two miles, but give all the signs a number. or vice versa.

so it sounds like: "turn north on the rancho-el-coronado-pacifico-jackson expressway" which means turn "physically east on the 610" because it's actually north-south, but run's east-west "logically".

then for extra fun, add state highway numbers that overlap the us freeway numbers and use lots of proper nouns. as in "a crash occurred at the interchange of the northbound 415 and the 188 at the south 67 jason plotz memorial parkway on the escobar-de-los-muertos exit headed eastbound". i don't even know what i just said, but at least twenty commuters reading this just rerouted to avoid this mess.

Some languages distinguish between these two types of numbers, like French "numéro" vs. "nombre". I don't know what a suitable English term would be, maybe "digit sequence" vs. "number"?

Numeral vs number.

Numerals are symbolic representations using digits, but may or may not have numeric properties.

I get medical bills from different providers. All of them provide me an account code to enter.

The instructions tell me to enter the account code "exactly" as on the paper.

Except for the fact that it starts with <letter><dash>. I'm supposed to omit that part...

As a webdev I just really want to submit a PR.

Some developers mix up validating and sanitizing.

If you can sanitize, then it doesn't matter what the user input was.

If validation fails, notify the user.

Obviously a lot of sites do format credit card numbers, but keep in mind that does add an additional level of complexity because you have to verify the type of card and what formatting to perform. American Express uses 15 digit numbers grouped in 4-6-5 format, so if you accept AMEX, you have to take that into account.

also when it has a maxlength which truncates last digits when you paste a copied CC number that contains spaces/dashes.

even worse with IBAN numbers

It's just as bad when sites won't allow me to enter it as a 15-16 digit string.

Another gripe is when it requires me to tell it what kind of card it is, when it also then validates the BIIN, and tells me I'm wrong if I forget to chose - why not just fix it for me?

On a side note, the Gov.UK site is one of the best sites Ive come across, especially for a government. It's incredibly simple and easy to navigate. It's easy to find any information you're looking for and all information is explained in very clear and simple english (unlike many other government sites, which are convoluted and fill of jargon).

IMO this is the gold standard for government websites

One failing, which I think it's significant, is that pages which are written as authoritative do not specify where they derive their authority from. Specifically, what I'm thinking of is finding information that says something is obligatory or forbidden but doesn't say what laws/rules/customs/departments make this the case. More links to legislation.gov.uk would improve the democratic status of the website.

Agreed. Only yesterday i wanted to know what the actual legal rules about working time are; starting here, the top Google result, it's a dead end:

https://www.gov.uk/maximum-weekly-working-hours

Absolutely. This is an excellent point. I’m sure it’s no accident either.

And it only got worse during the pandemic when the Gov purposefully tried to conflate their word with the law, using gov.uk to do so.

The IRS does this too; you can ask the IRS for their opinion on a tax matter, and they can give you a letter that states their position; which is a defense if you follow it, but it's not necessarily how the courts would rule. Many times it is worth following the letter of the law and being ready to defend it in court.

There are a few services that seem almost deliberately bad though.

Tax Free Childcare is a scheme that allows you to pay for daycare and get a 20% discount applied via the government.

It works quite well, but I'm convinced there is a deliberate attempt to frustrate people and stop them using it to save money.

For example, you cannot bookmark the sign-in page, you have to search for it from the gov.uk homepage each time and go through several intro pages. And then you have username + password + 2FA + 3 security questions.

And you have to login every 3 months to re-declare your eligibility.

> There are a few services that seem almost deliberately bad though.

The UK's Driver and Vehicle Licensing Agency takes this to an extreme by not offering online versions of some key services, such as re-applying for a driving license after a medical suspension. If your re-application involves a fee, you have to send them a (paper) cheque or postal order. I do understand that a postal order is a valid form of payment, even in the year 2022 (it can be used by people without a bank account), but not to offer credit card payment or bank transfer is amazing.

I can confirm that the DVLA treats everyone it deals with as a liar and criminal, even if no crime or deception is involved. It took me a decade to get my driving licence back after it was confiscated; it needed renewing, and the renewal form required me to state whether I had received treatment for alcohol problems. I told the truth - I had received treatment a few years back, I was clean, and I could prove it. Snatch - licence revoked. Cue ten years of legal and medical hassle and cost.

[Edit] I didn't own a car, I'm against private vehicles on the whole, and especially ICE private cars. I wanted to be able to hire a car occasionally. And a driving licence can be a requirement for certain jobs, even if they aren't "driving" jobs. A driving licence is the standard ID here; if you have neither a passport nor a DL, you will have to jump through hoops to prove your ID. So I'm angry that the DVLA can administratively deprive you of rights for ten years, without the matter ever coming before the judiciary.

> you cannot bookmark the sign-in page [...]

It's quite well hidden but the link to sign straight in is here:

https://www.gov.uk/sign-in-childcare-account

You are absolutely on the mark regarding this service though. It's bananas.

The gov.uk sites have indeed got a lot better (although "best I've come across" isn't language I'd have chosen).

UK government websites used to be AWFUL. Navigation and signposting is still awful; but UX has improved a lot in the last two years. And their approach to cross-device UX isn't bad (it's impossible to be "good" with mobile devices, IMO). But ten years ago, my sense was that government websites really didn't want people to interact with the government electronically at all. You had to use Internet Explorer; you had to authenticate, which meant getting an ID, which required physical documents, so a postal interaction.

It's much better now, but that doesn't mean it's good.

Another problem with `type="number"`, that this blog post does not mention - although for good reason (it's British) - is that different versions of Android will provide either "." or "," decimal pointer, depending on locale or not at all. Some phones - regardless of how much you insist on a comma-locale - would still provide "." as the only option. Eventually, we had to switch to `type="text" inputmode="numeric"` and interpret both "." and "," as a decimal separator. Most people won't bother to enter thousand separators anyway.

These numbers were amounts, i.e. actual numbers, and not text fields with only digits, so `type="number"` doesn't even work for actual numbers, as soon as you move beyond English.

If you handle the data programatically parseFloat will always work as expected. No good solution for native submit though :/

TIL about inputmode="number" - this is great! https://developer.mozilla.org/en-US/docs/Web/HTML/Global_att...

I wish more sites used appropriate inputmodes - it is often a pain in the backside to enter numeric information on mobile.

Midway through the article I was just thinking, "they should add something to the standard that lets you control which native keyboard is used for a field without all this other semantic baggage"

Lo and behold!

Probably going to use this at work today :)

Exactly! This is an amazing attribute.

I really like the effort gov.uk puts on it. IIRC there's a similar thing getting traction in Italy. Why can't we have anything similar in Spain? Some regional governments already have with more or less success but central state services are a complete mess. No consistence at all, and some websites are so badly made that if feels like it was the intent.

AFAIK there isn't a lowest bid system anymore, so why is everything so difficult?

Just imagine being able to worry because some stuff doesn't work with screenreaders...

We had a similar thing in Australia - the Australian Government Design System: https://designsystem.gov.au/

It is in use across a huge number of Australian government websites - the Australian Cyber Security Centre, Services Australia, Department of Health, Department of Veterans' Affairs to name just a few.

The agency that owned it had a huge amount of funding cut from its budget, and now it's being supported by an (admirable!) open source effort: https://designsystemau.org/

It's wonderful that there is this level of community support, but so disappointing that the government couldn't recognise the importance and usefulness of continued funding.

> The Australian Government Design System has been decommissioned and will be taken down on 30th Sep 2021.

Much like everything else that came out of that agency, it was released and then promptly abandoned.

The goal at various points was something gov.uk-like, but I think we failed pretty miserably on all counts.

Feels really wasteful that Australia would try to come up with the same thing rather than just using the UK one, if that's essentially the goal anyway.

https://design-system.service.gov.uk/

It's even published under this liberal license:

https://www.nationalarchives.gov.uk/doc/open-government-lice...

I feel this in my bones. Working on my Spanish tax return, and agencia tributaria's site has some of the most diabolical form validation I've ever encountered. They validate onblur and clear the field + popup an error dialog whenever validation fails - which triggers every single time I alt-tab out to my financial statements... grr

And Hacienda is one of the most widely used interfaces. Wait till you have to use some obscure system.

Luckily some other level of government made another interface for the same system cos they got tired of it.

I may be wrong, but I believe the gov.uk website work was originally done by a small consultancy who clearly knew what they were doing, which makes it something of a unicorn, as government IT work is usually farmed out to one of the big "jack of all trades, master of none" consultancies, with wearyingly familiar results in terms of low quality, cost overruns etc.

What was unique about GOV.UK is that it wasn’t done by a consultancy.

They managed to build an in-house, central resource (GDS/Government Digital Service) and pioneered a lot of public service design practices which are the template for USDS and others.

However, my understanding is that the GDS team is greatly diminished these days and the consultants are back across separate government departments again.

> However, my understanding is that the GDS team is greatly diminished these days and the consultants are back across separate government departments again.

That just seems to be the natural cycle of life. Some (somewhat independent) part of the government does something good and admirable, all of the self-interested politicians and other functionaries see that success and want to have a part of it, insert themselves and their interests into the thing, and in the process end up ruining it because they had no idea what they were talking about and should instead have left that work to the domain-experts which managed to make it successful in the first place.

There is a similar effort in France: https://www.systeme-de-design.gouv.fr/ and there are, presumably, other efforts elsewhere.

But the french administration has been very heavily centralised since forever, which probably makes that kind of project easier to run.

Wow I think this one is the best yet, I really like the visual look too. But it doesn't seem ready to be used? A part from the confluence link there's no mention of a license or how to use it a part from a "contact us" form.

Indeed it is not final but design systems are living entities anyway. It already covers quite a lot.

When to use and to not use it is slightly vaguely explained here: https://gouvfr.atlassian.net/wiki/spaces/DB/pages/606012403/.... If I understand correctly, it's supposed to become mandatory at some unknown point in the future for all websites operated by the state. Whether some or all of it could be used by other entities and under what conditions is not exactly clear to me.

> Il est formellement interdit à tout autre acteur public d’utiliser le système de design de l’État (les administrations territoriales ou tout autre acteur privé). Le système de design de l’État représente l’identité numérique de l’État. Par conséquent, ces entités ne sont pas concernées par son déploiement ou son adoption.

> Par ailleurs, en cas d’usage à des fins trompeuses ou frauduleuses, l'État se réserve le droit d’entreprendre les actions nécessaires pour y mettre un terme.

They mention the non-state-operated public sector and fraudulent use but not much beyond that.

There are some negatives too. The design pattern doesn't work well for some specialist websites that get jammed into the gov.uk mould. Overall though, it's better than the mish-mash of styles and the duplication of effort across many different departments and levels of government.

I think most of these issues should really be fixed in browsers though... And when they are, people will probably still point to this page for years... Hope this helps to bring visibility to the problems though...

I think the thing to remember here is that inputs should only be `type=number` where the semantic value is best represented with a numeric scale, not just where it is a number only field.

> A simple way of determining whether to use type=number is to consider whether it would make sense for the input control to have a spinbox interface (e.g. with "up" and "down" arrows). Getting a credit card number wrong by 1 in the last digit isn't a minor mistake, it's as wrong as getting every digit incorrect. So it would not make sense for the user to select a credit card number using "up" and "down" buttons.

I don't think browsers can infer the semantic intent enough for this to be a fixable problem without some distinction in syntax.

> e.g. with "up" and "down" arrows

I never used those except for testing to see what they do. They are always useless to me.

Depending on browser, they can be used with a scroll wheel as well. And of course, on mobile they will have different UI elements. But yeah I don't get the tiny up/down arrows either.

> with a scroll wheel as well

This happens to me accidentally while scrolling. Then I order the wrong quantity and such.

Yeah exactly, a phone number or credit card number may look like a number, but they're not. input type number will also discard leading zeroes, for example.

That said, I feel like the organizations behind HTML gave up too fast; they should have continued with input types for phone numbers (that e.g. phone manufacturers could then integrate with contacts without revealing anything to the website in question), credit card numbers (supporting all formats and with built-in format validation), etc. But they seem to have stopped 10+ years ago with HTML5's broken number input.

Enumerating types might be cool for semantic web, but what I'd love as a dev is a system for enumerating valid characters, so I can put digits and dashes, or only Latin letters, and the device figures out the best keyboard to use

The article gives two reasons for the choice:

> 1. Accessibility

Here I agree with you that it feels like a workaround. Well, technically, it is not the browsers that need fixing, but rather Dragon Naturally Speaking and the NVDA screen reader.

> 2. Incrementable numbers (the fact that long series of digits get reinterpreted as large numbers, which causes all sort of issues, like them being reformatted in scientific 1.23e+45 notation)

Here instead it feels more like a legitimate things both on gov.uk's part and on the browser's part. "Numbers" and "long series of digits" are fundamentally different things, and it seems normal that they would be described with different input fields. (Now how those input fields should be named, that I am not qualified to have an opinion on.)

A workaround can just as easily become tacitly expected domain knowledge that serves to obfuscate both the problem, and its solution, sadly :/

All the while SOME people use the browsers' implementation, and the browsers become an ever-increasing spaghetti of complexity and security holes that everyone is mandated to use.

I wonder if Gov.UK works with browser makers?

They do pretty extensive usability testing, and if I was a browser maker I'd listen to what they had to say.

Yes, in a way. When I worked for GDS, I was their representative to the W3C. There are still a number of people there who are on various W3C committees where - I assume - they regularly interact with browser makers and other interested parties.

> I wonder if Gov.UK works with browsers?

You mean works with browser developers? Otherwise I can't see the reason why their site wouldn't work on modern browsers. Especially given the lengths they'll go to make sure it's as accessible as possible.

Edit: formatting

Agree with you, but also, for how many decades should they wait for browsers to get their shit together? It's not as though input type="number" is particularly new.

In retrospect, they should have left all these special input types out and let application developers handle it with Javascript. There are too many real world cases they cannot handle, and real world knowledge probably shouldn't be hard coded into web browsers in the first place. The date entry is an example of something that is particularly useless - it is not flexible enough.

I don't want the browser to know or dictate what date format to use, that is the application's job, and the date input doesn't even let web applications specify the format. So you have a substantial engineering effort half implemented across a handful of browsers that approximately no one can use.

This is very interesting... I'm really happy to see this kind of information published as a blog post, with reasons and explanations... I read through and forwarded a link to it to our UI team, and all the data is there justifying the change.

Many of the (relatively) newfangled HTML input types exhibit this kind of half-baked behavior, coupled with a surprisingly stubborn lack of extensibility.

type="number" doesn't support thousands separators in any meaningful way.

type="date" and type="time" only display their values in the user's system locale, not the locale of the page. There's no way to change the format.

type="color" doesn't support RGBA and can't be in an empty state. If you try to unset its value, it always defaults to #000000, even in dark mode.

type="email" and similar text-like types don't offer any feedback for invalid values until you try to submit the form.

No wonder people are just using type="text" and relying on Javascript to achieve reasonable behavior.

While true that they don't show the feedback, you can use `.validationMessage` to retrieve it and show it yourself.

Also, input type=email has been in Firefox, Chrome, and Safari for over a decade. It's not exactly new.

My proposal:

* a type=count which is used for specifying a "count of things". This is the only type that should display arrow up/down as the current type=number does. The arrows must be easy to remove because sometimes add/remove 1 does not make sense. To avoid problems with rounding, browsers must restrict min/max to be +/- 1e15 so the value always fits safely into a double (due to javascript numbers). Some people will have an objection to this, but how many times do you specify a count that is bigger than 1e15? Browsers could present an optimized UI (e.g. a dropdown) when e.g. min=0 and max=10.

* a type=digits which as default allows for digits, dashes, spaces. Useful for creditcard numbers. Having this as distinct type makes it easier to get good keypad on mobile.

* a type=price which is optimized for input for money as the general type might not be good at giving good error responses for "too many decimals". Could have currency as attribute for display on mobile input for countries which use multiple currencies and therefore having this displayed is important.

* a type=int which is used for integers to make it easy to make sure the number is an integer. Current html requires too many attributes for this common task.

* a type=number which is used for any other kind of number.

I had submitted a proposal [1] to add type="digits" last year, when I was faced with similar issues designing TOTP/PIN controls. Didn't gain much traction though.

[1] https://github.com/whatwg/html/issues/5209

The phrasing in the standard they quote:

> The type=number state is not appropriate for input that happens to only consist of numbers but isn't strictly speaking a number.

sounds like silly self-contradictory nonsense, probably written by someone who didn’t know words like ‘digit’ or ‘quantity’, which would help tremendously to disambiguate this. (Ideally, it would have been <input type="quantity"> from the start, so that nobody would even think of using it for digit-based identifiers.)

Seriously, thesauri can be occasionally useful for something beyond sounding smug. (Not that it isn’t an advantage in itself…)

What's very disappointing about many of these problems is that it's browsers being really dumb & hostile to users. Chrome suddenly changing the number format, Safari trying to "auto-correct" numbers. No one asked for these "features".

Spinning can be prevented (by attaching event handlers), and the spinner buttons can be hidden.

The disadvantage of the proposed solution is the lack of (automatic) feedback. Browsers tell you when the a number input exceeds the min/max range, in the browser's default language. If you want to validate a text input field and tell the user the number is too low or too high, you'll need to provide your own translated text.

Yes...but that has a flipside: "Credit card number must be less than 9999999999999999" is completely useless, and you can't customize that.

I'm not saying that you should use a number input for credit cards. That's an identifier that happens to consists of digits, not a number. But for things like age, or number of items?

Related: I've been struggling for a long time to figure out the best way to implement a currency amount input. In my case I only need to support a single currency (USD), e.g. $9.99. Should it be type=number? type=text? Should I add an input mask? I haven't been able to find a clean answer I'm happy with.

Try the combination of the article - it is what you want.

But that won't show the dollar sign ($). It would also allow bogus fractional-cent values like 9.999. And it would display values like 9.9 (one decimal place) instead of the correct $9.90 (two decimal places).

If you’re only supporting USD, I would prefix the input with the dollar symbol, I.e. so that it appears to the left of the input rather than as a part of the input itself. This signals the website is accounting for the fact that the given value must be a quantity of USD.

You can use a type=number input and prevent bogus fractionals by setting the ‘step’ attribute on the input to ‘0.01’. This will do two things: the up/down clicker buttons will increment/decrement by 0.01, which IMO is all they’re useful for, and the browser should restrict values to two decimal spaces. Of course you still need to validate this on the backend.

type=number allows for weird exponential notations AFAIK.

Maybe take out the dollar sign from the input-value. Or just adjust the regex. Or just validate with js/serverside.

can't you use regex to only allow two decimal places?

this was on just a while ago..?

https://news.ycombinator.com/item?id=22433654

I hereby coin the term "pseudo déjà vu" – when something feels like a déjà vu but its actually for real.

That's over 2 years ago now. A bit more than "just a while ago", and perfectly fine to repost IMO.

> when something feels like a déjà vu but its actually for real.

...isn't that just remembering?

That's over two years ago and I don't recall reading it at the time. I think there's some sort of 'soft' rule about dupes though, if its less than a few months.