it was proposed and implemented, then the standards body did an about-face.

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."

Actually, they are waiting for module Imports to standardize and get some actual real-world usage. Once that happens, they may move onto HTML Imports. But I feel like they could probably get away with just doing `import Template from "./somefile.html"` using module resolvers.

It's disappointing that JS Frameworks are driving the HTML spec.

HTML Imports was not an <include> mechanism though.

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>.

Sigh.

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.

_This_ front end developer _loves_ writing HTML and CSS, regardless of my previous several years of JS, React, Angular, Backbone etc.

would you mind sharing the source or stack for your microsite? your setup sounds like something i'd enjoy using.

Code is here - https://github.com/chrisfinazzo/reverse-job-posting

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 :)

I vaguely recall doing things with server-side includes and ".shtml" in the late '90s...

I still have a website that uses server-side includes fro the navbar and other common page elements.

https://en.wikipedia.org/wiki/Server_Side_Includes

There's a web component for that! https://github.com/justinfagnani/html-include-element

    <script type="module" src='https://unpkg.com/html-include-element'></script>
    <html-include src="./my-local-file.html"></html-include>

Back in the day we had something which was often used:

<!--#include virtual="/cgi-bin/counter.pl" -->

That was the original web components. Much better. Then they changed it to make it worse. :(

Yeah I remember reading about web components, getting excited and building a prototype. Then when I worked again on the project shadow DOM API changed and HTML imports were removed :| At this point I highly suspects the people behind the Web shit-show (spec writers and implementors) keep things bad on purpose as a way to get job security.

That, and much more, is implemented in SGML on which HTML is based.

Then why not a templating language with looping constructs until it is Turing complete? Because base HTML is a document not a document generation language. Um, until javascript. Oh well.

Thus JS library references basically enable HTML includes.

a document that supports embedding other documents is still just a document.

Ah, but a document that supports including itself, that's the bomb!

That wouldn't be a solution to everything, but at least it would be a starting point to defining a fully-declarative custom element solution so that custom elements can be used in a non-JS context.