Webcomponents: Il devrait y avoir un moyen déclaratif d'importer des modules HTML

N'est-ce pas <script type="module" src="someHTMLModule.html"></script> ?

Il me semble que cela fait allusion à une demande d'éléments personnalisés déclaratifs qui pourraient être déclarés et importés même avec JS désactivé.

Je suppose que pour le moment, tous les types de modules supplémentaires seront désactivés avec JS - d'autant plus que sans JS, il n'y a encore rien à voir avec eux. Je ne sais pas à quel point c'est gravé dans le marbre, mais je suppose que cela pourrait être abordé lorsque nous en arriverons enfin aux éléments déclaratifs personnalisés.

@rniwa @justinfagnani Oui, en effet. Il s'agit (aussi) de pouvoir utiliser des modules HTML avec Javascript désactivé. Je vais modifier la description pour que cela soit plus clair. Merci de l'avoir signalé !

J'aimerais souligner que même sans aucune fonctionnalité Javascript, les importations HTML avec des modèles à fente peuvent apporter de nombreux avantages. Bien qu'il n'y ait actuellement aucun moyen d'enregistrer des modèles sans Javascript, j'espère que c'est quelque chose qui sera résolu dès que les modules seront terminés.

Pourquoi pas :
<template src="my-include.html" in-place>

C'est-à-dire pouvoir charger un modèle par une source externe en ajoutant un attribut src , le contenu prend place dans l'élément <template> tel qu'il y a été écrit.
Et ajoutez la possibilité de rendre le contenu de la balise du modèle comme un élément normal avec un attribut in-place (ou quel que soit le nom, cela peut également être disabled pour indiquer de désactiver le comportement normal de l'élément du modèle) .
Il offre également la possibilité de charger des modèles sans attribut in-place pour aucun rendu, et de l'utiliser toujours avec JS.

Une autre syntaxe plus exotique peut être :
<div src="my-part.html">placeholder</div> >>> Permettre à chaque élément de charger son contenu
<content src="my-part.html">placeholder</content > >>> L'élément de contenu d'un document racine

Une autre réflexion :
Peut-être que même la compréhension du contenu du modèle peut faire partie du travail du navigateur. Il existe déjà une bonne API pour la chaîne de modèle dans JS, le même analyseur peut être utilisé et transformer le contenu avec des valeurs d'attributs de données :

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

Déléguer la substitution simple au navigateur-land, sans avoir besoin de JS pour le remplacement simple d'une chaîne ou d'un élément, permet d'utiliser des modèles avec l'option sans script.

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

Ensuite, les auteurs JS peuvent toujours obtenir la source du modèle et l'utiliser comme d'habitude...

Et enfin, la possibilité d'utiliser un autre template avec un attribut use comme celui en 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>

Aussi avec un élément <slot> au document racine :

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

... mais je préfère toujours la méthode <content select=""> !
L'augmentation de l'élément content avec un attribut src rend plus polyvalent (même dans les racines d'ombre) :

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

Mais la priorité doit être résolue lorsqu'elle est donnée avec un contenu lightDOM et un attribut select

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

(Je suis sûr que l'implémentation d'un élément de contenu peut être utilisée en dehors d'un élément ShadowRoot...)

De cette façon dissocie la sémantique "d'importation" de la sémantique "calculée" d'une balise <template> , ajoutant enfin la "chargeabilité" aux éléments <template> qui pourraient auto-calculer des substitutions simples couvre plus d'utilisation que l'ajout de " loadability" aux éléments <slot> ...

Même si une page est exécutée en mode noscript , j'aimerais, en tant que développeur, avoir la possibilité d'extraire les modules de manière déclarative. C'est l'une des choses les plus puissantes du HTML et du DOM : ce contenu est déclaré sur la page. J'ai l'impression de bien faire mes utilisateurs en incluant un module dans le DOM.

Par conséquent, je ne pense pas que cette déclaration devrait avoir un impact sur ce qui se passe avec ce problème :

Il me semble que cela fait allusion à une demande d'éléments personnalisés déclaratifs qui pourraient être déclarés et importés même avec JS désactivé.

Il s'agit d'une question distincte. Mon intérêt dans ce problème est de pouvoir déclarer quels modules j'ai essayé d'utiliser.