Comment by lloydatkinson
16 hours ago
The moronic Web Component cabal got their hands on it and trashed it by forcing it to rely on JavaScript, thus ensuring it would never get support.
16 hours ago
The moronic Web Component cabal got their hands on it and trashed it by forcing it to rely on JavaScript, thus ensuring it would never get support.
I'm sorry, this a dumb comment that has no basis in reality.
HTML Imports was part of the initial set of the web components specs, there's no "cabal" or whatever that got its hands on it, and it didn't rely on JavaScript, not in the way you're probably referring to.
It was only opposed because it was separate from the JS module system, not because it relied on JS.
It's replacement: The HTML Modules proposal has general support from all vendors, just no one has put together a complete proposal yet.
It was rejected because it needed JS to even work.
This is simply not true, both in how it worked and why it was rejected.
HTML Imports didn't need JS to work: they used link tags and could transitively import HTML files without any JS.
You only needed JS because the wasn't anything you could do with the HTML yet because declarative custom elements don't exist yet.
HTML Imports were rejected because they created a parallel module graph to the JS module graph.
I think they could have been made to share the same graph, but that's basically what HTML modules are anyway.
For a long time web components generally built on four standards:
https://korban.net/posts/elm/2018-09-17-introduction-custom-...
Eventually it became clear some browsers were not going to implement and the design of HTML imports was better handled be ES modules.
https://webmasters.stackexchange.com/questions/127482/on-wha...
Found this, it should answer your complaints:
> HTML Imports were redundant, since you need JavaScript to bring them alive anyways
Exactly. I think the problem wasn't that browsers (specifically Firefox and Safari) were opposed to the idea of html includes in general, but they didn't like the specific proposal, in large part because it still required javascript, and added a lot of complexity for little to no benefit.
I think rejecting that proposal was the right thing to do. What disappoints me is that there hasn't been a more declaritive, simpler proposal that has gotten anywhere.
HTML Imports and HTML includes are two different ideas. HTML Imports was never like what people want from HTML includes.
HTML Imports were shelved because they didn't integrate with the JS module graph. HTML Modules will do that someday.
> What disappoints me is that there hasn't been a more declaritive, simpler proposal that has gotten anywhere.
Possible names: Client Side Includes (CSI): Like Server Side Includes (SSI) in Apache IHTML (inline html): Like the iframe tag, but for html instead of whole page.