HTML-first entwickeln: Baseline und Progressive Enhancement.

Webentwicklung wird häufig über Produktnamen besprochen. Ein Projekt soll mit einem bestimmten CMS, Framework oder visuellen Editor entstehen, bevor geklärt ist, was die Seite leisten muss. Damit wird eine Lösung zum Ausgangspunkt. Für eine Unternehmenswebsite ist die umgekehrte Reihenfolge belastbarer: Erst werden Nutzerfragen, Inhalte, Wege und Pflegebedarf geordnet. Danach lässt sich entscheiden, welche technische Schicht tatsächlich hilft.

HTML beschreibt die Bedeutung und Struktur eines Dokuments. Eine Überschrift ist als Überschrift ausgezeichnet, ein Link verweist auf ein erreichbares Ziel und ein Formular übermittelt Daten über einen vorgesehenen Weg. CSS gestaltet diese Struktur. JavaScript kann Zustände, unmittelbare Rückmeldungen und komplexere Interaktion ergänzen. Diese Trennung ist nicht bloß Lehrbuchordnung. Sie bestimmt, was übrig bleibt, wenn eine Ressource langsam lädt, ein Skript fehlschlägt oder ein Browser eine neue Funktion noch nicht versteht.

HTML-first bedeutet deshalb nicht, dass eine Seite schlicht aussehen oder ohne JavaScript auskommen muss. Es bezeichnet eine Priorität: Der fachliche Kern wird in passender Dokumentstruktur ausgeliefert. Gestaltung und Bewegung dürfen anspruchsvoll sein. Interaktion darf JavaScript benötigen, wenn die Aufgabe es verlangt. Die Seite sollte nur nicht aus Gewohnheit ihren gesamten Inhalt hinter einer unnötigen Laufzeit verbergen.

Für Suchsysteme und assistive Technik ist diese Struktur ebenfalls wichtig. Überschriften, Landmarks, Listen, Tabellen und beschreibende Links vermitteln Beziehungen, die eine gezeichnete Oberfläche allein nicht erklärt. Der vorhandene Artikel Warum ein Entwurf noch keine fertige Website ist zeigt, warum Gestaltung, Inhalt, Code, Prüfung und Betrieb zusammengehören.

Die Webplattform entwickelt sich nicht in einem einzigen Browser. Funktionen müssen in Safari, Chrome, Edge und Firefox sowie ihren mobilen Varianten ausreichend übereinstimmen. Baseline fasst diesen Stand in drei verständliche Gruppen. Die Daten werden im Web-features-Projekt gepflegt und von der WebDX Community Group koordiniert.

Die Kernmenge umfasst Safari auf macOS und iOS, Chrome auf Desktop und Android, Edge auf Desktop sowie Firefox auf Desktop und Android. Andere Browser können dieselben Engines verwenden, sind aber nicht automatisch Teil jeder Baseline-Aussage. Eingebettete Webviews, alte Betriebssysteme oder unternehmenseigene Geräteflotten benötigen möglicherweise eine gesonderte Betrachtung.

Ein Projekt kann „Widely available“ als allgemeine Untergrenze festlegen und einzelne neuere Funktionen mit Fallback einsetzen. Ein anderes richtet sich bewusst an aktuelle Geräte. Beide Entscheidungen können richtig sein, wenn sie dokumentiert sind. Baseline liefert den gemeinsamen Ausgangspunkt; Nutzungsdaten, Zielgruppe und wirtschaftliche Bedeutung einer Funktion liefern den Projektkontext.

Auch Werkzeuge können Baseline-Ziele übernehmen. Browserslist unterstützt entsprechende Abfragen, wodurch Buildwerkzeuge ein definiertes Featurejahr oder „widely available“ berücksichtigen können. Eine direkte HTML- und CSS-Seite braucht dafür nicht zwingend einen Buildprozess. Der Status lässt sich ebenso in Referenzdokumentation prüfen und in einer manuellen Kompatibilitätsentscheidung festhalten.

Apple, Google, Igalia, Microsoft und Mozilla arbeiten im Interop-Projekt an browserübergreifender Übereinstimmung. Für 2026 gehören unter anderem Dialoge und Popover, Container Style Queries, scrollgesteuerte Animationen, View Transitions und verschiedene Kompatibilitätsprobleme zu den Fokusbereichen. Automatisierte Web Platform Tests machen Fortschritt vergleichbar.

Diese Entwicklung ist für Unternehmenswebsites relevant, weil native Funktionen Aufgaben übernehmen können, für die früher zusätzliche Bibliotheken oder umfangreiche Sonderlösungen nötig waren. Ein echtes dialog-Element bringt bereits definierte Semantik und Fokusverhalten mit. Container-Abfragen können Komponenten nach ihrem verfügbaren Raum gestalten. CSS-basierte Bewegung kann JavaScriptarbeit reduzieren. Daraus folgt aber nicht, dass jede neue Funktion sofort ungeprüft eingesetzt werden sollte.

Ein Interop-Fokus ist ein Arbeitsprogramm, kein pauschales Freigabesiegel. Einige Funktionen sind bereits in mehreren Browsern verfügbar, andere weisen noch Unterschiede auf. Auch „Newly available“ bedeutet ausdrücklich, dass ältere Geräte fehlen können. Die richtige Umsetzung prüft den konkreten Baseline-Status zum Veröffentlichungszeitpunkt und entscheidet, ob ein Fallback nötig ist.

Trends werden dadurch zu Werkzeugen statt zu Dekoration. Eine View Transition ist sinnvoll, wenn sie Orientierung verbessert und reduzierte Bewegung respektiert. Ein Popover ist sinnvoll, wenn sein Inhalt, seine Bedienung und sein Schließverhalten verständlich sind. Neue CSS-Funktionen rechtfertigen sich nicht durch Neuheit, sondern durch ein besseres, leichter wartbares Ergebnis.

Semantisches HTML garantiert noch keine nutzbare Seite. Tests müssen die vereinbarten Browser und Viewports tatsächlich öffnen. Links, Formulare, Menü, Fokusreihenfolge, Statusmeldungen und Medien werden bedient. Bei Animationen kommt die Einstellung für reduzierte Bewegung hinzu. Die Seite wird mit langsamem Netz und blockierten Ressourcen betrachtet, damit versteckte Abhängigkeiten sichtbar werden.

Automatisierte Prüfungen können Statuscodes, fehlende Ziele, HTML-Struktur und bestimmte Accessibility-Muster zuverlässig wiederholen. Visuelle Kontrolle bleibt nötig, weil ein korrektes Element trotzdem abgeschnitten, überlagert oder unlesbar sein kann. Ein Browser-Smoke findet andere Fehler als ein statischer Audit. Beide ergänzen das redaktionelle Gegenlesen.

Performance gehört ebenfalls dazu. HTML-first kann frühe Inhalte begünstigen, ist aber keine Garantie für gute Core Web Vitals. Große Bilder, blockierendes CSS oder teure eigene Skripte bleiben mögliche Engpässe. Der Artikel Core Web Vitals verstehen erklärt, warum Feld- und Labordaten getrennt gelesen werden.

Schließlich muss der Betrieb den gewählten Ansatz tragen. Ein statisches Dokument braucht weiterhin Hosting, sichere Übertragung, Backups und einen Veröffentlichungsweg. Ein CMS benötigt zusätzlich gepflegte Laufzeitkomponenten und Rollen. Die technisch einfachere Lösung ist diejenige, deren vollständiger Lebenszyklus zur Organisation passt, nicht zwingend diejenige mit der kürzesten Dateiliste.

Bedeutet HTML-first, dass eine Website ohne JavaScript auskommen muss?

Nein. JavaScript kann Navigation, Formulare, Bewegung und anspruchsvolle Funktionen verbessern oder bei Webanwendungen notwendig sein. HTML-first bedeutet, dass Inhalt und Dokumentbedeutung nicht ohne Grund vollständig in die Skriptlaufzeit verlagert werden. Die angemessene Grundfunktion richtet sich nach der konkreten Aufgabe.

Ist eine Baseline-Funktion automatisch für jedes Projekt geeignet?

Nein. „Newly available“ bezieht sich auf aktuelle Kernbrowser und kann ältere Geräte ausschließen. „Widely available“ bietet eine breitere Grundlage, ersetzt aber keine Zielgruppenanalyse. Zusätzlich zählen Accessibility, Fehlerverhalten und der Nutzen der Funktion.

Ist Vanilla JavaScript immer schneller als ein Framework?

Nein. Eigenentwickelter Code kann ineffizient oder umfangreich sein, während ein gut gewähltes Werkzeug komplexe Aufgaben sauber löst. Verglichen werden tatsächliche Übertragungsmenge, Ausführung, Entwicklungsaufwand, Wartung und Funktion. Der Produktname allein liefert kein Ergebnis.

Wann ist ein CMS sinnvoll?

Ein CMS kann sinnvoll sein, wenn Inhalte regelmäßig von mehreren Personen gepflegt werden, Rollen gebraucht werden oder strukturierte Inhaltstypen den Betrieb erleichtern. Für selten geänderte Seiten kann eine direkte Umsetzung übersichtlicher sein. Entscheidung und Übergabe müssen zum Arbeitsablauf des Unternehmens passen.