Hacker News Reader

Comment by zxcvgm | Hacker News Reader

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.

View on HN

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!

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.

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.

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.

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.

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.

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

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

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.

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!

... but not if you type dot instead!

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.

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

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.

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>

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.

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.

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)

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.

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.

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.

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

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 is to say it's a numeral

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

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.

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.

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.

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.

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

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?

Reply on news.ycombinator.com