5 ms·

Fun read, but to say web components would solve any of this is just wrong. You've got to remember that there are two sides to the coin: presentation and functio

by mstade 11y ago

Fun read, but to say web components would solve any of this is just wrong. You've got to remember that there are two sides to the coin: presentation and functionality. The presentation problem can be solved by web components (more accurately: the encapsulation of presentation,) but the functionality bit should be solved with proper JS APIs. That there were no proper JS APIs available 21 years ago is understandable – after all the language barely existed. But that we don't have proper input APIs today is just silly.

webXL 11y ago
You just said they help the presentation differences of these controls, so they solve some of this, even though they bring a different set of problems. The JS API isn't that bad as everyone makes it out to be, especially since Microsoft is getting more standards compliant. And where it is bad, we see things like jQuery spring up, that solve more than the original problem (perhaps too much, but that's easier to fix than the browser differences). Perhaps you might define "proper" and provide any compelling examples how the current APIs aren't up to snuff, besides not being able to programmatically select text in a number element and unused checked properties. I'm curious.
rictic 11y ago
Custom elements can have their own JS apis! They're not just for style. Check it: http://www.html5rocks.com/en/tutorials/webcomponents/customelements/ http://www.html5rocks.com/en/tutorials/webcomponents/custome...
- mstade 11y ago
  Sure, and that's cute, but now make me an API that picks a file from a user's hard drive – or a photo from the photo roll. Yeah. My point isn't about putting JS on to DOM, that can be done without web components too. Rather, it's about the lack of proper access to input devices, actual data that matters.
pornel 11y ago
Indeed. There are no good APIs for this. With raw keyboard events a custom input won't be able to handle autocorrect, Japanese nor Chinese input. There's only draft of a Web IME API, but it still assumes you have a real `<input>` element.
shadowmint 11y ago
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.
- kalleboo 11y ago
  > Input types are inherently simple Maybe if all you need to support is English. 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.

by mstade 11y ago

webXL 11y ago

You just said they help the presentation differences of these controls, so they solve some of this, even though they bring a different set of problems. The JS API isn't that bad as everyone makes it out to be, especially since Microsoft is getting more standards compliant. And where it is bad, we see things like jQuery spring up, that solve more than the original problem (perhaps too much, but that's easier to fix than the browser differences). Perhaps you might define "proper" and provide any compelling examples how the current APIs aren't up to snuff, besides not being able to programmatically select text in a number element and unused checked properties. I'm curious.

rictic 11y ago

Custom elements can have their own JS apis! They're not just for style. Check it: http://www.html5rocks.com/en/tutorials/webcomponents/customelements/ http://www.html5rocks.com/en/tutorials/webcomponents/custome...

mstade 11y ago
Sure, and that's cute, but now make me an API that picks a file from a user's hard drive – or a photo from the photo roll. Yeah. My point isn't about putting JS on to DOM, that can be done without web components too. Rather, it's about the lack of proper access to input devices, actual data that matters.

pornel 11y ago

Indeed. There are no good APIs for this. With raw keyboard events a custom input won't be able to handle autocorrect, Japanese nor Chinese input. There's only draft of a Web IME API, but it still assumes you have a real `<input>` element.

shadowmint 11y ago

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.

kalleboo 11y ago
> Input types are inherently simple Maybe if all you need to support is English. 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.