3 ms·
The death of HTML imports killed web components for me. With HTML imports, you would import a HTML file. In that file would be css, html and the js to make the
by tarkin2 6y ago
The death of HTML imports killed web components for me.
With HTML imports, you would import a HTML file. In that file would be css, html and the js to make the component. Then you’d use HTML as usual in your main file.
Finally you could create custom components easily while keeping yourself dealing primarily with HTML.
Instead, you were forced to use bizarre js import systems. And at that point you were in JS land. Firefox’s decision not to support HTMLImports in favour of waiting to see what happens with JS killed it.
- flowerlad 6y ago> In that file would be css, html and the js to make the component. You can do that. Here's an example Web Component that contains the css, html and javascript: https://github.com/wisercoder/uibuilder/blob/master/WebComponentsDemo/elements/ZxListEditor.tsx https://github.com/wisercoder/uibuilder/blob/master/WebCompo...
- tarkin2 6y agoI'm talking about how you import that into your main HTML file.
- tannhaeuser 6y agoWhat's the point though to bake that into HTML if you need tons of JavaScript to make it happen anyway? You can just as well use the flexibility of JavaScript to build up component graphs. HTML, or rather SGML, has an established method of syntactically composing fragments using SGML entities that is well integrated into the process of editing HTML using plain text editors, not to speak of extending the vocabulary with new elements and their content models in powerful ways. Introducing elements into markup using script rather than declarative means only serves to complicate parsing, with questionable benefits.
- tarkin2 6y agoBecause with HTML you would use HTML to structure your elements. Javascript was never designed to structure element s we get things like JSX, to compensate, adding further complexity. HTML Imports was an attempt to keep with the existing platform.