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.
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.
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.
- Custom HTML elements
- Shadow DOM
- HTML imports
- HTML templates
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...
> HTML Imports were redundant, since you need JavaScript to bring them alive anyways
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.
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.
HTML Imports were shelved because they didn't integrate with the JS module graph. HTML Modules will do that someday.