HTML und CSS können das jetzt selbst

Ein Entwickler hat sein gesamtes internes Tool mit HTML5 neu gebaut – ohne Frameworks, ohne UI-Libraries, mit minimalem JavaScript. Ausgangspunkt war ein aufgeblähtes Frontend mit über 40.000 Zeilen JavaScript, schwer wartbar, voller Bugs. Die Erkenntnis danach: Viele dieser Probleme waren selbst gemacht. Der Browser konnte das meiste schon.

Lange Zeit war die Antwort auf jede UI-Interaktion dieselbe: JavaScript. Ein Dropdown? JavaScript. Ein Modal? JavaScript. Ein Toggle? JavaScript. Libraries wie Alpine.js entstanden genau dafür – leichtgewichtig, deklarativ, direkt im HTML. Und sie haben ihre Aufgabe gut gelöst.

Aber die Plattform hat aufgeholt.

HTML und CSS haben in den letzten zwei Jahren Fähigkeiten bekommen, die viele dieser Anwendungsfälle nativ abdecken. Nicht als experimentelle Features hinter Flags, sondern als stabile, breit unterstützte Standards. Was Alpine mit x-show, x-on:click und x-data löst, geht heute oft mit <dialog>, popover und :has() – ohne JavaScript, ohne Dependency, ohne Bundle-Overhead.

Was jetzt nativ geht

Das `<dialog>`-Element

Modals ohne JavaScript – fast. Das <dialog>-Element bringt alles mit, was man braucht: Overlay, Fokus-Trap, Escape-zum-Schließen, Backdrop-Styling.

<button onclick="document.getElementById('modal').showModal()">
  Öffnen
</button>

<dialog id="modal">
  <h2>Bestätigung</h2>
  <p>Wirklich löschen?</p>
  <form method="dialog">
    <button value="cancel">Abbrechen</button>
    <button value="confirm">Löschen</button>
  </form>
</dialog>

dialog::backdrop {
  background: rgba(0, 0, 0, 0.5);
  backdrop-filter: blur(4px);
}

dialog {
  border: none;
  border-radius: 0.5rem;
  padding: 2rem;
  max-width: 28rem;
}

method="dialog" schließt den Dialog automatisch, der value des Buttons ist über dialog.returnValue auslesbar. Fokus-Management, Backdrop, Keyboard-Handling – alles eingebaut. Kein z-index-Krieg, kein manuelles Event-Handling.

In allen modernen Browsern seit 2022 stabil.

Das `popover`-Attribut

Popover ist das neueste Werkzeug – und vielleicht das wirkungsvollste. Es löst Tooltips, Dropdowns und Flyout-Menüs ohne eine Zeile JavaScript.

<button popovertarget="menu">Menü</button>

<div id="menu" popover>
  <nav>
    <a href="/profil">Profil</a>
    <a href="/einstellungen">Einstellungen</a>
    <a href="/logout">Abmelden</a>
  </nav>
</div>

[popover] {
  border: 1px solid #e2e8f0;
  border-radius: 0.5rem;
  padding: 0.5rem;
  box-shadow: 0 4px 12px rgba(0, 0, 0, 0.1);
}

[popover]:popover-open {
  display: block;
}

Was dabei automatisch passiert:

Light Dismiss: Klick außerhalb schließt das Popover
Top Layer: Kein z-index nötig, das Popover liegt immer oben
Keyboard: Escape schließt
Accessibility: ARIA-Attribute werden implizit gesetzt

Seit 2024 in allen modernen Browsern verfügbar.

`<details>` und `<summary>`

Accordions und Disclosure-Widgets – seit Jahren nativ, aber oft unterschätzt:

<details>
  <summary>Technische Details anzeigen</summary>
  <div class="content">
    <p>Hier steht der ausklappbare Inhalt.</p>
  </div>
</details>

details > .content {
  padding: 1rem;
  border-top: 1px solid #e2e8f0;
}

summary {
  cursor: pointer;
  padding: 0.75rem;
  font-weight: 600;
}

details[open] > .content {
  animation: slide-down 200ms ease-out;
}

@keyframes slide-down {
  from { opacity: 0; transform: translateY(-0.5rem); }
  to { opacity: 1; transform: translateY(0); }
}

Kein State-Management, kein Toggle-Handler. Das Element kennt seinen eigenen Zustand.

Native Formular-Validierung

Formulare validieren ohne JavaScript – das geht mit HTML-Attributen weiter, als die meisten nutzen:

<form>
  <input type="email" required placeholder="E-Mail">
  <input type="text" minlength="3" maxlength="50" required>
  <input type="number" min="1" max="100">
  <input type="url" placeholder="https://...">
  <button type="submit">Absenden</button>
</form>

input:invalid { border-color: #ef4444; }
input:valid { border-color: #22c55e; }
input:user-invalid { /* nur nach Nutzer-Interaktion */ }

required, min, max, minlength, maxlength, pattern, type="email" – der Browser übernimmt Validierung, Fehlermeldung und Feedback. Kein Event-Listener, kein Validation-Schema, keine Library. Und der Fallback bei deaktiviertem JavaScript: er funktioniert trotzdem.

Datum, Uhrzeit und Farbe nativ

Datepicker-Libraries gehören zu den am häufigsten eingebundenen Abhängigkeiten – dabei ist der native Input seit Jahren stabil:

<input type="date" min="2024-01-01" max="2026-12-31">
<input type="time" step="900"> <!-- 15-Minuten-Schritte -->
<input type="datetime-local">
<input type="color" value="#3b82f6">
<input type="range" min="0" max="100" step="5">

Mobile-optimiert, barrierefrei, kein Bundle-Overhead. Gerade type="color" und type="range" ersetzen regelmäßig externe Komponenten, ohne dass es auffällt.

Autocomplete – der Browser erledigt es

<input type="email" autocomplete="email">
<input type="tel" autocomplete="tel">
<input autocomplete="street-address">
<input autocomplete="postal-code">
<input autocomplete="cc-number"> <!-- Kreditkarte -->

Mit korrekt gesetztem autocomplete-Attribut füllt der Browser Formulare aus dem gespeicherten Profil des Nutzers. Keine Custom-Autocomplete-Library, kein State-Management, keine API. Und es funktioniert besser als jede eigene Implementierung, weil der Browser Daten hat, die die eigene App nie haben wird.

`<template>` für dynamische Inhalte

Dynamische UI ohne Framework – <template> macht es möglich:

<template id="card-template">
  <div class="card">
    <h3 class="card-title"></h3>
    <p class="card-body"></p>
  </div>
</template>

const template = document.getElementById('card-template');
const clone = template.content.cloneNode(true);
clone.querySelector('.card-title').textContent = 'Titel';
clone.querySelector('.card-body').textContent = 'Text';
document.querySelector('.grid').appendChild(clone);

Saubere DOM-Struktur statt String-Concatenation oder innerHTML-Hacks. <template>-Inhalte werden nicht gerendert, nicht ausgeführt – nur geklont wenn benötigt. Kein Framework, kein Virtual DOM.

Drag & Drop ohne Library

Für einfache Drag-and-Drop-Szenarien reichen native Events:

<div draggable="true" class="item">Element</div>
<div class="dropzone">Hier ablegen</div>

document.querySelectorAll('[draggable]').forEach(el => {
  el.addEventListener('dragstart', e => e.dataTransfer.setData('text/plain', el.id));
});

document.querySelector('.dropzone').addEventListener('drop', e => {
  e.preventDefault();
  const id = e.dataTransfer.getData('text/plain');
  e.currentTarget.appendChild(document.getElementById(id));
});

Für Listen-Sortierung mit komplexem Touch-Support bleibt eine Library sinnvoll. Für Standard-Drag-and-Drop – Dateien hochladen, Elemente verschieben, Kanban-Grundstruktur – reichen native Events.

`<progress>` und `<meter>`

<!-- Upload-Fortschritt -->
<progress value="65" max="100">65%</progress>

<!-- Auslastung / Wert in Bereich -->
<meter value="0.7" low="0.3" high="0.8" optimum="0.5">70%</meter>

Visuelles Feedback ohne Custom UI. <progress> zeigt unbestimmten Zustand ohne value. <meter> färbt sich automatisch (grün/gelb/rot) basierend auf low, high, optimum. Barrierefrei, semantisch korrekt, kein JavaScript nötig.

Semantisches HTML als Accessibility-Fundament

<!-- Statt: <div class="btn" onclick="..."> -->
<button type="button">Aktion</button>

<!-- Statt: <div class="link"> -->
<a href="/seite">Navigation</a>

<!-- Statt: <div class="alert"> -->
<output role="status" aria-live="polite">Gespeichert</output>

Screenreader, Tastatur-Navigation, Fokus-Management – all das funktioniert automatisch mit semantischem HTML. Jedes <div>, das ein <button> sein sollte, kostet Accessibility-Punkte und erfordert extra ARIA. Jedes korrekte HTML-Element liefert das gratis.

CSS `:has()` – der fehlende Eltern-Selektor

:has() verändert CSS fundamental. Zum ersten Mal kann ein Element basierend auf seinen Kindern gestylt werden:

/* Formular-Gruppe hervorheben, wenn ein Input fokussiert ist */
.form-group:has(input:focus) {
  border-color: #3b82f6;
  box-shadow: 0 0 0 3px rgba(59, 130, 246, 0.1);
}

/* Navigation anpassen, wenn ein Dropdown offen ist */
nav:has([popover]:popover-open) {
  background: #f8fafc;
}

/* Card-Layout ändern, wenn ein Bild vorhanden ist */
.card:has(img) {
  grid-template-rows: 200px 1fr;
}

Viele Zustands-abhängige Styles, die bisher JavaScript brauchten – Klassen toggeln, classList.add, MutationObserver – lassen sich jetzt rein in CSS lösen.

Was Alpine bisher gelöst hat – und was jetzt nativ geht

Ein typisches Alpine-Dropdown sieht so aus:

<div x-data="{ open: false }">
  <button @click="open = !open">Menü</button>
  <nav x-show="open" @click.outside="open = false">
    <a href="/profil">Profil</a>
    <a href="/einstellungen">Einstellungen</a>
  </nav>
</div>

Das ist elegant. Wenig Code, deklarativ, direkt im HTML. Alpine hat dieses Pattern populär gemacht – zu Recht.

Dasselbe nativ:

<button popovertarget="menu">Menü</button>
<nav id="menu" popover>
  <a href="/profil">Profil</a>
  <a href="/einstellungen">Einstellungen</a>
</nav>

Kein JavaScript, kein Framework, kein Bundle. Click-Outside, Escape-zum-Schließen, Top-Layer – alles eingebaut. Und im Gegensatz zu Alpine: serverseitig gerendert, kein Hydration-Problem, kein FOUC.

Das ist kein Argument gegen Alpine. Alpine löst auch komplexere reaktive Patterns im DOM, die nativ nicht abbildbar sind. Aber für Dropdowns, Modals, Toggles und Accordions – den Kern dessen, wofür Alpine in den meisten Projekten eingesetzt wird – gibt es jetzt einen zweiten Weg. Einen, der keine Dependency braucht.

Anchor Positioning – Tooltips ohne JavaScript-Positionierung

Eines der hartnäckigsten JavaScript-Probleme: Elemente relativ zu einem Trigger positionieren. Tooltips, Dropdowns, Kontextmenüs – bisher brauchte man dafür Floating UI, Popper.js oder eigene Berechnungen. Seit 2024/2025 geht das nativ.

.trigger {
  anchor-name: --menu-trigger;
}

.dropdown {
  position: fixed;
  position-anchor: --menu-trigger;
  top: anchor(bottom);
  left: anchor(left);
  position-try-fallbacks: flip-block, flip-inline;
}

position-try-fallbacks macht das, wofür Floating UI hunderte Zeilen JavaScript braucht: automatisch die Position umdrehen, wenn der Viewport-Rand erreicht wird. Kein ResizeObserver, kein IntersectionObserver, kein manuelles Neuberechnen bei Scroll.

In Kombination mit popover:

<button popovertarget="tooltip" style="anchor-name: --tip-trigger">Hilfe</button>
<div id="tooltip" popover="hint"
     style="position-anchor: --tip-trigger; top: anchor(bottom); left: anchor(center);">
  Hier steht die Erklärung.
</div>

Ein Tooltip mit automatischer Positionierung, Light Dismiss, Top Layer und Keyboard-Support. Null JavaScript. Keine Dependency.

Container Queries – responsive Komponenten statt responsive Seiten

Media Queries reagieren auf den Viewport. Container Queries reagieren auf den Container. Das klingt nach einem kleinen Unterschied, ist aber ein Paradigmenwechsel.

.card-container {
  container-type: inline-size;
  container-name: card;
}

@container card (min-width: 400px) {
  .card {
    display: grid;
    grid-template-columns: 200px 1fr;
  }
}

@container card (max-width: 399px) {
  .card {
    display: flex;
    flex-direction: column;
  }
}

Eine Card-Komponente, die sich an ihren Container anpasst – egal ob sie in einem schmalen Sidebar oder einem breiten Content-Bereich steht. Bisher brauchte man dafür ResizeObserver und dynamische Klassen. Jetzt ist es eine CSS-Regel.

Das macht Komponenten portabel. Eine Card funktioniert überall, ohne zu wissen, wo sie eingebaut wird. Kein JavaScript. Kein Framework. Keine Breakpoint-Props.

View Transitions – Seitenübergänge ohne Animation Libraries

Seitenwechsel in Multi-Page-Apps waren immer abrupt. Single-Page-Apps hatten Transitions, aber zum Preis von Client-Side-Routing, Hydration und Framework-Overhead. View Transitions schließen diese Lücke.

@view-transition {
  navigation: auto;
}

::view-transition-old(root) {
  animation: fade-out 200ms ease-out;
}

::view-transition-new(root) {
  animation: fade-in 200ms ease-in;
}

.hero-image {
  view-transition-name: hero;
}

Zwei Zeilen CSS und jeder Seitenwechsel wird animiert. Für Shared-Element-Transitions – ein Bild, das von der Übersicht in die Detailseite fliegt – reicht ein view-transition-name auf beiden Seiten. Der Browser rechnet die Animation selbst aus.

Astro nutzt das bereits. Keine JavaScript-Animation-Library, kein FLIP-Pattern, kein manuelles getBoundingClientRect(). Und es funktioniert auch bei echten Seitenwechseln, nicht nur bei SPA-Navigation.

CSS Nesting – endlich ohne Preprocessor

SCSS und Less haben jahrelang ein Feature geliefert, das CSS nicht konnte: Verschachtelung. Seit 2024 geht das nativ:

.card {
  padding: 1.5rem;
  border-radius: 0.5rem;

  & .title {
    font-size: 1.25rem;
    font-weight: 600;
  }

  & .body {
    color: #64748b;
  }

  &:hover {
    box-shadow: 0 4px 12px rgba(0, 0, 0, 0.1);
  }

  @media (min-width: 768px) {
    padding: 2rem;
  }
}

Kein SCSS-Compiler, kein Build-Step für Styles, keine node_modules-Dependency. Nativer CSS-Code, der genauso lesbar und strukturiert ist wie SCSS – nur ohne Tooling.

`@layer` – Spezifitäts-Kontrolle ohne `!important`

CSS Cascade Layers lösen das älteste CSS-Problem: Spezifitäts-Konflikte.

@layer reset, base, components, utilities;

@layer reset {
  * { margin: 0; padding: 0; box-sizing: border-box; }
}

@layer components {
  .button { background: #3b82f6; color: white; padding: 0.75rem 1.5rem; }
}

@layer utilities {
  .bg-red { background: #ef4444; }
}

utilities gewinnt immer gegen components, egal wie spezifisch der Selektor ist. Kein !important, keine ID-Selektoren, keine Reihenfolge-Tricks. Tailwind v4 nutzt das bereits intern.

`light-dark()` und `color-mix()` – Theming ohne JavaScript

Dark Mode in CSS, ohne JavaScript-Toggle, ohne doppelte Farbdefinitionen:

:root {
  color-scheme: light dark;
}

body {
  background: light-dark(#ffffff, #1a1a2e);
  color: light-dark(#1a1a2e, #e2e8f0);
}

.card {
  border: 1px solid color-mix(in srgb, currentColor 15%, transparent);
  background: color-mix(in srgb, light-dark(#ffffff, #2a2a3e) 90%, transparent);
}

light-dark() liefert je nach color-scheme den richtigen Wert. color-mix() berechnet Farben dynamisch – Transparenzen, Abstufungen, Hover-States, alles ohne Custom Properties oder JavaScript.

Scroll-Driven Animations – ohne `IntersectionObserver`

Elemente beim Scrollen einblenden – bisher IntersectionObserver plus classList.add. Jetzt:

@keyframes reveal {
  from { opacity: 0; transform: translateY(2rem); }
  to { opacity: 1; transform: translateY(0); }
}

.card {
  animation: reveal linear both;
  animation-timeline: view();
  animation-range: entry 0% entry 100%;
}

Die Animation ist an die Scroll-Position gebunden. Kein JavaScript, kein Observer, kein Cleanup bei Seitenwechseln. Und es läuft auf dem Compositor-Thread – performanter als jede JavaScript-basierte Scroll-Animation.

`field-sizing` und `interpolate-size` – die kleinen Revolutionen

Textareas, die automatisch mitwachsen:

textarea {
  field-sizing: content;
}

Bisher brauchte das einen input-EventListener, scrollHeight-Berechnung und manuelles Setzen der Höhe. Eine CSS-Zeile ersetzt 15 Zeilen JavaScript.

Und smooth Transitions auf auto-Werte – ein Problem, das seit 20 Jahren existiert:

:root {
  interpolate-size: allow-keywords;
}

details > .content {
  height: 0;
  overflow: hidden;
  transition: height 300ms ease;
}

details[open] > .content {
  height: auto;
}

Kein max-height: 999px-Hack mehr. Kein JavaScript, das die tatsächliche Höhe misst. Der Browser animiert von 0 nach auto.

Was sich dadurch ändert

Das Muster der letzten 15 Jahre war immer dasselbe: Browser können zu wenig, also bauen wir eine Abstraktion drüber. jQuery für DOM-Manipulation. Bootstrap für Layout. Alpine für Interaktivität. Floating UI für Positionierung. Framer Motion für Animationen. Jede Schicht löste ein echtes Problem – und wurde zur Abhängigkeit.

Die Plattform hat jetzt in fast allen Bereichen aufgeholt:

Was bisher JavaScript brauchte	Was jetzt nativ geht
Modal mit Overlay und Fokus-Trap	`<dialog>`
Dropdown mit Click-Outside	`popover`
Accordion mit Toggle-State	`<details>`
Formularvalidierung	`required`, `min`, `pattern` etc.
Datepicker	`<input type="date">`
Autocomplete-Logik	`autocomplete`-Attribut
Dynamische UI-Templates	`<template>`
Drag & Drop (einfach)	Native DnD-Events
Fortschrittsanzeige	`<progress>`, `<meter>`
Tooltip-Positionierung	Anchor Positioning
Responsive Komponenten	Container Queries
Seitenübergangs-Animationen	View Transitions
Scroll-basierte Animationen	Scroll-Driven Animations
Auto-growing Textareas	`field-sizing: content`
Transition auf height auto	`interpolate-size`
Dark Mode Toggle	`light-dark()` + `color-scheme`
Spezifitäts-Management	`@layer`
CSS-Verschachtelung	Natives Nesting

Das ist kein gradueller Fortschritt. Das ist ein Paradigmenwechsel. Die Frage bei jedem neuen Feature ist nicht mehr „Welche Library brauche ich?” – sondern „Kann die Plattform das schon?”

2026 lautet die Antwort überraschend oft: Ja.

Wo JavaScript bleibt

Nicht alles lässt sich nativ lösen. Komplexe Formulare mit Validierungs-Logik, Echtzeit-Daten, State der über mehrere Komponenten geteilt wird, API-Calls, WebSocket-Verbindungen – das braucht JavaScript.

Die Grenze ist klar: Sobald es um Logik geht, nicht nur um Zustand oder Darstellung, ist JavaScript das richtige Werkzeug. Aber die Grenze hat sich verschoben. Was gestern Logik war – „toggle diese Klasse, wenn der User klickt”, „positioniere dieses Element relativ zu jenem”, „animiere beim Scrollen” – ist heute ein HTML-Attribut oder eine CSS-Regel.

Für Astro-Projekte, statische Sites und SSR-Anwendungen ist das direkt relevant: Jedes Feature, das nativ in HTML/CSS läuft, muss nicht hydriert werden. Kein Bundle-Overhead, kein Hydration-Delay, keine Framework-Abhängigkeit. Native Elemente haben eingebaute Accessibility – Fokus-Management, ARIA, Keyboard-Handling – und sie funktionieren serverseitig gerendert, ohne Client-JavaScript.

Die Web-Plattform ist nicht perfekt. Aber sie ist 2026 besser als jede Library, die versucht, ihre Lücken zu füllen.

Der eigentliche Perspektivwechsel

Das Problem ist selten fehlendes Können. Das Problem ist der Reflex: Framework zuerst wählen, dann schauen was damit geht.

Wer erst prüft, was der Browser schon kann, kommt überraschend oft ohne Dependency aus. Weniger JavaScript bedeutet weniger Bugs, weniger Wartungsaufwand, weniger Bundle-Size – und oft bessere Accessibility, weil native Elemente das bereits mitbringen.

HTML ist nicht „basic”. Es ist eine durchdachte Plattform, die jahrelang unterschätzt wurde – weil Libraries schneller waren als Browser-Standards. Das hat sich geändert. Der Stack aus <dialog>, popover, nativer Formularvalidierung, <template> und CSS-Nesting macht heute Dinge möglich, für die früher Hunderte Zeilen JavaScript nötig waren.

Die Frage lohnt sich vor jedem neuen Feature: Was kann die Plattform hier schon?