Data Attribute Variants und Custom Variants für State-Driven UI in Tailwind

1. Warum State-Driven UI mehr braucht als Klassen-Toggling

Der klassische Ansatz für zustandsabhängige Darstellung besteht darin, per JavaScript CSS-Klassen hinzuzufügen oder zu entfernen, etwa element.classList.toggle('is-open'). Dieser Ansatz vermischt aber zwei unterschiedliche Verantwortlichkeiten: Der Zustand einer Komponente lebt im JavaScript, die Darstellung dieses Zustands lebt in CSS-Klassennamen, die von Hand synchron gehalten werden müssen. Mit Data Attribute Variants lässt sich diese Kopplung auflösen, indem Tailwind direkt auf ein data-*-Attribut reagiert, das eine Komponente ohnehin für ihren eigenen Zustand pflegt.

Viele moderne Komponentenbibliotheken, darunter auch Alpine.js-Plugins und headless UI-Bibliotheken, setzen bereits data-state-Attribute mit Werten wie open, closed oder active direkt auf das Root-Element einer Komponente. Data Attribute Variants greifen genau diese vorhandene Information ab, statt eine zweite, redundante Zustandsquelle über CSS-Klassen einzuführen. Das reduziert die Fehlerquellen erheblich, weil es nur noch eine einzige Wahrheit über den aktuellen Zustand gibt.

Für State-Driven UI bedeutet das: Der Zustand wird einmal im Markup als Attribut gesetzt, und sämtliche visuelle Reaktion darauf, von einfachen Farbwechseln bis zu komplexen Transitions, wird deklarativ über Tailwind-Klassen mit Data Attribute Variants und eigenen Custom Variants beschrieben, ganz ohne dass JavaScript wissen muss, welche CSS-Klassen für welchen Zustand zuständig sind.

2. Data Attribute Variants: Syntax und Funktionsweise

Die grundlegende Syntax für Data Attribute Variants lautet data-[attribut=wert]:utility, etwa data-[state=open]:block oder data-[disabled]:opacity-50 für ein Attribut ohne festen Wert. Tailwind generiert daraus einen Attribut-Selektor, der exakt matcht, wenn das entsprechende data-*-Attribut mit dem angegebenen Wert auf dem Element vorhanden ist, unabhängig davon, ob dieses Attribut von einer Komponentenbibliothek, von Alpine.js oder von serverseitig gerendertem Markup gesetzt wurde.

Ein wichtiger Unterschied zu klassischen Zustandsvarianten wie hover: oder focus:: Data Attribute Variants reagieren nicht auf Browser-Pseudoklassen, sondern auf tatsächliches Markup, das explizit gesetzt und wieder entfernt werden muss. Das macht sie ideal für Zustände, die eine Anwendung selbst verwaltet, etwa ob ein Akkordeon geöffnet ist, welcher Tab aktiv ist, oder ob ein Formularfeld gerade validiert wird, Zustände also, die nicht direkt aus nativen Browser-Interaktionen ableitbar sind.

<!-- Data attribute variant reacts to data-state set anywhere in the DOM,
     regardless of whether Alpine.js, a headless library or server-rendered
     markup set the attribute -->
<div data-state="open" class="hidden data-[state=open]:block">
  Panel-Inhalt
</div>

<!-- Boolean-style attribute without a fixed value -->
<button data-loading class="data-[loading]:opacity-50 data-[loading]:pointer-events-none">
  Speichern
</button>

3. Data-Attribute und Alpine.js kombinieren

Alpine.js eignet sich besonders gut, um data-*-Attribute reaktiv zu setzen, ohne dass ein Entwickler die Zustandslogik doppelt in JavaScript und in CSS-Klassennamen pflegen muss. Mit x-bind:data-state, kurz :data-state, lässt sich das Attribut direkt an eine Alpine-Variable binden, sodass es automatisch aktualisiert wird, sobald sich der zugrunde liegende Zustand ändert. Tailwinds Data Attribute Variants reagieren darauf ganz ohne zusätzliche Verdrahtung.

Diese Kombination ist in Hyvä-Themes besonders wertvoll, weil Alpine.js dort ohnehin die einzige JavaScript-Schicht ist. Statt in einer Alpine-Komponente :class="open ? 'block' : 'hidden'" zu schreiben, was Darstellungslogik in die JavaScript-Ebene zieht, bleibt mit Data Attribute Variants die gesamte visuelle Logik in Tailwind-Klassen im Markup, während Alpine.js ausschließlich für die Zustandsänderung selbst zuständig ist. Diese Trennung erleichtert spätere Anpassungen am Design erheblich, weil kein JavaScript-Code angefasst werden muss.

<!-- Alpine.js manages state, data attribute variant handles all visual reaction -->
<div x-data="{ open: false }">
  <button x-on:click="open = !open" class="font-semibold text-slate-800">
    Details anzeigen
  </button>

  <div
    x-bind:data-state="open ? 'open' : 'closed'"
    class="hidden data-[state=open]:block mt-2 p-4 rounded-lg bg-slate-50">
    Zusaetzliche Informationen zum Produkt
  </div>
</div>

4. ARIA-Varianten als semantisch verwandtes Konzept

Neben data-*-Attributen unterstützt Tailwind eigene, vordefinierte Varianten für ARIA-Attribute, etwa aria-expanded:, aria-selected: oder aria-disabled:. Der entscheidende Unterschied zu Data Attribute Variants: ARIA-Attribute haben eine feste, standardisierte Bedeutung für Screenreader und andere assistive Technologien, während data-*-Attribute frei definierbar sind und keine semantische Bedeutung für Barrierefreiheit tragen.

Eine gute Faustregel für State-Driven UI: Wo ein Zustand ohnehin aus Gründen der Barrierefreiheit als ARIA-Attribut gesetzt werden muss, etwa aria-expanded="true" bei einem Akkordeon, sollte die visuelle Darstellung direkt an dieses ARIA-Attribut gekoppelt werden, statt zusätzlich ein redundantes data-state-Attribut zu pflegen. Nur für Zustände ohne direktes ARIA-Äquivalent, etwa einen rein visuellen Ladezustand, sind eigene data-*-Attribute die richtige Wahl.

5. Eigene Custom Variants mit @custom-variant definieren

Für wiederkehrende Zustandsmuster, die über die eingebauten Varianten hinausgehen, erlaubt Tailwind v4 die Definition eigener Custom Variants direkt in CSS über die @custom-variant-Direktive. Damit lässt sich ein häufig genutzter, aber umständlich zu schreibender Selektor wie ein bestimmtes data-*-Muster oder eine Kombination mehrerer Bedingungen unter einem kurzen, sprechenden Variantennamen kapseln, der sich danach überall im Projekt wie eine eingebaute Variante verwenden lässt.

Diese Kapselung zahlt sich besonders bei Design-Systemen mit vielen wiederkehrenden Komponenten aus. Statt in jeder Datei erneut data-[state=active]: auszuschreiben, kann eine eigene Variante wie active: im Projekt-Kontext definiert werden, die intern denselben Attribut-Selektor erzeugt, aber im Code sofort erkennbar macht, dass es sich um einen projektspezifischen Anwendungszustand handelt, nicht um eine native Browser-Pseudoklasse.

/* app.css — defining a reusable custom variant for a recurring data attribute pattern */
@import "tailwindcss";

@custom-variant active (&:is([data-state="active"], [data-state="active"] *));
@custom-variant closing (&[data-state="closing"]);

/* Usage anywhere in the project, behaves like a built-in variant:
   <div data-state="active" class="opacity-50 active:opacity-100"> */

6. Kombinierte Varianten für mehrere gleichzeitige Zustände

Reale Komponenten haben selten nur einen einzigen Zustand. Ein Dropdown kann gleichzeitig geöffnet und deaktiviert sein, ein Tab kann aktiv und im Fokus stehen. Tailwind erlaubt das Verketten mehrerer Data Attribute Variants und eingebauter Varianten in beliebiger Kombination, etwa data-[state=open]:focus:ring-2, was die Utility nur dann anwendet, wenn beide Bedingungen gleichzeitig zutreffen.

Bei mehr als zwei oder drei kombinierten Bedingungen wird die Klassenliste allerdings schnell unübersichtlich. Hier zahlt sich eine eigene, über @custom-variant definierte Kombinationsvariante aus, die die häufig gemeinsam auftretende Bedingung, etwa geöffnet und interaktiv gleichzeitig, unter einem einzigen, kurzen Namen zusammenfasst. Diese Investition lohnt sich vor allem bei Komponenten, die in vielen Varianten immer wieder dieselbe Zustandskombination benötigen.

7. Praxisbeispiel: Tab-Komponente mit data-state

Eine Tab-Komponente ist ein klassisches Beispiel für State-Driven UI: Genau ein Tab-Panel ist zu einem Zeitpunkt sichtbar, während der zugehörige Tab-Button visuell hervorgehoben wird. Mit data-state="active" auf dem aktiven Tab-Button und dem zugehörigen Panel lässt sich die gesamte Darstellungslogik ausschließlich über Data Attribute Variants abbilden, während Alpine.js nur dafür zuständig ist, welches data-state-Attribut auf welchem Element gerade den Wert active trägt.

Der Vorteil dieses Musters zeigt sich besonders beim Testen: Ein automatisierter Test kann den Zustand einer Komponente allein über das Vorhandensein und den Wert des data-state-Attributs prüfen, unabhängig von den tatsächlich verwendeten CSS-Klassen. Das entkoppelt Tests von Design-Änderungen, die reine Tailwind-Klassen betreffen, solange das zugrunde liegende data-state-Attribut unverändert bleibt.

<div x-data="{ activeTab: 'details' }" class="border-b border-slate-200">
  <div class="flex gap-4">
    <button
      x-on:click="activeTab = 'details'"
      x-bind:data-state="activeTab === 'details' ? 'active' : 'inactive'"
      class="pb-2 border-b-2 border-transparent text-slate-500 data-[state=active]:border-sky-600 data-[state=active]:text-sky-700">
      Details
    </button>
    <button
      x-on:click="activeTab = 'reviews'"
      x-bind:data-state="activeTab === 'reviews' ? 'active' : 'inactive'"
      class="pb-2 border-b-2 border-transparent text-slate-500 data-[state=active]:border-sky-600 data-[state=active]:text-sky-700">
      Bewertungen
    </button>
  </div>

  <div x-show="activeTab === 'details'" class="pt-4">Produktdetails ...</div>
  <div x-show="activeTab === 'reviews'" class="pt-4">Kundenbewertungen ...</div>
</div>

8. Praxisbeispiel: Toast-System mit Enter- und Exit-Zuständen

Ein Benachrichtigungs-Toast, der beim Erscheinen einfliegt und beim Verschwinden ausblendet, ist ein Fall, in dem Data Attribute Variants gegenüber reinem x-show deutliche Vorteile bieten. Mit einem dreiwertigen data-state-Attribut, etwa entering, visible und leaving, lassen sich für jede Phase eigene Transition-Utilities definieren, ohne dass separate Alpine-Transition-Direktiven für jede einzelne Eigenschaft geschrieben werden müssen.

Dieses Muster skaliert gut auf mehrere gleichzeitig sichtbare Toasts, weil jeder Toast unabhängig seinen eigenen data-state trägt und Tailwind pro Element korrekt reagiert, ganz ohne dass eine zentrale JavaScript-Logik den visuellen Zustand aller Toasts synchron halten müsste. Die Trennung von Zustand im Attribut und Darstellung in Tailwind-Klassen bleibt dabei auch bei mehreren gleichzeitig aktiven Instanzen sauber nachvollziehbar.

<div
  x-data="{ state: 'entering' }"
  x-init="setTimeout(() => state = 'visible', 20)"
  x-bind:data-state="state"
  class="transition-all duration-300
         data-[state=entering]:opacity-0 data-[state=entering]:translate-y-2
         data-[state=visible]:opacity-100 data-[state=visible]:translate-y-0
         data-[state=leaving]:opacity-0 data-[state=leaving]:translate-y-2
         bg-slate-900 text-white rounded-lg px-4 py-3 shadow-lg">
  Artikel wurde zum Warenkorb hinzugefuegt
</div>

9. State-Strategien im direkten Vergleich

Die folgende Übersicht zeigt, welche Strategie für welchen Zustandstyp am besten passt.

In der Praxis kombinieren robuste State-Driven UI-Architekturen alle vier Ansätze gezielt: ARIA-Varianten für Barrierefreiheitszustände, Data Attribute Variants für rein visuelle Anwendungszustände, und eigene Custom Variants für die immer wiederkehrenden Kombinationen aus beiden.

10. Zusammenfassung

Data Attribute Variants wie data-[state=open] lösen ein grundlegendes Architekturproblem von State-Driven UI: Sie erlauben Tailwind, direkt auf Zustände zu reagieren, die eine Komponente ohnehin im Markup pflegt, statt eine zweite, redundante Zustandsquelle über manuell getoggelte CSS-Klassen einzuführen. Kombiniert mit Alpine.js in Hyvä-Themes entsteht eine klare Trennung: Alpine.js verwaltet ausschließlich den Zustand, Tailwind beschreibt ausschließlich die visuelle Reaktion darauf.

Eigene Custom Variants über @custom-variant erweitern dieses Muster für wiederkehrende Zustandskombinationen in Design-Systemen, während ARIA-Varianten dort zum Einsatz kommen, wo ein Zustand ohnehin für Barrierefreiheit erforderlich ist. Wer diese drei Werkzeuge bewusst nach ihrem jeweiligen Zweck einsetzt, statt sie zu vermischen, baut Komponenten, die sowohl leicht testbar als auch leicht wartbar bleiben.

11. FAQ: Data Attribute Variants und Custom Variants