To be fair, that's only true of one type of input; the file picker; possibly the color picker too...
The rest of the input types are just text values and some presentation. There's no technical reason for them to all be as absolutely terrible as they are; it's just legacy bloat.
That said, I agree, 'in general' web components probably aren't going to be 'the thing' any time soon; the polyfills are too rubbish, and the native browser support basically doesn't exist yet.
...but the issue is mostly module imports and the shadow dom being ridiculously slow and terrible with nested components.
Input types are inherently simple; there is no reason to have another component inside your input; simple web-components for the most common input types (text, textarea, date, number) seems like a very reasonable and plausible goal.
You've got to admit, if there was a simple way to get consistent cross browser responsive input tags, it'd be awesome.
I have so much trouble typing Japanese even in many native apps (cross platform libraries are usually the culprit), I can't imagine Web developers ever getting it right... For instance it's quite broken off and on in Google Docs.
The rest of the input types are just text values and some presentation. There's no technical reason for them to all be as absolutely terrible as they are; it's just legacy bloat.
That said, I agree, 'in general' web components probably aren't going to be 'the thing' any time soon; the polyfills are too rubbish, and the native browser support basically doesn't exist yet.
...but the issue is mostly module imports and the shadow dom being ridiculously slow and terrible with nested components.
Input types are inherently simple; there is no reason to have another component inside your input; simple web-components for the most common input types (text, textarea, date, number) seems like a very reasonable and plausible goal.
You've got to admit, if there was a simple way to get consistent cross browser responsive input tags, it'd be awesome.