There should be a declarative way to import HTML modules

[esarbe]

HTML modules promise a new way to structure and re-use HTML content. As such they fill a gap that has long filled by programmatic approaches, with varying success.

However; without a declarative way to consume HTML modules even the simplest use-case requires Javascript. There is no inherent reason why this should be necessary.

Since there are many use cases where HTML modules provide benefit even when there's no JS is in play, I suggest the addition of a declarative way to import HTML modules. This declarative means of importing HTML modules should not require Javascript to be enabled in the Browsers.

[rniwa]

Isn't this <script type="module" src="someHTMLModule.html"></script>?

[justinfagnani]

It sounds to me like this is hinting at an ask for declarative custom elements that could be declared and imported even with JS turned off.

I presume that right now all additional module types will be disabled along with JS - especially since without JS, there's nothing to do with them yet. I'm not sure how set in stone that is, but I guess that could be broached when we finally get to declarative custom elements.

[esarbe]

@rniwa @justinfagnani Yes, indeed. This is (also) about being able to use HTML modules with Javascript disabled. I'll edit the description to make this more clear. Thanks for pointing it out!

[esarbe]

I'd like to point out that even without any Javascript functionality, HTML imports with slotted templates might bring about quite a few benefits. While there's currently no way to register templates without Javascript, I hope this is something that will be addressed as soon as modules are through.

[devingfx]

Why not :
<template src="my-include.html" in-place>

Meaning being able to load template by external source adding a src attribute, the content take place in the <template> element as it was written there.
And add the ability to render the template tag's content like a normal element with an in-place attribute (or whatever name, it can be also disabled to tell to disable template's element normal behavior) .
It offers the ability also to load templates without in-place attribute for no render, and still use it with JS.

---

Another more exotic syntaxes can be:
<div src="my-part.html">placeholder</div> >>> Alowing each element to load it's content
<content src="my-part.html">placeholder</content > >>> A root document's content element

[devingfx]

Another thought:
Maybe even template's content understanding can be part of browser job. There is already a good API for template string in JS, the same parser can be used, and transform the content with data-attributes values :

<template data-who="Doctor" in-place>Hello ${who} !</template>

<template data-who="Doctor" xlink:data-include="#part" in-place>
    <span>Hello ${who} !</span>
    <div>${include}</div>
</template>
<span id="part">o_O</span>

Delegating simple substitution to the browser-land, without needing JS for simple string or element replacement make it possible to use templates with no-script option.

<template data-who="Doctor" src="welcome.html" in-place>placecholder</template>

Then JS authors can still get the template's source and use it as usualy...

And finally, the ability to use another template with a use attribute like the one in SVG :

<template id="welcomer" src="welcome.html"></template>
<div>
    <template in-place xlink:use="#welcomer" data-who="Doctor"></template>
    <template in-place xlink:use="#welcomer" data-who="Master"></template>
    <template in-place xlink:use="#welcomer" data-who="Galifrey"></template>
</div>

[EDIT]: This last attribute can also be simply src (testing if it's an URL or an #id (even a more clear xlink:src )

[devingfx]

Also with a <slot> element at root document :

<header>
    <slot name="slot-with-u" src="welcome.html"></slot>
</header>

... but I still perfer the <content select=""> way !
Augmenting the content element with a src attribute make it more versatile (even in shadow roots):

<header>
    <content src="welcome.html"></content>
</header>

But the precedence have to be solved when given along with a lightDOM content and a select attribute

<content select="span.name" src="welcome.html"></content>

(I'm sure how content element implementation can be used outside a ShadowRoot element...)

This way dissociates the "importing" semantic form the "computed" semantic of a <template> tag, finally adding "loadability" to <template> elements that could self-compute simple substitutions covers more usage that adding "loadability" to <slot> elements...

[rektide]

Even if a page is run in noscript mode, I would like, as a developer, to have the option to pull in modules declaratively. This is one of the greatest most powerful things about HTML and the DOM: that content is declared on the page. I feel like I am doing my users right by including a module in the DOM.

Therefore I do not think this statement should have any impact on what happens with this issue:

It sounds to me like this is hinting at an ask for declarative custom elements that could be declared and imported even with JS turned off.

This is a separate issue. My interest in this issue is in being able to declare what modules I attempted to use.