Please revisit HTML Imports

[matthew-dean]

I'm disappointed by the industry rejection of HTML Imports. IMHO the web has needed declarative HTML imports since HTML 1.0. The lack of it has been the reason why so many server-side templating languages have needed to exist, when their only reason for being has been that web pages can re-use all assets across pages (JS and CSS) except for other HTML partials.

I think one of the reasons for this rejection is that the use-cases for HTML imports have been so narrowly scoped to defining custom elements. But the reason to have HTML imports extends far, far beyond web components to the fundamentals of web page construction.

I think if HTML Imports could be redefined with a broader scope, it would be more obvious to vendors that ES6 JS Modules are not a sufficient replacement for the power of what HTML Imports can do. (And maybe that's only because the current editor's draft is not flexible enough to be used for importing partials declaratively?)

[matthewp]

Hi @matthew-dean! You'll hopefully be happy to know that they are being revisited, see #645 for the ongoing discussion.

[matthew-dean]

@matthewp That's great! Although it's a little disappointing that the conversation is so focused on a JavaScript-based solution. 😞 I mean ES6 modules are great but they're just not necessary to declare an HTML import. It looks like people are very focused on injecting Webpack-like syntax into JavaScript.

[matthewp]

That conversation has several different threads of ideas so it's hard to follow, but I don't think any of them require that you use JavaScript to import HTML. One idea would make this work:

<script type="module" src="./path/to/element.html">
<my-element></my-element>

Of course, element.html likely contains some JavaScript to do anything useful, but using it wouldn't necessarily require JS.

[matthew-dean]

@matthewp Hmm, I see. Well, that's better than nothing.

[rniwa]

I don't think anyone thinks it's not important. It's just that new mechanism to import & integrate a separate HTML document requires a well thought out solution. Right now, we're exploring what the declarative syntax for custom elements should look like, and that should help us guide what the importation mechanism should be.

Relatedly, it would be great if you can enumerate a list of concrete use cases (not some generic description of what API you want but a concrete user/developer scenario).

[TakayoshiKochi]

Thanks @matthew-dean for raising your interest and concerns!
I don't repeat what @rniwa said above, but we are always glad to hear any use cases or different ideas.

I'll close this in favor of #645 but your voice is certainly heard.

[matthew-dean]

@TakayoshiKochi @rniwa Thanks for listening. And I hope that declarative HTML Imports could be considered for replacing unnecessary server-side templating solutions someday.

[Kuzcoo]

I think one of the reasons for this rejection is that the use-cases for HTML imports have been so narrowly scoped to defining custom elements. But the reason to have HTML imports extends far, far beyond web components to the fundamentals of web page construction.

I think this issue should leave on its own, as @matthew-dean clearly explained the problem at stake in the quote above.
The #645 dicussion seems to be js oriented, and I think the @matthewp snippet is a very promising js free approach.
We should forget highly dense js webapp for a moment, and think of a html/css first approach, progressively enhanced by js if supported/loaded/not breaking.
All web apps are not rich and complex applications, but just a bunch of nav and form aggregations with strong visual identity, and we rely on heavy js client side render and tooling for a bunch of UI functionnal components.
We should be able to load the html/css of the component even if the js is breaking or is disabled.

[matthewp]

@Kuzcoo I don't believe HTML Imports did anything useful without JavaScript iirc. I think others agree that being able to define components using only HTML/CSS is a good goal (I do!).

I think you might be thinking that because HTML modules goes through the JavaScript module system that it means they are for JavaScript oriented sites (SPAs if you will) but that's not the case. They serve the same use case as HTML imports, just use a different mechanism.

[Kuzcoo]

@matthewp : ok. If we could just link the html fragment and use it as such <my-element></my-element> as you wrote it above it would be great. Otherwise we should import doc from "my-element.html"and clone and append for every single element we need, it seems tedious. It is not necessarily a matter of creating functionnal components but it is very much about ux/ui scaling and having a reusable source of truth for branding consistency and semantic/accessibility issues, and stability through css in shadow dom.

Also, it looks counterintuitive to need js to serve HTML. import everything as a js dependency is a webpack philosophy, we don't have to see through that bias.

[matthew-dean]

import everything as a js dependency is a webpack philosophy, we don't have to see through that bias.

Exactly. It's counter to the existing platform. HTML should be imported via other HTML declarations. To the extent it's created via JS, JS should create the HTML import, and that import should have a DOM interface to get access to the imported tree. But import doc from "my-element.html" is super-webpack-y and very counter to existing HTML/CSS/JS architecture and separation of concerns. HTML importing should not happen via JS nor require JS for it to happen. It should be imported declaratively just like external stylesheets.

[domenic]

You can use <script type="module" src="my-element.html"></script>.

[Kuzcoo]

@domenic : do we still have to execute customElements.define inside this HTML file in a <script> tag or as soon as imported by the browser, the custom element will be registered ? Maybe I did not read quite well the discussion, but I don't see any document summarizing what have been told.

Furthermore, here we assume the .html snippet is a JavaScript module.
I think it is not semantically correct to have a html file as a JavaScript module.
Don't know why <link rel="import" ...>has been dropped.

The HTML External Resource Link element () specifies relationships between the current document and an external resource.