[Closi]

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.

[xupybd]

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

[andi999]

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

[darrenf]

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

[andi999]

of course!

[Closi]

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

[HPsquared]

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)

[spiffytech]

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.

[david422]

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.

[nightpool]

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

[JulianMorrison]

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.

[Kwpolska]

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.

[JulianMorrison]

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.