Warum unterstützt HTML nicht von Haus aus eine `include`-Funktion?

 (frontendmasters.com)
2 Punkte von GN⁺ 2025-05-05 | 1 Kommentare | Auf WhatsApp teilen
  • Mit reinem HTML gibt es keine include-Funktion, um dasselbe Element auf mehreren Seiten einzubinden
  • CSS kann CSS und JavaScript kann JS laden, aber HTML kann kein HTML importieren – genau das wirft Fragen auf
  • Zur Lösung dieses Problems werden verschiedene JavaScript-Ansätze, Template-Sprachen und statische Site-Generatoren verwendet
  • Performance, Sicherheit, Rendering-Verzögerungen und zirkuläre Includes gelten als Hürden für die Einführung
  • Viele Entwickler wünschen sich eine rein deklarative Include-Funktion in HTML, doch bisher hat sie es nicht in den Webstandard geschafft

Die Frage, warum HTML keine Include-Funktion hat

Problemstellung

  • Auf mehreren Seiten wie index.html, about.html und contact.html denselben gemeinsamen Header immer wieder einzufügen, ist umständlich
  • Entwickler möchten einen einmal definierten Header ohne Duplikate wiederverwenden

Bereits vorhandene Alternativen

  • Externes HTML per Fetch API von JavaScript laden und in das DOM einfügen
  • Server Side Includes (SSI), include in PHP, statische Site-Generatoren und Template-Sprachen sind vorhandene Lösungen
  • Auch HTML-Elemente wie <iframe> und <object> sind möglich, aber wegen Barrierefreiheit, Performance und Stil-Isolation ungeeignet
  • Letztlich gibt es in HTML selbst keine einfache Include-Syntax

Warum hat HTML diese Funktion nicht?

  • CSS und JS haben mit @import bzw. import jeweils eine entsprechende Syntax, HTML jedoch nicht
  • Webstandards haben Funktionen oft übernommen, wenn sie von Entwicklern stark nachgefragt wurden, bei HTML-Includes war das bislang nicht der Fall
  • Als mögliche Gründe werden genannt:
    • mögliche Beeinträchtigung des Preload-Scanners
    • Layout-Verschiebungen oder Flackern bei asynchronem Laden
    • Komplexität bei verschachtelten oder zirkulären Includes
    • Widerstand gegen erhöhten Traffic beim Webhosting
    • Sicherheitsprobleme (CORS, CSP usw.) sowie Kollisionen beim Timing von Dokument-Ladeereignissen
    • oder einfach, dass die Priorität niedrig war und ein klarer Vorschlag fehlte

Verwandte Diskussionen

  • Im WHATWG-Issue-Thread auf GitHub #2791 wird das Thema aktiv diskutiert
  • In Chrome gab es früher einmal HTML Imports, diese wurden jedoch wegen fehlender Unterstützung durch andere Browser wieder abgeschafft
  • Als alternative Ansätze werden HTMX, Web Components, XSLT und SSI genannt

Zusammenfassung der Reaktionen aus der Community

  • Weil sich HTML weiterhin stark auf statisches Markup konzentriert, ist die Philosophie, logische Funktionen auszuklammern, nach wie vor verbreitet
  • Viele wünschen sich diese Funktion, doch einzelne Entwickler haben es im Standardisierungsprozess schwer, Gehör zu finden
  • Analysen zufolge ist eine Einführung schwierig, solange komplexe Designfragen rund um Performance, Sicherheit, Rendering und die Vermeidung von Zyklen nicht gelöst sind
  • Manche Entwickler sehen den Grund auch einfach darin, dass HTML konzeptionell nur für das „Ergebnis“ zuständig sein soll

Fazit

  • HTML besitzt bis heute keine native Include-Funktion, sodass man auf verschiedene externe Tools und Sprachen ausweichen muss
  • Dennoch hoffen viele Entwickler weiterhin auf eine einfache, HTML-basierte Struktur zur Wiederverwendung

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2025-05-05
Hacker-News-Kommentare
  • HTML war historisch eine Anwendung von SGML, und SGML unterstützte Include-Funktionen. Man konnte neue „Entities“ definieren und „System“-Entities erzeugen, die später referenziert und ersetzt werden konnten
    • Wegen der Komplexität von SGML gab es verschiedene Bemühungen, HTML zu vereinfachen, und dabei wurden solche Funktionen entfernt
  • Ende der 90er gab es Versuche, dieses Problem zu lösen. Als Webmaster der Website von Analog Science Fiction erstellte ich viele statische Seiten mit demselben Header und derselben Sidebar. So entdeckte ich die Server-Side-Includes von Apache. Das war meine Art, das zu pflegen, noch bevor ich das DRY-Prinzip kannte
    • Dieses Problem wird immer wieder auf verschiedene Weise gelöst. Den Leuten, die sagen, ein iframe sei ausreichend, würde ich entgegnen, dass ein iframe nicht passend zum Inhalt mitwächst. Server-seitige Lösungen brauchen einen Server. Warum gibt es keine einfache Client-seitige Methode? Ich finde, das ist eine berechtigte Frage
  • Es gab einen Feature-Vorschlag namens HTML Imports. Er wurde als Teil von Web Components entwickelt
    • HTML Imports ist eine Methode, HTML-Dokumente in andere HTML-Dokumente einzubinden und wiederzuverwenden
    • Google implementierte die vorgeschlagene Spezifikation in Blink, aber andere Unternehmen lehnten sie aus verschiedenen Gründen ab. Mozilla hatte Bedenken wegen der Komplexität der Implementierung, wegen Sicherheitsproblemen und wegen Überschneidungen mit ES6-Modulen. Mangels Herstellerunterstützung wurde der Vorschlag offiziell eingestellt
  • Netscape 4 hatte eine Funktion namens inflow layers
    • Der Name für dieses Konzept ist Transklusion. Es war Teil von Project Xanadu und wurde ursprünglich als wichtige Funktion von Hypertext betrachtet
    • MediaWiki nutzt Transklusion sehr intensiv. Manchmal fühlt sich ein Wiki wie die wahre Form von Hypertext an
  • Ein ordentliches Frameset (nicht iframe) war schon vor langer Zeit dafür gedacht, solche Funktionen zu erfüllen. Zumindest automatische Größenanpassung funktionierte gut, und Benutzer konnten die Größe ändern
    • Es gab viel Kritik an Frames, aber sie wurden erfolgreich für nützliche Dinge wie die Java-API-Dokumentation eingesetzt
    • Ich denke, Framesets wurden nicht beibehalten, weil sie Designern nicht genug Flexibilität boten. Auf heutigen Mobilgeräten würden Framesets nicht gut funktionieren
  • Eine „Includes“-Funktion gilt als Server-seitig und wird außerhalb des Webbrowsers verarbeitet. HTML ist Client-seitig und nur eine einfache Markup-Syntax, keine Programmiersprache
    • Dieses Problem ist bereits gelöst. Das „Includes“-Problem ist etwas, bei dem alle Webdesign-Studierenden lernen, wie man PHP benutzt. In den meisten CMS werden „Includes“ zu „Template-Teilen“ und gehören zu den ersten Dingen, die in der Dokumentation erklärt werden
    • Es gibt keinen Bedarf, „Includes“ nur mit HTML zu nutzen. HTML ist ein Präsentationsformat und macht ohne CSS und JS nichts Interessantes
  • HTML-Includes haben verschiedene Probleme
    • Wenn main.html child/include1.html einbindet und child/include1.html einen Link src="include2.html" enthält, wohin soll der Nutzer beim Klick auf den Link gelangen? Wenn er zu „include2.html“ geht, fehlt dort alles andere. Wenn er zu main.html geht, wie soll dann angegeben werden, dass diesmal include2.html statt include1.html verwendet werden soll?
    • Umgekehrt könnten article1.html, article2.html, article3.html usw. jeweils header.html, footer.html und navi.html einbinden. Aber wenn man comments.html zu allen Artikeln hinzufügen will, muss man alle Artikel bearbeiten, und am Ende generiert man die Artikel auf Basis eines Templates, sodass der Browser Includes gar nicht unterstützen muss
    • Wenn der Header den Titel kennen soll oder der Footer Links zum vorherigen/nächsten Eintrag braucht, braucht man eine Möglichkeit, diese Informationen zwischen Includes weiterzugeben, und am Ende erzeugt man doch die Seite, sodass Includes nicht die Lösung sind
    • HTML-Includes wären für die meisten Anwendungsfälle praktisch nutzlos
  • Bei WHATWG gibt es ein offenes Issue zu diesem Thema
    • Client-seitige Includes für HTML
  • HTML hatte Include-Funktionen, verlor damit aber an Popularität
    • Der eigentliche Begriff „include“ stammt aus einer XML-Funktion und entspricht dem, was im Artikel gewünscht wird. HTML hatte vor XML einen alternativen Ansatz. Dieser Ansatz waren Frames. Frames boten mehr Funktionen als XML-Includes, deshalb bekam HTML diese Funktion nicht. Frames verloren wegen Missbrauch, Sicherheit, Barrierefreiheit und verschiedener anderer Probleme an Popularität