Hacker News Reader

Comment by throwup238 | Hacker News Reader

The feature proposal was called HTML Imports [1], created as part of the Web Components effort.

> HTML Imports are a way to include and reuse HTML documents in other HTML documents

There were plans for <template> tag support and everything.

If I remember correctly, Google implemented the proposed spec in Blink but everyone else balked for various reasons. Mozilla was concerned with the complexity of the implementation and its security implications, as well as the overlap with ES6 modules. Without vendor support, the proposal was officially discontinued.

[1] https://www.w3.org/TR/html-imports/

View on HN

That matches with the comment [1] on the article, citing insufficient demand, no vendor enthusiasm, etc.

The thing is that all those are non-reasons that don't really explain anything: Low demand is hard to believe if this feature is requested for 20 years straight and there are all kinds of shim implementations using scripts, backend engines, etc. (And low demand didn't stop other features that the vendors were interested in for their own reasons)

Vendor refusal also doesn't explain why they refused it, even to the point of rolling back implementations that already existed.

So I'd be interested to understand the "various reasons" in more detail.

"Security implications" also seem odd as you already are perfectly able to import HTML cross origin using script tags. Why is importing a script that does document.write() fine, but a HTML tag that does exactly the same thing hugely problematic?

(I understand the security concern that you wouldn't want to allow something like "<import src=google.com>" and get an instant clone of the Google homepage. But that issue seems trivially solvable with CORS.)

[1] https://frontendmasters.com/blog/seeking-an-answer-why-cant-...

JS-first developers want something that works the same way client-side and server-side, and the mainstream front-end dev community shifted to JS-first, for better or worse

Maybe something that adds to this low demand is that: 1. Web pages that are developed from the viewpoint of the user having JS, makes it trivial to implement something that provides the same results. 2. Web pages that are developed for user agents that don't run js, probably want to have some interaction, so already have a server runtime that can provide this feature. 2b. And if it doesn't have any user interaction, its probably a static content site, and nobody is writing content in HTML, so there already is a build step that provides this feature.

That is a bit of a large ask.

There are various specs/semantics you can choose, which prescribe the implementation & required cross-cutting complexity. Security is only relevant in some of them.

To give you some idea:

- HTML load ordering is a pretty deeply held assumption. People understand JS can change those assumptions (document.write). Adding an obscure HTML tags that does so is going to be an endless parade of bugs & edge cases.

- To keep top-to-bottom fast we could define preload semantics (Dropping the linear req-reply, define client-cache update policy when the template changes, etc). Is that added complexity truly simpler than having the server combine templates?

- <iframe> exists

In other words, to do the simplest thing 75% of people want, requires a few lines of code. Either client side or server side.

To fit the other 25% (even to 'deny' it) is endlessly complex in ways few if any can oversee.

HTML imports could not include markup within the body, it could only be used to reference template elements for custom elements

HTML Imports went in a similar direction but they do not do what the blog post is about. HTML should be imported and displayed in a specific place of the document. HTML Imports could not do this without JavaScript.

See https://github.com/whatwg/html/issues/2791#issuecomment-3112... for details.

To be fair, it was pretty complicated. IIRC, using it required using Javascript to instantiate the template after importing it, rather than just having something like <include src="myinclude.html">.

https://caniuse.com/imports says FF even had it as a config flag

Tbf, HTML Imports were significantly more complex than includes, which this article requests.

Frames essentially could do html import

Reply on news.ycombinator.com