Just Let Me Write Digits

I've always found it weird when a form admonishes you for writing spaces or dashes in e.g. a phone number or credit card number. Hey, implementation, you're a computer! Strip them out automatically on the backend if you don't like them!

> So statistically speaking I’m surprised that this bug hasn’t been noticed and fixed yet!

I'm not so surprised, given that you cannot write support tickets if the bug prevents you from registering...

Also, I don't think people have high hopes that a broken government website will ever get fixed.

Reading this makes me feel like we have not learned any lessons at all in software engineering and UI design since the 1980s.

As someone who uses Programmer Dvorak I often encounter pages where the js uses `event.code` instead of correct `event.key`. Silent discards of the shift key also affect Programmer Dvorak as the numbers require it.

I have two products in the wild with PIN entry for kiosk users that have a regular text input field. I have been asked if it could be the typical single digit boxes thing like this, but _never_ by the actual kiosk users. The kiosk users don’t celebrate my input type choice either. It just goes to show that most users won’t even see the details unless they are impacted by those choices.

I'm curious if there's a reason this six-cell mechanism has become the defacto?

It seems this should just be a single input field styled appropriately, but it feels like there must be an underlying reason I'm missing.

Web developer classic: use Javascript to replace the native, working, internationally supported standard inputs with a different input mechanism that doesn't work.

(saving you a click: AZERTY has digits on the shift key, and for some reason the JS is handling raw keys rather than processed characters)

Another peeve I have with this type of input is when entering the last digit automatically submits the form. Once I fat-fingered the last digit and was about to hit backspace, but it was too late, the form submitted and verification failed. I had to wait an excruciating amount of time for the SMS send rate limit to expire before I could try again (I no longer remember which service this was for).

Same, but for dates. There's <input type="date">; it's literally a solved problem ffs. Forcing to scroll through years, months and days in your remarkably creative date selection widget is extremely user hostile.

On X.com on my Chrome browser I am unable to correct digits if I entered a wrong number.

Very nice blog layout btw.

FWIW In the Apple ecosystem this usually gets filled in automatically based on the source.

Yet another example where using <form method="post"> and <input> with zero JavaScript would be a better user experience. If you are going to write custom code you have to clear the minimum bar of what the browser provides.

On their website, when I enter a digit, the cursor advances to the next input box automatically. Deleting a digit with backspace also jumps back to the previous box. Seems to work perfectly for me. Maybe fixed since yesterday?