HTML5 ist tot. Es lebe HTML!

HTML5 existiert als Versionsnummer offiziell nicht mehr. Stattdessen pflegt die WHATWG seit 2019 allein den HTML Living Standard, dessen jüngste Fassung vom 4. Oktober 2026 stammt. Für Ihre Website, Ihre Agentur und Ihre Ausschreibungen hat diese stille Umstellung handfeste Folgen.

Der Begriff HTML5 hat ein Imageproblem. Offiziell existiert die Versionsnummer nicht mehr, trotzdem geistert der Begriff durch jede Ausschreibung, jedes Briefing und jedes Lehrbuch. Wer heute eine Website beauftragt, sollte wissen, was hinter dem Schlagwort tatsächlich passiert ist und welche Folgen sich daraus ergeben.

Was ist eigentlich aus HTML5 geworden?

Die kurze Antwort: HTML5 wurde abgeschafft, allerdings nur als Versionsbezeichnung und nicht inhaltlich.

Am 28. Mai 2019 unterzeichneten W3C und WHATWG ein Memorandum of Understanding, seither gibt die WHATWG die HTML- und DOM-Standards allein heraus. Die getrennten Fassungen beider Gremien entfielen. Das W3C übernimmt seitdem geprüfte Arbeitsstände der WHATWG, statt eigene Versionen zu veröffentlichen.

Den Namen Living Standard führt die Spezifikation bereits seit 2011. Die Bezeichnung ist Programm: Das Regelwerk kennt kein Versionsende und wächst schrittweise weiter. Die jüngste Aktualisierung vor dieser Überarbeitung stammt vom 4. Oktober 2026, ein Aufruf eine Woche später zeigt womöglich schon eine neuere Fassung.

Auf die Frage „Is this HTML5?“ antwortet die WHATWG in ihrer offiziellen FAQ zunächst knapp mit „in short: yes“. Die Langfassung liefert den entscheidenden Hinweis: HTML5 sei ein Buzzword, das auf moderne Webtechnologien verweise, ohne ein bestimmtes Versionsdatum zu meinen.

Stellen Sie sich HTML5 als Etikett auf einem Ordner vor, dessen Inhalt seit Jahren laufend ausgetauscht wird. Die Unterlagen darin sind aktuell, nur die Beschriftung stammt noch aus der Zeit vor 2019. Im Markt verhält sich die Bezeichnung genauso: Die Sprache verharrt, während die Technik unter dem alten Namen weiterzieht.

Der Übergang verlief unspektakulär. Browserhersteller entwickeln ihre Funktionen ohnehin gegen den aktuellen Stand der Spezifikation und nicht gegen einen eingefrorenen Snapshot. Als Referenz dient der Living Standard, keine HTML-5.2- oder HTML-5.3-Mumie. Ehrlicher als der alte Versionsreigen ist die Living-Standard-Logik allemal, denn feste Versionsnummern bildeten den Entwicklungsstand der Browser nie genau ab.

Vom Versionsnamen zum Living Standard

Die wichtigsten Wegmarken der HTML-Spezifikation im Überblick.

2004

WHATWG gegründet

Apple, Mozilla und Opera gründeten die Arbeitsgruppe als Reaktion auf die stockende HTML-Entwicklung beim W3C.

2011

Living Standard

Seit diesem Jahr führt die WHATWG ihre HTML-Spezifikation ohne Versionsnummer.

2019

Einigung mit dem W3C

Am 28. Mai unterzeichneten W3C und WHATWG ein Memorandum of Understanding. Seither gibt die WHATWG HTML und DOM allein heraus.

Okt. 2026

jüngste Aktualisierung

Am 4. Oktober 2026 erschien die bislang neueste Fassung, ganz ohne Versionsnummer.

Quelle: WHATWG (HTML Living Standard, FAQ); W3C (Memorandum of Understanding, 2019)

© 2026 Dr. Web | Das Fachportal für Entscheider | Infografik von Dr. Web

Warum spricht trotzdem die halbe Branche von HTML5?

Begriffe sterben langsamer als Standards. Der Name HTML5 überlebt aus drei Gründen, und keiner davon ist technisch: Werkzeuge, Ausschreibungen und Lehrmaterial halten ihn am Leben.

Erstens hält das Tooling den Namen fest. HTML5 Validator, HTML5 Boilerplate, HTML5 Doctor und HTML5 UP führen die Versionsnummer im Namen. Niemand benennt Software um, nur weil ein Standardgremium die Zählung abschafft. Die Werkzeuge bleiben im Einsatz und mit ihnen der Begriff.

Zweitens wirkt die Ausschreibungs-Sprache. Im Pflichtenheft signalisiert „HTML5“ einen aktuellen Standard, während „Living Standard“ Rückfragen auslöst. Sprachlich gewinnt das Vertraute, auch wenn der Begriff technisch unschärfer ist. In IT-Ausschreibungen hält sich die alte Versionsbezeichnung deshalb hartnäckig.

Drittens prägt das Lehrmaterial die Wahrnehmung. Schulbücher, Universitätsskripte, VHS-Kurse und Online-Tutorials wirken über Jahre nach, und eine solche Bibliothek lässt sich nicht über Nacht erneuern. Der Begriff bleibt im Curriculum, solange das Curriculum bleibt.

Welche semantischen Elemente sind heute Pflicht?

Zum Pflichtumfang gehören sieben Strukturelemente von <header> bis <footer>, ergänzt um <figure>, <figcaption> und <time>.

Die eigentliche Neuerung hinter dem Begriff HTML5 lag nie bei <canvas> oder <video>, sondern in der semantischen Gliederung. Sieben Elemente haben das Web aufgeräumt und das Zeitalter von <div id="content"> beendet:

Hinzu kommen <figure> und <figcaption> für Abbildungen mit Beschriftung sowie <time datetime="..."> für maschinenlesbare Datumsangaben. Mit diesen sieben plus drei Elementen kommt ein modernes Seitenlayout im Kern aus.

Seit dem 28. Juni 2025 verschärft das Barrierefreiheitsstärkungsgesetz die Lage für viele Online-Angebote, vor allem für Shops und andere Dienstleistungen im elektronischen Geschäftsverkehr. Als technischen Maßstab nennt die Bundesfachstelle Barrierefreiheit die europäische Norm EN 301 549, die auf den Web Content Accessibility Guidelines (WCAG) 2.1 aufbaut; die neuere Fassung 2.2 liegt seit 2023 vor. Screenreader unterscheiden <nav> von <main>, eine Tapete aus div-Elementen dagegen nicht.

Fehlen auf einer solchen Website <nav>, <main> und <article>, steht nicht mehr nur ein Stilfehler im Raum, sondern ein möglicher Verstoß gegen das Gesetz. Das BFSG sieht dafür Bußgelder von bis zu 100.000 Euro vor. Eine ausführliche Anleitung zur barrierefreien Umsetzung bietet unser Leitfaden zu validem, barrierefreiem Webdesign.

Konkret heißt das: Jede <article>-Box braucht eine Überschrift. Layout-Tabellen sind tabu, Tabellen bleiben tabellarischen Daten vorbehalten. Inline-Styles haben in keinem modernen Projekt etwas verloren. Diese drei Maßgaben decken die häufigsten Fehlerquellen ab.

Was hat HTML5 in Formularen wirklich verändert?

Seit HTML5 prüfen Browser Pflichtfelder, E-Mail-Adressen und Datumswerte selbst, wofür früher JavaScript nötig war.

Formulare waren vor 2014 ein Trauerspiel. Jede E-Mail-Prüfung musste in JavaScript gegossen werden, jedes Datumsfeld brauchte ein jQuery-UI-Plug-in, und jeder Pflichtfeld-Hinweis hing an einer Prüfung auf dem Server. Mit HTML5 verschwand ein Großteil dieses Aufwands.

Heute reicht für die meisten Standardfälle das type-Attribut:

Drei Attribute erledigen seither direkt im Browser, wofür früher Zusatzcode nötig war: required macht ein Feld zur Pflicht, pattern erlaubt reguläre Ausdrücke direkt im Markup, und autocomplete teilt dem Browser mit, welche Werte er vorschlagen soll. Die native Validierung spart Code und verringert die Abhängigkeit von JavaScript. Die Prüfung auf dem Server bleibt trotzdem Pflicht, weil sich jede Browserprüfung umgehen lässt; für schnelle Rückmeldungen an die Nutzer reicht die native Variante aber aus.

Unterschätzt wird ein viertes Attribut: inputmode. Damit schaltet die mobile Bildschirmtastatur passend zum Kontext um, ohne dass sich der type ändert. Für eine Hausnummer, die als Zeichenkette gespeichert wird, ergibt das Sinn: Die Tastatur springt auf Ziffern, der Wert bleibt ein String.

Welche Multimedia-Elemente sind heute etabliert?

Etabliert sind <video>, <audio> und <picture> mit srcset; Plug-ins wie Flash braucht kein Browser mehr.

Vor HTML5 verlangte ein Video im Browser nach dem Adobe Flash Player, ein Audio-Schnipsel nach QuickTime oder Windows Media. Sicherheitslücken und Inkompatibilitäten der Plug-ins gehörten zum Alltag. Mit den nativen Medienelementen endete diese Ära.

Drei Elemente bestimmen heute die Medienwiedergabe im Web:

<video src="film.mp4" controls> reicht für Standardvideos. Das Attribut poster setzt ein Vorschaubild, preload="metadata" verringert die anfangs geladene Datenmenge, und mehrere <source>-Kinder liefern alternative Codecs.

<audio src="podcast.mp3" controls> funktioniert nach demselben Schema. Streaming- und Musikanwendungen ergänzen das Element um die Web Audio API, mit der sich Klänge per Skript erzeugen, filtern und mischen lassen. Für einen gewöhnlichen Podcast-Player genügt das schlichte <audio>-Tag.

<picture> regelt zusammen mit srcset die responsive Bildauslieferung. Der Browser wählt je nach Viewport und Pixeldichte die passende Auflösung, ganz ohne JavaScript. Für moderne Layouts gilt diese Technik als Pflicht, weil die Bildauslieferung auf dem Smartphone die Ladezeit maßgeblich bestimmt.

Bei Videos entscheidet oft eine technische Detailfrage über die Praxistauglichkeit: das Codec-Problem. MP4 mit H.264 spielen alle Browser ab, WebM mit VP9 oder AV1 setzt sich zunehmend durch, und Apple-Geräte haben mit manchen WebM-Varianten Probleme. Als Faustregel gilt deshalb: MP4 als Pflichtquelle, WebM als sparsamere Variante für moderne Browser.

Was ist neu seit dem Living-Standard-Modell?

Zu den wichtigsten Neuerungen zählen das <dialog>-Element, Web Components, das <search>-Element sowie die Attribute popover und inert.

Seit 2019 wächst der Standard laufend. Drei Neuerungen verdienen besondere Aufmerksamkeit, weil sie echte Probleme lösen.

Erstens hat sich das <dialog>-Element vom Wackelkandidaten zum stabilen Standard entwickelt. Seit 2022 unterstützen alle gängigen Browser das Element. Modale Dialoge laufen damit ohne JavaScript-Bibliothek, ohne ARIA-Bastelei und ohne Bootstrap-Modal-Plug-in: Die Methoden showModal() und close() öffnen und schließen die Box, das Pseudo-Element ::backdrop gestaltet den Hintergrund. Eine zusätzliche Bibliothek wie SweetAlert lädt für Standarddialoge nur Ballast nach.

Zweitens etablieren sich Web Components. Custom Elements und Shadow DOM erlauben browsereigene Komponenten ohne den Ballast eines Frameworks. Eine <my-product-card> mit gekapseltem Stil und eigener Logik funktioniert in React-, Vue- und reinen JavaScript-Projekten gleichermaßen. Die Kernfunktionen erreichen laut caniuse.com (Stand März 2026) rund 97 Prozent der Nutzer. Web Components bieten sich deshalb als schlanke Alternative zum Framework-Wildwuchs der 2010er-Jahre an.

Drittens kommen neue Attribute und Elemente hinzu: popover als globales Attribut für Tooltips und Menüs ohne JavaScript, <search> als semantischer Container für Suchformulare und inert, das ganze Bereiche für Tastaturfokus und Klicks sperrt. Im Detail entfalten diese kleinen Erweiterungen große Wirkung.

In der Redaktion haben wir mehrfach versucht, eine kompakte Übersicht aller Neuerungen seit 2019 zu schreiben. Jeder Versuch endete bei einer Liste mit über 80 Einträgen. Vollständig erfassen lässt sich der Wandel nicht, eingrenzen schon: Nutzen Sie caniuse.com als laufende Referenz statt eines Fachbuchs von 2018.

Was der Living Standard seit 2019 dazugelernt hat

Vier Befunde zu Neuerungen, die Bibliotheken und Plug-ins überflüssig machen.

2022

dialog-Element stabil

Seit diesem Jahr unterstützen alle gängigen Browser modale Dialoge ohne Zusatzbibliothek.

97 %

Reichweite von Web Components

Custom Elements und Shadow DOM erreichen laut caniuse.com rund 97 Prozent der Nutzer, Stand März 2026.

0

Zeilen Skript für ein Popover

Das globale Attribut popover öffnet Tooltips und Menüs ohne eigenes JavaScript.

80+

Neuerungen seit 2019

So lang wurde jede redaktionelle Liste aller Änderungen am Living Standard.

Quelle: WHATWG HTML Living Standard; caniuse.com (Stand März 2026); Dr.-Web-Redaktion

© 2026 Dr. Web | Das Fachportal für Entscheider | Infografik von Dr. Web

Was bedeutet HTML5 für Entscheider heute?

Vier Aufgaben ergeben sich für die Geschäftsführung, ohne dass Sie eine Zeile Code lesen müssen: Vertragssprache präzisieren, Browser-Support realistisch festlegen, das BFSG ernst nehmen und Vorlagen vor dem Einsatz prüfen.

Erstens, Vertragssprache präzisieren. Die Formulierung „HTML5-konform“ ist wertlos, weil HTML5 als technischer Versionsbegriff nicht mehr existiert. Besser passt: „aktueller HTML Living Standard, valide gegen den W3C-Validator, semantisch ausgezeichnet, WCAG-2.2-konform“. Diese Maßgaben gehören in jedes Pflichtenheft. Am verlässlichsten landen solche Formulierungen im Vertrag, wenn Auftraggeber und umsetzende Agentur das Pflichtenheft Punkt für Punkt gemeinsam durchgehen. Mit einem Team in erreichbarer Nähe fällt dieses Gespräch leichter; Kölner Unternehmen finden passende Dienstleister im Vergleich der Webdesign-Agenturen in Köln.

Zweitens, Browser-Support realistisch festlegen. Microsoft hat den Support für den Internet Explorer 11 im Juni 2022 eingestellt. Eine Zielplattform mit IE11 im Lastenheft kostet Budget für Polyfills, die niemand mehr braucht. Die realistische Zielmatrix umfasst Chrome, Edge, Firefox und Safari in der aktuellen und der vorherigen Version, mobil ergänzt um Chrome auf Android und Safari auf iOS. Weitere Browser verlangen nur in Ausnahmefällen eigene Tests.

Drittens, das BFSG ernst nehmen. Sauberes HTML nach den semantischen Vorgaben des Living Standards ist die technische Voraussetzung für Barrierefreiheit. Für Online-Shops und andere vom Gesetz erfasste Dienste stehen bei Verstößen Bußgelder von bis zu 100.000 Euro im Raum. Eine sorgfältige Auswahl der technischen Basis senkt dieses Risiko früh. Welche Rolle dabei das saubere Zusammenspiel von HTML und CSS spielt, beschreibt Dr. Web in einer eigenen Vertiefung.

Viertens, Templates und Themes prüfen. Ein WordPress-Theme aus dem Jahr 2018 erfüllt selten die heutigen semantischen Anforderungen. Vor jedem Relaunch lohnen deshalb ein Validator-Check, ein HTML-Audit und ein WAVE-Test auf Barrierefreiheit. Auch beim Einsatz fertiger HTML-Templates für Microsites gehört semantisches Markup auf die Prüfliste. Bei kommerziellen Vorlagen findet dieselbe Prüfung am besten vor dem Kauf statt, denn der Quelltext der Demo verrät, ob <nav>, <main> und <article> sauber gesetzt sind; welche Anbieter solche Vorlagen liefern, stellt der Vergleich der HTML-Templates gegenüber. Veraltete Vorlagen bringen technische Schulden mit, die später teuer werden.

Glossar: 14 wichtige Fachbegriffe rund um HTML5

ARIA

Accessible Rich Internet Applications (ARIA) bezeichnet einen Satz von Attributen, der die Barrierefreiheit dynamischer Inhalte verbessert. Wo semantisches HTML nicht ausreicht, ergänzt ARIA Rollen, Zustände und Eigenschaften, etwa role="alert" für eine Fehlermeldung. In komplexen Webanwendungen gehört ARIA zum Pflichtprogramm.

Browser-Support

Browser-Support beschreibt die Verfügbarkeit einer Funktion in den verschiedenen Webbrowsern. Als Standard-Referenz dient caniuse.com. Vor jedem Einsatz einer neuen Funktion lohnt der Blick auf die aktuelle Unterstützung, insbesondere bei Safari auf iOS.

Custom Elements

Custom Elements sind selbst definierte HTML-Elemente und gehören zum offiziellen Web-Components-Standard. Entwickler registrieren neue Tags wie <my-card> direkt im Browser. Der Ansatz vermeidet die Bindung an ein Framework, kapselt die Logik und funktioniert in jedem aktuellen Browser.

Datalist

Das datalist-Element liefert Vorschlagswerte für Eingabefelder. Verknüpft mit einem <input> über das list-Attribut, zeigt der Browser während der Eingabe eine Auswahlliste. Die Autovervollständigung funktioniert damit nativ, ohne JavaScript-Bibliothek.

DOCTYPE

DOCTYPE steht in der ersten Zeile jedes HTML-Dokuments. Seit HTML5 genügt die Kurzform <!DOCTYPE html>. Die Deklaration weist den Browser an, die Seite im Standards Mode darzustellen statt im Quirks Mode mit seinen alten Darstellungsfehlern.

Living Standard

Der HTML Living Standard ist die offizielle, versionslose Spezifikation der WHATWG und ersetzt seit 2019 alle versionierten HTML-Standards. Kennzeichnend sind laufende Aktualisierungen ohne festes Versionsende. Die offizielle Adresse lautet html.spec.whatwg.org.

Pattern-Attribut

Das pattern-Attribut erlaubt reguläre Ausdrücke direkt im HTML-Markup. Browser prüfen die Eingabe gegen den Ausdruck, bevor das Formular abgeschickt wird. Ein Beispiel ist pattern="[0-9]{5}" für eine fünfstellige Postleitzahl.

Picture-Element

Das picture-Element liefert je nach Viewport oder Auflösung verschiedene Bildvarianten aus. Der Browser wählt aus mehreren <source>-Kindern die passendste Variante. Die Technik gilt als Pflicht für responsive Bildauslieferung und schnelle Ladezeiten.

Polyfill

Ein Polyfill bezeichnet JavaScript-Code, der eine moderne Funktion in älteren Browsern nachbildet. Heute spielen Polyfills nur noch in Altprojekten eine Rolle, aktuelle Browser kommen ohne solche Nachbauten aus.

Semantisches HTML

Semantisches HTML setzt Tags entsprechend ihrer Bedeutung ein: <nav> für die Navigation, <article> für eigenständige Inhalte, <header> für Kopfbereiche. Saubere Auszeichnung verbessert Barrierefreiheit, Auffindbarkeit und Wartbarkeit. Seit Inkrafttreten des BFSG gehört sie für viele kommerzielle Websites zur Pflicht.

Shadow DOM

Shadow DOM gehört zu den Web Components und stellt abgekapselte DOM-Bäume innerhalb eines Custom Elements bereit. Styles und Skripte bleiben isoliert, Konflikte mit dem Hauptdokument entfallen. Auf dieser Kapselung beruhen browsereigene Komponenten.

srcset

Das srcset-Attribut ergänzt <img>– und <source>-Tags um Auflösungsvarianten. Der Browser wählt automatisch das passende Bild für Pixeldichte und Viewport-Größe. Auf Mobilgeräten sinkt die übertragene Datenmenge dadurch deutlich.

Validator

Ein HTML-Validator prüft Markup auf Konformität mit dem Living Standard. Der offizielle Validator steht unter validator.w3.org bereit. Bei Code-Reviews und vor jeder Veröffentlichung gehört das Werkzeug zur Grundausstattung, denn der Validator erkennt fehlerhaftes Markup, das Browser zwar tolerant darstellen, das aber später Probleme verursachen kann.

WHATWG

Die Web Hypertext Application Technology Working Group (WHATWG) gibt seit 2019 die HTML- und DOM-Standards allein heraus. Apple, Mozilla und Opera gründeten die Gruppe 2004 als Reaktion auf die stockende HTML-Entwicklung beim W3C.

FAQ: Häufige Fragen zu HTML5 und dem Living Standard

Quellen

Artikelhistorie

Dieser Artikel entstand aus einer vollständigen Überarbeitung eines HTML5-Überblicks, der erstmals im November 2009 erschienen war. Über die Jahre kamen Abschnitte hinzu, ohne dass eine redaktionelle Gesamtüberarbeitung stattfand, und so wuchs ein Flickenteppich aus Texten verschiedener Jahrgänge.

Im Mai 2026 hat die Redaktion den Artikel vollständig neu geschrieben und den Begriff „HTML5“ durch die korrekte Bezeichnung „HTML Living Standard“ ersetzt. Im Oktober 2026 folgte eine weitere Prüfung: Die Angaben zu BFSG und WCAG sind präzisiert, zwei Infografiken und ein FAQ-Bereich ergänzt.