It was much more akin to JS imports. HTML files would be side-effectful, then you could use the elements they defined, like <x-foo>.
A web that was built on documents fragments because the JS and server-side developers think writing raw HTML and CSS is gross.
Email developers would like a word with them.
This isn't going away, and at some point, adding more abstractions is actually harmful.
As I have little else to do at this point - Tl;dr When you work for a public library, but are closed the public, nothing happens - I'm rewriting a small microsite I made for job hunting purposes.
Other than a Service Worker cache, it's markup and styles all the way down, stitched together with Make.
For my blog, I've stuck with Liquid, because Jekyll - which I actually like (ducks) - will be interesting to see if this gets revived and actually lands one day.
Started on GH Pages, but moved to Netlify which gives me a bit more fine grained control.
Pardon the dust;
First, I'm not a graphic designer and second this is actually an older deploy that I've "locked" so I can continue tinkering with the master branch behind the scenes. Will be a single page with just anchors to navigate when done.
Everything old is new again. Homepages, kids, ask your parents about them :)
https://hacks.mozilla.org/2015/06/the-state-of-web-component... (ctrl+f "HTML Imports")
"HTML Imports do lend themselves well to a simpler/more declarative workflow. [...] Imports don’t offer enough control to be taken seriously as a dependency management solution. [...] Mozilla had a working implementation behind a flag, but struggled through an incomplete specification."
which to me reads a bit like: "js frameworks won't use it, and the spec didn't get enough love because everybody's only thinking about frameworks rather than vanilla-js."