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.
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.
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...
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.
(e.g. a CC number input and stored as "1" and displayed as "0000 0000 0000 0001" - an extreme example I know)
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.
Graphically I was thinking of the opposite of hiding the number, but rather making it clear to see by automatic digit grouping and stuff.
I would bet this sort of pragmatic workaround is taking place.
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.