`number` also unlocks the ability to use a numerical input on a mobile phone. In fact, I imagine this is why there's so many websites using it inappropriately o

`number` also unlocks the ability to use a numerical input on a mobile phone. In fact, I imagine this is why there's so many websites using it inappropriately on desktop: because it makes the mobile experience better. If I was maintaining the HTML spec, I'd do two things: - Deprecate the use of spinboxes on `number` input. Browser vendors would be free to remove the spinbox or only support it in certain circumstances - Add an explicit `interface` attribute (or equivalent CSS properties and psuedoelements) for specifying the kinds of input UI the form author expects to be available to the user. You'll be able to apply multiples of these and to any form input type (including <select> and <textarea>) without changing their validation rules. The browser picks out options that make sense for the current platform and input type and implements those. Interface hints themselves would be things like: - `keyboard` - widget should support virtual input and/or IMEs (on a select, this would also trigger a combobox) - `numeric` - implies `keyboard`, plus virtual input should be optimized for numbers (on a phone, this means give the user a numeric keyboard) - `text` - implies `keyboard`, plus virtual input should be optimized for text of the input widget, document, or user's current language - `nokeyboard` - widget should not support virtual text input of any kind - `increment` - widget should have numeric increment/decrement buttons (e.g. use a spinbox) - `noincrement` - widget should omit numeric increment (no spinbox) - `content` - contents of the field should be visible to the user (even if the field is type=password; this would allow a "show password" box that does not expose the password to predictive text input) - `obscured` - obscures the text input like type=password - `nocontent` - contents of the field are entirely hidden, would allow hiding even the length of a password - `predict` - widget should participate in predictive text - `nopredict` - widget should NOT participate in predictive text, and should not have it's input be fed back into the predictive text system, like type=password - `passwordrecall` - widget should support password recall through a password manager - `nopasswordrecall` - widget should NOT support password managers