Pourquoi HTML ne prend-il pas en charge une fonctionnalité d’`include` à lui seul ?

• En HTML seul, il n’existe pas de fonctionnalité d’include permettant d’inclure le même élément sur plusieurs pages
• Le CSS peut charger du CSS, JavaScript peut charger du JS, mais HTML ne peut pas importer du HTML, ce qui soulève des questions
• Pour résoudre ce problème, on utilise divers JavaScript, langages de template et générateurs de sites statiques
• Les problèmes complexes de performance, sécurité, délai de rendu et inclusions circulaires constituent des freins à son adoption
• De nombreux développeurs souhaitent une fonctionnalité d’include déclarative pure en HTML, mais elle n’a toujours pas été intégrée aux standards du Web

---

Pourquoi il n’existe pas de fonctionnalité Include en HTML ?

Le problème

• Il est contraignant de répéter un en-tête commun dans plusieurs pages comme index.html, about.html, contact.html, etc.
• Les développeurs veulent réutiliser un en-tête défini une seule fois sans duplication

Les solutions de contournement déjà existantes

• Utiliser la fetch API de JavaScript pour charger du HTML externe puis l’insérer dans le DOM
• Les Server Side Includes (SSI), include en PHP, les générateurs de sites statiques et les langages de template constituent déjà des solutions
• Des éléments HTML comme <iframe> et <object> sont aussi possibles, mais restent inadaptés à cause de problèmes d’accessibilité, de performance et d’isolation des styles
• Au final, HTML lui-même ne dispose pas d’une syntaxe d’include simple

Pourquoi cette fonctionnalité n’existe-t-elle pas en HTML ?

• Le CSS et le JS disposent respectivement de syntaxes comme @import ou import, mais ce n’est pas le cas du HTML
• Les standards du Web ont généralement intégré les fonctionnalités largement utilisées par les développeurs, mais l’include HTML n’a pas suivi ce chemin
• Raisons avancées dans la discussion :
  • risque de perturber le fonctionnement du preload scanner
  • problèmes de décalage de mise en page / scintillement lors d’un chargement asynchrone
  • complexité du traitement des includes imbriqués ou circulaires
  • réticence liée à l’augmentation du trafic côté hébergement Web
  • enjeux de sécurité (CORS, CSP, etc.) et conflits de timing avec les événements de chargement du document
  • ou simplement une priorité faible et l’absence de proposition claire

Discussions liées

• Le sujet est activement débattu dans le fil d’issue WHATWG sur GitHub #2791
• Dans le passé, Chrome a un temps proposé HTML Imports, mais la fonctionnalité a été abandonnée en raison de l’absence de prise en charge par les autres navigateurs
• Des approches alternatives comme HTMX, Web Components, XSLT ou SSI sont également partagées

Résumé des réactions de la communauté

• L’évolution de HTML est restée centrée sur le balisage statique, avec une philosophie qui écarte encore les fonctionnalités logiques
• Beaucoup de gens souhaitent cette fonctionnalité, mais la plupart des développeurs individuels ont du mal à se faire entendre dans le processus de standardisation
• Certains estiment aussi que son adoption restera difficile tant que ne seront pas résolus les problèmes complexes de performance, sécurité, rendu et prévention des boucles circulaires
• Pour certains développeurs, cette absence s’explique simplement par l’idée que HTML ne devrait s’occuper que du “résultat”

Conclusion

• À ce jour, HTML ne dispose toujours pas d’une fonctionnalité d’include pure, et il faut la remplacer par divers outils et langages externes
• Mais de nombreux développeurs continuent d’espérer une structure de réutilisation simple fondée sur HTML

[GN⁺]

Avis Hacker News

• Historiquement, HTML était une application de SGML, et SGML prenait en charge les mécanismes d’inclusion. On pouvait définir une nouvelle « entité » et créer une entité « système » pour ensuite la référencer et la substituer
  • Divers efforts ont ensuite cherché à simplifier HTML à cause de la complexité de SGML, et cette fonctionnalité a été supprimée au passage
• Des tentatives ont été faites à la fin des années 1990 pour résoudre ce problème. En tant que webmaster du site web d’Analog Science Fiction, je créais de nombreuses pages statiques avec le même en-tête et la même barre latérale. C’est ainsi que j’ai découvert les inclusions côté serveur d’Apache. C’était ma manière de maintenir cela avant même de connaître le principe DRY
  • Ce problème a été résolu encore et encore de multiples façons. À ceux qui disent qu’un iframe suffit, le problème est qu’un iframe ne s’adapte pas automatiquement au contenu. Les solutions côté serveur nécessitent un serveur. Pourquoi n’existe-t-il pas une méthode simple côté client ? Je pense que c’est une question légitime
• Une proposition de fonctionnalité appelée HTML Imports a existé. Elle a été conçue dans le cadre des Web Components
  • HTML Imports est une manière d’inclure et de réutiliser un document HTML dans un autre document HTML
  • Google a implémenté la spécification proposée dans Blink, mais d’autres entreprises s’y sont opposées pour diverses raisons. Mozilla s’inquiétait de la complexité de l’implémentation, des questions de sécurité et du chevauchement avec les modules ES6. Faute de soutien des fournisseurs, la proposition a été officiellement abandonnée
• Netscape 4 disposait d’une fonctionnalité appelée inflow layers
  • Le nom de cette fonctionnalité est transclusion. Elle faisait partie de Project Xanadu et était à l’origine considérée comme une fonction importante de l’hypertexte
  • MediaWiki utilise largement la transclusion. Par moments, un wiki donne l’impression d’être la véritable forme de l’hypertexte
• Un frameset approprié, et non un iframe, était censé remplir ce rôle il y a longtemps. Au minimum, le redimensionnement automatique fonctionnait bien et l’utilisateur pouvait ajuster la taille
  • Les frames ont fait l’objet de nombreuses critiques, mais elles ont été déployées avec succès pour des choses utiles comme la documentation de l’API Java
  • Je pense que les framesets n’ont pas survécu parce qu’ils n’offraient pas assez de flexibilité aux designers. Sur mobile aujourd’hui, ils ne fonctionneraient probablement pas bien
• La fonctionnalité « Includes » est considérée comme relevant du côté serveur et est traitée en dehors du navigateur web. HTML est côté client et n’est qu’une syntaxe de balisage simple, pas un langage de programmation
  • Ce problème est déjà résolu. La question des « Includes » est la façon dont tous les étudiants en web design apprennent PHP. Dans la plupart des CMS, les « Includes » deviennent des « parties de template », et c’est l’une des premières choses expliquées dans la documentation
  • Il n’est pas nécessaire d’utiliser des « Includes » avec HTML seul. HTML est un format de présentation et ne fait rien de très intéressant sans CSS ni JS
• L’inclusion HTML pose plusieurs problèmes
  • Si main.html inclut child/include1.html et que child/include1.html contient un lien src="include2.html", où l’utilisateur doit-il aller quand il clique sur ce lien ? S’il va vers include2.html, il lui manquera tout le reste de la page. S’il va vers main.html, comment indiquer que cette fois il faut utiliser include2.html et non include1.html ?
  • À l’inverse, article1.html, article2.html, article3.html, etc. peuvent chacun inclure header.html, footer.html et navi.html. Mais si l’on veut ajouter comments.html à tous les articles, il faut modifier tous les articles ; on finit donc par générer les articles à partir d’un template, ce qui rend inutile un support des inclusions par le navigateur
  • Si l’en-tête doit connaître le titre, ou si le pied de page veut des liens précédent/suivant, il faut un moyen de transmettre ces informations entre les inclusions ; on finit là aussi par générer la page, et les inclusions ne sont pas la solution
  • Les inclusions HTML seraient en pratique inutiles pour la plupart des cas d’usage
• Il existe une issue ouverte à ce sujet au WHATWG
  • Les inclusions côté client en HTML
• HTML avait bien une forme d’inclusion, mais elle a perdu en popularité
  • Le véritable terme « include » renvoie à une fonctionnalité XML, qui correspond à ce que recherche l’article. HTML avait une autre approche, antérieure à XML. Cette approche, c’étaient les frames. Les frames offraient davantage de fonctionnalités que les inclusions XML, et c’est pour cela que HTML n’a pas adopté cette fonctionnalité. Les frames ont ensuite perdu en popularité en raison de leur mauvais usage, de problèmes de sécurité, d’accessibilité et de divers autres problèmes