I've been working on a little demo for how to avoid copy-pasting header/footer boilerplate on a simple static webpage. My goal is to approximate the experience of Jekyll/Hugo but eliminate the need for a build step before publishing. This demo shows how to get basic templating features with XSL so you could write a blog post which looks like
<?xml version="1.0"?>
<?xml-stylesheet type="text/xsl" href="/template.xsl"?>
<page>
<title>My Article</title>
<content>
some content
<ul>
<li>hello</li>
<li>hello</li>
</ul>
</content>
</page>
Some properties which set this approach apart from other methods: - no build step (no need to setup Jekyll on the client or configure Github/Gitlab actions)
- works on any webserver (e.g. as opposed to server-side includes, actions)
- normal looking URLs (e.g. `example.com/foobar` as opposed to `example.com/#page=foobar`)
There's been some talk about removing XSLT support from the HTML spec [0], so I figured I would show this proof of concept while it still works.[0]: https://news.ycombinator.com/item?id=44952185
See also: grug-brain XSLT https://news.ycombinator.com/item?id=44393817
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.