StyleX und TYPO3: Bessere Ergebnisse beim Styling mit KI

StyleX bekommt gerade viel Aufmerksamkeit, besonders in Verbindung mit KI-gestützter Frontend-Entwicklung (siehe z.B. Tailwind CSS vs StyleX: Why People Are Switching). 
StyleX selbst ist ein von Meta entwickeltes System zum Schreiben von Styles in JavaScript oder TypeScript. 
Im Dezember 2023 wurde StyleX schließlich auch als OpenSource veröffentlicht, nachdem es bereits seit 2019 für alle Meta Platformen, wie z.B. Facebook, Instagram, WhatsApp (Web / surfaces), Messenger, Threads usw. eingesetzt wurde.
Doch mehr und mehr stellen nun auch andere Firmen, wie z.B. Figma, Snowflake, HubSpot, Linear und Polar ihre Anwendungen auf StyleX um.

Da stellt sich natürlich die Frage: Warum? 

Was sind die Vorteile von StyleX?

Der größte Vorteil dürfte vor allem darin liegen, dass KI Assistenten mit StyleX sehr viel besser umgehen können, als mit klassischem CSS, Bootstrap oder Tailwind. Das liegt an den klaren, einfachen Regeln: Dein Assistent findet die vorgesehenen Designwerte im Code, und die Kombination von Styles wird leichter nachvollziehbar. Wie das genau funktioniert, lässt sich am besten an einem kleinen Beispiel zeigen.

StyleX verstehen, vom Design-Token bis zum fertigen HTML

In der Datei tokens.stylex.js definierst Du zunächst die Gestaltungswerte bzw. “Variablen” Deiner Website:

 

import * as stylex from '@stylexjs/stylex'; 

export const tokens = stylex.defineVars({  
	'--site-color-accent': '#5b35d5',  
	'--site-color-surface': '#ffffff',  
	'--site-space-sm': '1.5rem',  
	'--site-space-md': '2.5 rem',  
	'--site-space-lg': '3.5 rem',  
	'--site-radius-sm': '0.75rem', 
});

 

Das sind Design-Tokens. Jeder Token gibt einem Gestaltungswert einen Namen. --site-space-sm beschreibt beispielsweise einen kleinen Innenabstand. Die Namen mit -- habe ich bewusst gewählt, damit auch gewöhnliches CSS später genau diese Variablen verwenden kann. StyleX unterstützt solche ausdrücklich benannten CSS Custom Properties- dazu später mehr. Variablen-API.

Die kleine Card-Komponente verwendet diese Tokens in Card.stylex.js:

 

import * as stylex from '@stylexjs/stylex'; 
import { tokens } from './tokens.stylex.js'; 

export const styles = stylex.create({  
	root: {    
		backgroundColor: tokens['--site-color-surface'],    
		padding: tokens['--site-space-sm'],    
		borderRadius: tokens['--site-radius-sm'],  
	},  
	title: {    
		color: tokens['--site-color-accent'],  
	}, 
});

 

root enthält die Gestaltung des Card-Containers, title die der Überschrift. Die Werte kommen aus der gemeinsamen Token-Datei. Styles definieren.

Beim Build-Prozess erzeugt StyleX daraus CSS-Variablen und einzelne Klassen für die Deklarationen. Der folgende Ausschnitt basiert auf dem kompilierten Beispiel. Beachte dabei, dass jede Klasse nur eine einzelne Deklaration enthält.:

 

:root {  
	--site-color-accent: #5b35d5;  
	--site-color-surface: #ffffff;  
	--site-space-sm: 1.5rem;  
	--site-radius-sm: 0.75rem; 
} 
.xff6u3m { background-color: var(--site-color-surface); } 
.xv27a3v { padding: var(--site-space-sm); } 
.x1vopvgf { border-radius: var(--site-radius-sm); } 
.x15ao89e { color: var(--site-color-accent); }

 

In TYPO3 verwendest Du die benannten Styles über den ViewHelper des StyleX-Connectors:

 

<article class="{stylex:class(styles: 'Card.root')}">  
	<h2 class="{stylex:class(styles: 'Card.title')}">    
		Deine nächste Idee  
	</h2> 
</article>

 

Im ausgelieferten HTML stehen dann die erzeugten Klassen:

 

<article class="xff6u3m xv27a3v x1vopvgf">  
	<h2 class="x15ao89e">Deine nächste Idee</h2> 
</article>

 

Damit ist das Grundprinzip bereits erklärt. Du definierst Designwerte als Tokens und verwendest sie in benannten Style-Objekten. StyleX erzeugt daraus CSS. Der Connector ordnet die Namen in Deinen Fluid-Templates den erzeugten Klassen zu. Connector-ViewHelper.

Für die gezeigte Verwendung in TYPO3 brauchst Du kein React. Dein Frontend arbeitet weiterhin mit serverseitig gerendertem HTML und CSS. StyleX-Grundlagen, Connector-Architektur.

Wiederverwendete Werte halten Dein CSS klein

Wie bereits erwähnt, enthält jede generierte Klasse immer nur eine einzelne Deklaration. Dieses Prinzip heißt atomisches CSS. Eine identische Kombination aus Eigenschaft und Wert wird unter denselben Bedingungen im gemeinsamen StyleX-Build immer nur einmal erzeugt und anschließend wiederverwendet. StyleX-Projekt.

Verwenden zwanzig verschiedene Komponenten padding: var(--site-space-sm), können sie dieselbe Klasse nutzen. Dafür brauchst Du keine zwanzig getrennte Padding-Regeln. Das gilt ebenso für einen gemeinsam verwendeten Radius.

Neue Komponenten, die sich aus bereits vorhandenen Deklarationen zusammensetzen, können deshalb ohne zusätzliche entsprechende CSS-Regeln auskommen. Dein CSS wächst mit den neuen Gestaltungsregeln, die Du tatsächlich einführst. Die Anzahl Deiner Komponenten bestimmt seine Größe praktisch kaum mehr.

Neue Werte erzeugen weiterhin neue Regeln. Aber ein konsequent verwendetes Designsystem bietet hier besonders viel Wiederverwendung, weil seine Komponenten auf einem gemeinsamen Vorrat an Gestaltungswerten aufbauen.

Für eine TYPO3-Website mit vielen Inhaltselementen ist das sehr attraktiv. Jede neue Komponente kann vorhandene Styles übernehmen, während der gemeinsame CSS-Bestand überschaubar bleibt.

Warum klassisches CSS KI-Assistenten leicht in die Irre führt

Bei klassischem CSS muss ein KI-Assistent berücksichtigen, welche Regeln auf ein Element wirken und welche davon gewinnen. Vererbbare Eigenschaften können von übergeordneten Elementen kommen. Bei konkurrierenden Deklarationen spielen unter anderem Selektorspezifität und CSS-Schichten eine Rolle; bei ansonsten gleichrangigen Regeln entscheidet ihre Reihenfolge im Stylesheet. CSS-Kaskade.

Du kennst das wahrscheinlich aus einem gewachsenen Sitepackage. Eine Regel sieht richtig aus, im Browser erscheint trotzdem eine andere Hintergrundfarbe. Eine später eingebundene CSS-Datei überschreibt die Änderung, oder ein vorhandener Selektor hat eine höhere Spezifität.

Die Herausforderung bleibt auch mit Bootstrap und Tailwind bestehen. Beide erzeugen gewöhnliches CSS, das mit den übrigen Styles Deiner Website zusammenspielt. Ein Assistent muss deshalb die tatsächlich wirksamen Regeln berücksichtigen, einschließlich Deiner eigenen Anpassungen. Bei Tailwind entscheidet außerdem die Reihenfolge im erzeugten CSS über kollidierende Utilities, unabhängig von ihrer Reihenfolge im HTML-Klassenattribut. Tailwind zu Stilkonflikten.

Gerade bei KI-generierten Änderungen kann das zu einer frustrierenden Schleife führen. Der Assistent ergänzt einen Style, sieht dass die Änderung nicht wirkt und versucht beim nächsten Durchlauf einen stärkeren Selektor. Mit weiteren Überschreibungen wird es immer schwieriger, die ursprüngliche Gestaltungsentscheidung wiederzufinden.

Bei StyleX gewinnt der zuletzt angewendete Style

StyleX macht die Kombination konkurrierender Styles ausdrücklich. Wenn zwei angewendete StyleX-Styles dieselbe Eigenschaft setzen, gewinnt der zuletzt angewendete Style. Die Reihenfolge ihrer Definition in verschiedenen Dateien entscheidet diesen Konflikt nicht. Styles kombinieren.

Ergänzen wir die Card um eine hervorgehobene Variante:

 

highlighted: {  backgroundColor: tokens['--site-color-accent'], }

 

Im Fluid-Template wendest Du sie nach dem Grundstil an:

 

<article class="{stylex:class(styles: 'Card.root, Card.highlighted')}">  
	Eine hervorgehobene Karte 
</article>

 

Card.highlighted setzt die Hintergrundfarbe zuletzt. Der Connector wählt für diese Eigenschaft die Klasse der hervorgehobenen Variante aus. Padding und Radius aus Card.root bleiben erhalten. Im HTML landet für diesen Konflikt die passende Hintergrundklasse.

Für die KI ergibt sich daraus eine einfach verständliche Regel. Sie kann eine gewünschte Variante an der Verwendung ergänzen und deren Wirkung nachvollziehen. Die Suche nach einer passenden Lade-Reihenfolge für mehrere komponentenspezifische Stylesheets entfällt für diese StyleX-Komposition.

Tokens geben Deiner KI ein verbindliches Designsystem

Die Token-Datei aus unserem Beispiel ist die Definition deines Designsystems bzw. eines “Theme”. Sie hält fest, welche Werte für Deine Website vorgesehen sind. Damit gibst Du der KI einen konkreten Ausgangspunkt für ihre Gestaltung.

Wenn Du eine weitere Komponente erstellst, kann der Assistent die vorhandenen Tokens lesen und deren Werte übernehmen. Er muss für den Innenabstand keine neue Größe erfinden. Eine Anpassung an --site-space-sm erreicht anschließend alle Komponenten, die diesen Token verwenden.

Das hilft besonders bei größeren Projekten. Neue Komponenten orientieren sich an den vorhandenen Entscheidungen, statt mit jedem Auftrag einen weiteren kleinen Stilunterschied einzuführen. Deine Prompts können auf das Designsystem verweisen, und der dazugehörige Code zeigt dem Assistenten, was damit gemeint ist.

Diese Bindung wird zuverlässiger, wenn Du Token-Verwendung durch automatische Regeln absicherst. StyleX erlaubt grundsätzlich auch freie Werte. Ergänzende Prüfungen können verhindern, dass eine KI die vereinbarte Gestaltung mit neuen Hexfarben oder beliebigen Abständen umgeht. Polar beschreibt diesen Ansatz für sein Designsystem. Polars Erfahrungsbericht.

Auch vorhandene Komponenten können dieselben Variablen verwenden

Die Tokens werden zu normalen CSS Custom Properties. Dadurch kannst Du sie auch dort einsetzen, wo Deine Website weiterhin gewöhnliches CSS, Bootstrap oder Tailwind verwendet.

Ein Bereich für Rich-Text-Ausgaben aus Fluid-Styled-Content könnte beispielsweise die gemeinsame Aktionsfarbe übernehmen:

 

.ce-bodytext a {  color: var(--site-color-accent); }

 

Bei Bootstrap kannst Du geeignete Komponentenvariablen an Dein Designsystem anbinden. Ein ausgewählter Button könnte seine Hintergrundfarbe so erhalten:

 

.site-action.btn {  
	--bs-btn-bg: var(--site-color-accent);  
	--bs-btn-border-color: var(--site-color-accent); 
}

 

Die vorhandenen Komponenten greifen damit auf dieselbe Quelle zurück wie Deine nativen StyleX-Styles. Bootstrap-Button-Variablen.

Bei Drittkomponenten bzw. -extensions brauchst Du eine entsprechende Anbindung über deren CSS-Variablen. Gemeinsame Tokens bieten Dir dafür eine praktische Verbindung; die Zuordnung richtest Du bewusst zentral ein.

Themes verändern das Aussehen, Deine Komponenten bleiben gleich

Auf Deinem tokenbasierten Designsystem kannst Du mit StyleX auch Themes aufbauen. Ein Theme weist denselben Tokens alternative Werte zu. So kann Deine Karte eine dunkle Variante erhalten, während sie weiterhin dieselben Style-Definitionen verwendet.

Mit stylex.createTheme() erstellst Du beispielsweise ein dunkles Theme für die Token-Gruppe aus unserem Beispiel:

 

import * as stylex from '@stylexjs/stylex'; 
import { tokens } from './tokens.stylex.js'; 

export const darkTheme = stylex.createTheme(tokens, {  
	'--site-color-accent': '#b9a3ff',  
	'--site-color-surface': '#18212f',  
	'--site-space-sm': '1.5rem',  
	'--site-space-md': '2.5 rem',  
	'--site-space-lg': '3.5 rem',  
	'--site-radius-sm': '0.75rem', 
});

 

Die Farben ändern sich, während Innenabstand und Radius ihre bisherigen Werte behalten. Die Card verwendet weiterhin var(--site-color-surface), ihre Überschrift weiterhin var(--site-color-accent). StyleX erzeugt für das Theme eine zusätzliche Klasse, die die Variablenwerte festlegt. Theme-API.

Du wendest die Theme-Klasse auf ein umschließendes Element an, beispielsweise auf einen Seitenbereich oder die gesamte Seite. Die dort gesetzten CSS-Variablen stehen auch den untergeordneten Komponenten zur Verfügung. Dadurch kannst Du mehrere Komponenten gemeinsam auf die dunkle Gestaltung umstellen oder alternativ sogar die gesamte Website. Themes erstellen und anwenden.

Für TYPO3 bedeutet das, dass Dein Seitenlayout den Geltungsbereich eines Themes festlegen kann. Die erzeugte Theme-Klasse muss Dein Build dafür dem Fluid-Template zugänglich machen. Auch angebundene Bootstrap-Komponenten oder Rich-Text-Styles können innerhalb dieses Bereichs die alternativen Werte übernehmen, wenn sie dieselben CSS-Variablen verwenden.

Für Deine KI bleibt die Aufgabe sehr überschaubar. Wenn Du ein weiteres Farbschema möchtest, kann sie die Theme-Werte bearbeiten, während die Komponenten ihre vorhandenen Tokens behalten. Dadurch lässt sich die Gestaltung einer weiteren Marke ebenso vorbereiten wie eine dunkle Variante Deiner Website. Neue Komponenten greifen weiterhin auf dasselbe Designsystem zurück.

Automatische Prüfungen reduzieren vermeidbare Fehler

StyleX bietet Unterstützung für statische Typen und ein ESLint-Plugin zur Prüfung der Styles. Damit kannst Du fehlerhafte Style-Definitionen erkennen und projektspezifische Einschränkungen festlegen. Beispielsweise lässt sich absichern, welche Werte für bestimmte Eigenschaften zulässig sind. Statische Typen, ESLint-Plugin.

Für die Zusammenarbeit mit KI ist das ein großer Vorteil. Der Assistent bekommt eine konkrete Fehlermeldung und kann seine Änderung daran korrigieren. Die Regeln Deines Designsystems werden damit zu einem überprüfbaren Teil der Entwicklung.

Ergänzend kann der StyleX-Connector seine Manifest-Dateien und benötigten Schlüssel prüfen. Das hilft, fehlende Zuordnungen vor der Veröffentlichung zu entdecken. Connector-Validierung.

Content Blocks und bestehende TYPO3-Styles zusammenführen

Mit dem StyleX-Connector kannst Du auch Deine Content Blocks an das gemeinsame Designsystem anbinden. Eine Styling-Datei beim jeweiligen Block importiert die zentralen Tokens. Sein Fluid-Template verwendet die dazugehörigen Style-Schlüssel, beispielsweise Card.root und Card.title. Der gemeinsame Frontend-Build nimmt diese Styles auf. Content-Blocks-Integration.

Dadurch kann eine neue KI-generierte Komponente sofort dieselben Gestaltungswerte wie der Rest Deiner Website verwenden. Du gibst dem Assistenten das Block-Template mit der zugehörigen Styling-Datei. Die Token-Definitionen liefern ihm den gemeinsamen gestalterischen Rahmen.

Auch ein Parallelbetrieb mit bootstrap_package und Fluid-Styled-Content ist möglich. Du kannst mit einzelnen eigenen Komponenten beginnen und vorhandene Templates zunächst weiterverwenden. Ihre Styles lassen sich über die gemeinsamen CSS-Variablen schrittweise an Dein Designsystem anbinden. Fluid Styled Content, Bootstrap Package. So kannst Du die Umstellung an einer kleinen Komponente beginnen und anschließend gezielt erweitern.

Wie Vite aus Deinen Styles die fertigen Dateien baut

Nachdem Du die Vorteile nun klar sein sollten, fehlt noch die technische Verbindung. Obwohl theoretisch auch andere Build-Tools funktionieren, empfehle ich Vite für den Frontend-Build. Deine Einstiegspunkt-Datei importiert die verwendeten StyleX-Dateien. Das StyleX-Plugin übersetzt deren Definitionen und erzeugt das CSS. StyleX mit Vite.

Der Manifest-Adapter des Connectors schreibt zusätzlich die Zuordnung zwischen Style-Namen und erzeugten Klassen in eine JSON-Datei. TYPO3 liest dieses StyleX-Manifest. Der ViewHelper kann dadurch beispielsweise Card.root in die benötigten Klassennamen umwandeln.

Vite erstellt außerdem ein eigenes Asset-Manifest, das auf die gebauten CSS- und JavaScript-Dateien verweist. Der Vite Asset Collector kann darüber die passenden Dateien in Deiner TYPO3-Seite einbinden. Die beiden Manifeste erfüllen also unterschiedliche Aufgaben. Vite- und Manifest-Einrichtung.

Auf dem Produktivsystem liefert TYPO3 die vorbereiteten Dateien aus. Für die gezeigten statischen Styles wird das CSS bereits beim Build erzeugt. Die CSS-Dateien und das zugehörige StyleX-Manifest veröffentlichst Du gemeinsam, damit Template-Schlüssel und Styles zusammenpassen.

Diese Voraussetzungen brauchst Du

Für den dokumentierten Composer- und Vite-Einstieg benötigst Du:

• Ein Composer-basiertes TYPO3-Projekt mit installiertem Sitepackage.
• TYPO3 12.4, 13.4 oder mindestens 14.3 innerhalb der 14.x-Reihe.
• Eine passende PHP-Version. TYPO3 12.4 kann mit PHP 8.1 verwendet werden; TYPO3 13.4 und 14.3 benötigen mindestens PHP 8.2. Der Connector unterstützt derzeit PHP bis einschließlich 8.4.
• Node.js in einer zur verwendeten Vite-Version passenden Version sowie eine Einbindung der erzeugten Assets.

Node.js benötigst Du nur für den Build. TYPO3 kann die fertigen Dateien ohne Node.js im PHP-Laufzeitbetrieb verwenden - Node.js ist also auf dem Live-Server nicht notwendig. 
DDEV ist für die lokale Entwicklung optional. Bei TYPO3 12.4 solltest Du im Produktivbetrieb natürlich eine aktuell gepatchte ELTS-Version einsetzen. Voraussetzungen.

Kurze Installation für Dein TYPO3-Projekt

1. Connector und Asset Collector installieren

Führe im Projektverzeichnis aus:

 

composer require skom/stylex-connector 
composer require praetorius/vite-asset-collector

 

Der Collector ist die Asset-Lösung wie in der Dokumentation beschrieben. Eine andere, bereits vorhandene geeignete Asset-Einbindung kannst Du weiterverwenden. Die Extension findest Du auch im TYPO3 Extension Repository. Installation und Aktivierung.

2. Vite um StyleX ergänzen

Bei Verwendung von npm:

 

npm install @stylexjs/stylex 
npm install --save-dev vite vite-plugin-typo3 @stylexjs/unplugin @babel/parser

 

Ergänze das StyleX-Plugin und den mitgelieferten Manifest-Adapter in Deiner Vite-Konfiguration. Importiere Deine Styling-Dateien im Einstiegspunkt. Die Vite-Anleitung enthält die vollständige Konfiguration, einschließlich der CSS-Auslieferung im Entwicklungsbetrieb.

3. Manifest bei TYPO3 registrieren

Trage den erzeugten Manifest-Pfad in der ext_localconf.php Deines Sitepackages ein:

 

\Vendor\StylexConnector\Configuration\StylexRegistry::registerManifest(    
	'my_sitepackage',    
	'EXT:my_sitepackage/Resources/Public/StylexManifest/stylex-manifest.json' 
);

 

Binde den Connector über ein Site Set oder TypoScript ein. Ergänze die Asset-Einbindung im tatsächlich verwendeten Seitenlayout. Pfade und Paketnamen passt Du an Dein Projekt an. TYPO3-Anbindung.

4. Komponente bauen und prüfen

Verwende die Style-Schlüssel im Fluid-Template. Die kurzen Namen aus dem Beispiel sind Aliase des dokumentierten Manifest-Adapters; für größere Projekte kannst Du eindeutige vollständige Schlüssel verwenden. ViewHelper.

Mit einem eingerichteten npm-Build-Script:

 

npm run build 
vendor/bin/typo3 stylex:validate --required-key Card.root 
vendor/bin/typo3 cache:flush

 

Prüfe die Produktionsausgabe bei gestopptem Vite-Entwicklungsserver. Veröffentliche die erzeugten Assets zusammen mit dem passenden StyleX-Manifest. Ausgabe überprüfen.

Native StyleX-Komponenten für TYPO3 sind der nächste Schritt

Ich arbeite derzeit an einer Extension, die fluid-styled-content und bootstrap_package durch eigene native StyleX-Komponenten, basierend auf Astryx, einer Sammlung von über 180 StyleX-Komponenten für React, ersetzen soll. Damit möchte ich eine Grundlage schaffen, bei der die Inhaltselemente von Anfang an auf einem modernen StyleX-Designsystem aufbauen.

Aber wie oben beschrieben, kann der StyleX-Connector auch problemlos mit eigenen Komponenten und anderen Frameworks, wie Bootstrap oder Tailwind verwendet werden.  Definiere einige gemeinsame Tokens und lass z.B. Deinen KI-Assistenten damit einen Content Block gestalten. Anschließend bitte ihn um eine Variante. So kannst Du direkt erleben, wie wiederverwendbare Designentscheidungen und nachvollziehbare Style-Komposition die Zusammenarbeit verbessern.

Probier den StyleX-Connector aus und mach mit

Ich möchte Dich herzlich dazu einladen, den StyleX-Connector einmal in einem kleinen Test-Projekt selbst auszuprobieren.  Nachdem du alles installiert und konfiguriert hast, erstelle zunächst ein paar eigene Design-Tokens und lass dann zum Beispiel mit KI ein paar neue Content-Blocks erstellen und diese mit StyleX stylen.  So kannst Du selbst erleben, wie einfach und präzise KI deine Designwünsche dabei umsetzt.

Ich würde mich über Dein Feedback sehr freuen. Schreib mir gerne, was bei Dir gut funktioniert und wo Du beim Einstieg hängenbleibst. Deine Erfahrungen helfen mir, den StyleX-Connector und seine Dokumentation weiterzuentwickeln.

Wenn Du einen Fehler findest oder eine Idee für eine Verbesserung hast, eröffne gerne ein Issue auf GitHub. Auch Pull Requests sind herzlich willkommen. Ob Du am Code mitarbeiten oder die Dokumentation verständlicher machen möchtest, ich freue mich über jeden Beitrag!

Quellen

• StyleX: Themes erstellen und anwenden und createTheme-API.
• Meta / StyleX: Projekt und atomisches CSS, Grundprinzipien, Styles definieren.
• StyleX: Variablen-API, Styles kombinieren, statische Typen, ESLint-Plugin, Vite-Integration.
• Kenneth Skovhus / Linear: Styling Linear for the future with StyleX, 26. August 2026.
• Polar: Building an LLM safe design system, 16. Juni 2026.
• MDN: Introduction to the CSS cascade.
• Tailwind Labs: Styling with utility classes.
• Bootstrap: Buttons und Komponentenvariablen.
• Sven Kalbhenn: StyleX-Connector auf GitHub und im TYPO3 Extension Repository.
• StyleX-Connector: Architektur, ViewHelper, Content Blocks, Fluid Styled Content, Bootstrap Package.
• StyleX-Connector: Voraussetzungen und Installationsübersicht, Abhängigkeiten, Vite und Manifeste, TYPO3-Anbindung, Überprüfung.