Sechs eingebettete HTML-Funktionen, die gängige JavaScript-UI-Bibliotheken ersetzen

Jahrelang sorgte HTML für die Struktur und JavaScript für das gesamte Verhalten: Ein Modal-Fenster erforderte eine React-Bibliothek, ein Tooltip benötigte Popper.js oder Tippy, und serverseitig generierte Komponenten erforderten eigene Skripte. Gleichzeitig fügten der WHATWG HTML Living Standard sowie die Browser-Engines native Bausteine hinzu, die viele dieser Fälle mit nur wenigen Attributen abdecken, wodurch Boilerplate-Code und die Größe der Dateien reduziert werden, während die Barrierefreiheit standardmäßig gewährleistet ist. Dieser Leitfaden behandelt sechs dieser Bausteine, die dafür benötigte Markup-Strukturen sowie die Fälle, in denen weiterhin CSS oder JavaScript erforderlich sind. Überprüfen Sie vor dem Einsatz eines Fallback-Lösungsansatzes die Browserunterstützung für Ihre Zielgruppe.

1. Popovers mit dem popover-Attribut

Tooltip-Elemente und Menüs erforderten traditionell den Umgang mit z-index-Stacking-Contexts sowie die manuelle Implementierung von „Click-outside“-Listenern. Mit der Popover-API wird jedes Element, das das popover-Attribut trägt, beim Öffnen auf die oberste Schicht versetzt – über allen normalen Inhalten hinweg, unabhängig vom z-index. Ein Button, dessen popovertarget die id des Elements angibt, schaltet den Popover ein und aus:

<!-- The Trigger -->
<button popovertarget="my-menu">Toggle Menu</button>

<!-- The Popover Content -->
<div id="my-menu" popover>
  <p>I am natively managed! Press ESC or click outside to close me.</p>
</div>

Ohne jeglichen JavaScript erhält man:

• Deklaratives Schalten: Der Button öffnet und schließt den Popover.
• Einfaches Schließen: Ein Klick außerhalb oder die Drücke der Escape-Taste schließen ihn. Dies gilt für den Standardmodus popover="auto"; bei popover="manual" liegt die Entscheidung beim Benutzer.
• Keine Stacking-Probleme: Der geöffnete Popover wird in der obersten Schicht über allem anderen angezeigt.

Zwei Einschränkungen: Die API steuert Sichtbarkeit und Stapelung, nicht die Platzierung, weshalb das Anheften eines Menüs an seinen Auslöser weiterhin CSS erfordert (klassische Positionierung oder die neuere, weniger weit verbreitete Anchor-Positionierung). Zudem ist ein Popover nicht modal und fängt den Fokus nicht ein, daher sollte für Bestätigungen dialog verwendet werden.

2. Exklusive Akkordeons mit Details und Namen

details und summary bieten bereits seit langer Zeit zusammenfaltbare Abschnitte ohne JavaScript. Die neuere Erweiterung: details-Elemente, die einen gemeinsamen name haben, bilden eine Gruppe, in der nur eines gleichzeitig geöffnet sein kann – ähnlich wie bei einem klassischen Akkordeon.

<details name="faq">
  <summary>What is modern HTML?</summary>
  <p>A living standard evolving directly inside browser engines.</p>
</details>

<details name="faq">
  <summary>Do I still need JavaScript?</summary>
  <p>Much less of it than you used to!</p>
</details>

<details name="faq">
  <summary>Is this supported natively?</summary>
  <p>Yes, across all major modern browser engines.</p>
</details>

Das Öffnen einer Frage schließt alle anderen mit name="faq" geöffneten Elemente, ohne dass dafür Listener, State-Hooks oder Klassentoggles benötigt werden. Browser ohne Unterstützung für name erlauben einfach mehrere geöffnete Elemente – ein eleganter Ersatzweg.

3. Zugängliche Modale mit dialog und ::backdrop

Kundenspezifische div-Überlagerungen scheitern häufig bei Zugänglichkeitsprüfungen, da eine korrekte Modal-Struktur den Fokus innerhalb behalten, die Seite dahinter blockieren und danach den Fokus wieder auf den Auslöser zurückgeben muss. Das dialog-Element kümmert sich um dies. Im folgenden Beispiel schließt ein Formular mit method="dialog" das Dialogfeld bei jedem Klick auf eine Schaltfläche, und der value-Wert der angeklickten Schaltfläche wird zum returnValue des Dialogfelds:

<dialog id="user-modal">
  <h2>Confirm Action</h2>
  <p>Are you sure you want to delete this repository?</p>

  <!-- A form inside a dialog with method="dialog" closes it automatically -->
  <form method="dialog">
    <button value="cancel">Cancel</button>
    <button value="confirm">Delete</button>
  </form>
</dialog>

<button onclick="document.getElementById('user-modal').showModal()">
  Open Modal
</button>

Die abgedimmte Überlagerung ist das ::backdrop-Pseudo-Element, das mit reinem CSS gestylt wird:

/* Styling the native browser backdrop */
dialog::backdrop {
  background-color: rgba(0, 0, 0, 0.6);
  backdrop-filter: blur(4px);
}

showModal() stellt das Dialogfeld an die oberste Ebene, macht den Rest der Seite inaktiv, behält den Fokus im Dialog und ermöglicht es durch die Taste Escape, ihn zu schließen; bei Schließung geben aktuelle Browser den Fokus wieder an das zuvor fokussierte Element zurück. show() hingegen öffnet das Dialogfeld nicht modalerweise und ohne diese Schutzmechanismen. In React sollte showModal() über einen Ref aufgerufen werden anstelle eines inline-Definierens von onclick.

4. Serverseitig generierte Web Components mit deklarativem Shadow DOM

Früher erforderte das Shadow DOM Client-Side-JavaScript (element.attachShadow({ mode: 'open' })), wodurch serverseitig generierte oder statisch erstellte Web Components bis zum Ausführen der Skripte keine eingebetteten Markup-Strukturen hatten, was zu ungestylten Anzeigen und Layoutänderungen führte. Das deklarative Shadow DOM löst dieses Problem: Ein template mit shadowrootmode innerhalb des Host-Elements beschreibt den Shadow-Tree in HTML:

<user-card>
  <template shadowrootmode="open">
    <style>
      /* Styles here stay encapsulated inside this component */
      h3 { color: #3b82f6; font-family: sans-serif; }
    </style>

    <h3>Jane Doe</h3>
    <p>Senior Frontend Engineer</p>
  </template>
</user-card>

Der Parser wandelt das Template vor der Darstellung in eine Schattenwurzel auf user-card um, sodass die eingeschränkten Styles und das Markup bereits bei der ersten Darstellung sichtbar werden. Hinweis: Dies geschieht nur während der HTML-Parsing-Phase. Markup, das später über innerHTML eingefügt wird, erzeugt keine Schattenwurzel; für dynamische Einfüge sind APIs wie setHTMLUnsafe() erforderlich – prüfen Sie daher die aktuelle Unterstützung.

5. Priorisierung kritischer Ressourcen mit fetchpriority

loading="lazy" sowie async/defer können nicht angeben, welche Ressourcen zuerst wichtig sind. Wenn mehrere Bilder oberhalb des Scrollbereichs vorhanden sind, sollte das Hauptebild hinter dem Largest Contentful Paint (LCP) Vorrang vor Abzeichen und Icons haben. fetchpriority gibt dem Netzwerkplaner diesen Hinweis:

<!-- Critical LCP Image: Load this immediately! -->
<img src="hero-banner.webp" fetchpriority="high" alt="Product Hero">

<!-- Lower priority images -->
<img src="avatar.webp" fetchpriority="low" alt="User avatar">

<!-- Critical JavaScript bundle -->
<script src="app.js" fetchpriority="high"></script>

Dies kann die Core Web Vitals verbessern, ohne die Anwendungslogik zu verändern. Es handelt sich dabei um einen Hinweis, nicht um einen Befehl – das Markieren vieler Ressourcen als high hebelt den Nutzen wieder auf. Laden Sie außerdem niemals das LCP-Bild verspätet.

6. Eigene Vorschläge mit datalist

Viele Projekte fügen ein aufwändiges Autocomplete-Element hinzu, nur um Werte vorzuschlagen, während gleichzeitig freier Text erlaubt wird. datalist erledigt dies nativ: Verbinden Sie es über das list-Attribut des Eingabefeldes, und seine Optionen werden zu Vorschlägen.

<label for="framework">Choose or type a framework:</label>
<input list="frameworks" id="framework" name="framework" placeholder="e.g. Next.js">

<datalist id="frameworks">
  <option value="Next.js"></option>
  <option value="SvelteKit"></option>
  <option value="Nuxt.js"></option>
  <option value="Astro"></option>
  <option value="Remix"></option>
</datalist>

Der Browser rendernt und filtert die Liste, kümmert sich um die Tastaturnavigation und folgt dem Design der Plattform. Der Kompromiss liegt in der Kontrolle: Die Gestaltung ist begrenzt, das Verhalten unterscheidet sich zwischen Browsern und Mobilgeräten, und erweiterte Optionen sind nicht möglich. Ideal für einfache „auswählen oder eingeben“-Felder; ein markengerechter Combobox benötigt weiterhin ein eigenes Element.

Eigene Funktion gegenüber dem alten Ansatz

• Tooltip-Elemente und Menüs: popover anstelle einer Positionierungsbibliothek sowie Handhabung von Klicks außerhalb des Elements und der Taste Escape (die eigentliche Positionierung stammt weiterhin aus CSS).
• Akkordeons: details-Elemente, die einen gemeinsamen name teilen, anstelle von Zustandsverwaltung und Schalterlogik in JavaScript.
• Modale Fenster: dialog mit showModal() und ::backdrop anstelle eines benutzerdefinierten Überlagerungselements mit manueller Fokussierungsverwaltung.
• Eingebettete, auf dem Server generierte Komponenten: template shadowrootmode anstelle von ausschließlich clientseitigen attachShadow()-Aufrufen.
• Ladeprioritäten: fetchpriority anstelle manueller Vorklapptricks oder einer durch Skripte gesteuerten Ladereihenfolge.

Eingabevorschläge: Für einfache Fälle datalist anstelle eines benutzerdefinierten Autocomplete-Widgets verwenden.

Für einen umfassenderen Überblick über Plattformfunktionen, die Abhängigkeiten ersetzen können, sehen Sie unsere Übersicht zu nativen Browser-APIs, die beliebte npm-Pakete ersetzen.

Kernpunkte

• Browser liefern nun Funktionalitäten, die früher Bibliotheken erforderten – oft mit integrierter Fokusbearbeitung und Schließen per Escape-Taste.
• Nativ bedeutet nicht vollständig: Popovers benötigen CSS für die Platzierung, datalist bietet nur begrenzte Stylingmöglichkeiten, und das Declarative Shadow DOM funktioniert nur zur Zeit der Parsing.
• Bevor Sie eine UI-Abhängigkeit hinzufügen, prüfen Sie, ob ein Element oder Attribut den tatsächlichen Anforderungen für Ihre unterstützten Browser entspricht.