notwaldorf
commented
6 years ago Heh, by "emotional baggage" I meant that it's a very old element (21 years old!) that for backwards compatibility reasons can't really be changed, so it's big and with a bad API as a result. I wrote a blog post with slightly more details about it here and gave a talk about it too.
Letting a user type e for type=number makes sense, because 10e3 is a number. The problem is, however, that input type=number tries to validate the value you enter, and when you enter garbage, is secretly resets it; so when you enter eee even though you can see eee in the textbox, that input's value is actually now undefined (and you didn't get any events telling you this happened). This makes it hard to add fancy error messaging UI that works reliably well.
But otherwise, in general if input type="number" works for you, you should use it. It's just that there's a lot of cases (a telephone number), when it really doesn't, and that's what inputmode is meant to solve.
o-t-w
Hi Monica. I saw your tweet about inputmode, but i don't have a Twitter account so thought i'd ask you here...
I understand that the desktop incrementer/decrementer on desktop for number inputs is sometimes inappropriate (for credit card numbers, to take one example). I am curious what the other problems are though? Letting a user type 'e' is a bit random, but with
<input type="text" inputmode="numeric">the user can type any letter they want, rather than only numbers. I see the automatic validation of input type="number" a useful feature that saves me writing javascript? What is wrong with it?I know that it's possible to make things accessible with aria etc, but why
<div contenteditable inputmode="numeric">when you could have<input type=“text” inputmode="numeric">to avoid the number problems you allude to?You mention "’s years of emotional baggage". I'm a bit uneducated on what that baggage is!
Many thanks Oliver