3 ms·
This is why we badly need an alternative to input's `type` attribute, as the type attribute encapsulates many different things: 1. Validation 2. Autofill hint
by STRML 10y ago
This is why we badly need an alternative to input's `type` attribute, as the type attribute encapsulates many different things:
1. Validation
2. Autofill hints
3. Native helper widgets (date calendar, number input spinner)
4. Mobile keyboard layouts
And, confusingly, while most `type`s are text inputs with differing values of the above, others are very, very different (radio, checkbox, select, file, etc). Still others use completely different tags (like <textarea>) and you even have to switch on `value` or `checked` for checkboxes.
Many people use `type="tel"` or `type="number"` just for the mobile layouts, and spend a long amount of time working around all the awful bugs in number inputs. Our own `<NumberInput>` React component works around multiple browser bugs and took weeks to get right. The incidental complexity even creates very hairy React bugs (https://github.com/facebook/react/issues/7253 https://github.com/facebook/react/issues/7253).
Even if you get around all the bizarre failures in differing implementations, you still have ridiculous spec bugs like the (intended) lack of selectionEnd/selectionStart on number inputs (https://www.w3.org/Bugs/Public/show_bug.cgi?id=24796 https://www.w3.org/Bugs/Public/show_bug.cgi?id=24796) and the like.
I don't know if anyone is championing splitting these concerns into separate attributes, but the web really needs it.