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