Übertragung auf eigene Technologien oder anderes Markup

Das KERN Plain Kit liefert strukturiertes HTML und die zugehörigen CSS-Klassen als Blaupause. Du kannst diese Referenz auch nutzen, wenn dein Projekt ein eigenes Framework oder ein CMS mit eigenen Templates verwendet. KERN übernimmt die Gestaltung; deine Technologie übernimmt das HTML-Rendering, die Datenbindung und die Anwendungslogik.

Je nachdem, wie viel Einfluss du auf die HTML-Ausgabe hast, stehen dir zwei Wege offen:

• Variante 1: KERN-Markup erzeugen: Du passt deine Templates an die KERN-Struktur an und nutzt das globale KERN-CSS direkt. Das ist der einfachere Weg, wenn du das Markup kontrollieren kannst.
• Variante 2: Fremdes Markup mit SCSS adaptieren: Das vorgegebene Markup bleibt bestehen. Ein eigener SCSS-Adapter ordnet dessen Klassen den KERN-Regeln zu und gleicht strukturelle Unterschiede aus. Diesen Adapter musst du bei Updates erneut kompilieren und prüfen.

Variante 1: KERN-Markup erzeugen

1. Referenz auswählen: Nimm das HTML aus der Dokumentation der gewünschten Komponente, zum Beispiel des Buttons, und bilde es in deiner Komponente oder deinem Template nach.
2. Struktur und Attribute beibehalten: Übernimm die KERN-Klassen mit ihren Basis-, Element- und Variantenklassen sowie die benötigten data-*-Attribute, etwa data-kern-theme. Entscheidend ist das erzeugte HTML im Browser, nicht die Template-Syntax. Erhalte auch semantische HTML-Elemente, ARIA-Attribute, Label-Zuordnungen und die für CSS-Selektoren erforderliche Verschachtelung.
3. Verhalten anbinden: Verbinde Ereignisse, Zustände und Validierung mit deiner eigenen Technologie. Stelle Tastaturbedienung und Fokusführung sicher; CSS allein liefert keine Interaktionslogik. Beachte bei interaktiven Komponenten die jeweilige Dokumentation und binde benötigtes KERN-JavaScript ein oder implementiere das Verhalten gleichwertig im Framework.

Ein Template für einen primären Button sollte beispielsweise folgendes HTML erzeugen. Beschriftung und Aktion können dabei aus deinem Framework oder CMS stammen:

<button type="button" class="kern-btn kern-btn--primary">
  <span class="kern-label">Weiter</span>
</button>

Binde das globale KERN-CSS wie unter Einbinden von KERN beschrieben ein. Ein eigenes Theme kannst du nach der Anleitung Updatesicheres Theming ergänzen. So profitiert auch die eigene Implementierung von KERN-CSS-Updates, solange Klassen, Attribute und Struktur kompatibel bleiben. Eigene Erweiterungen gehören in projektseitige Komponenten und Stylesheets, nicht in eine veränderte Kopie der Bibliothek.

Variante 2: Fremdes Markup mit SCSS adaptieren

Bei stark abweichendem Markup reicht das Hinzufügen von Klassen allein nicht aus. Wenn du die HTML-Ausgabe deiner Technologie nicht an die Referenz anpassen kannst, brauchst du eigene Adapter-Styles. Mit SCSS-@extend kannst du vorhandene Klassen den KERN-Regeln zuordnen und diese durch eigene Regeln für abweichende Strukturen ergänzen.

Beispiel: Button ohne KERN-Klassen und Label-Element

Angenommen, ein Formularsystem erzeugt einen Button mit der Klasse portal-button und direktem Textinhalt. Das folgende Markup ist frei erfunden und dient nur der Veranschaulichung. Anders als im Plain Kit gibt es hier kein inneres <span class="kern-label">:

<div class="portal-actions" data-kern-theme="light">
  <button type="button" class="portal-button">Weiter</button>
</div>

Lege im eigenen Projekt eine Datei portal-adapter.scss an. Lade die KERN-Regeln mit Sass-@use in denselben Build und erweitere ihre Selektoren mit @extend. Dafür kann Dart Sass auch das bereits kompilierte KERN-CSS als Modul laden:

portal-adapter.scss

@use "@kern-ux/native/dist/kern.css";

.portal-button {
  @extend .kern-btn;
  @extend .kern-btn--primary;

  padding: var(--kern-metric-space-small) var(--kern-metric-space-large);
  font-family: var(--kern-typography-font-family-default);
  font-size: var(--kern-typography-font-size-medium-static);
  font-weight: var(--kern-typography-font-weight-label-default);
  line-height: var(--kern-typography-line-height-medium-static);
  color: var(--kern-color-action-on-default-contextual);
}

@extend ergänzt .portal-button in den passenden KERN-Selektoren, auch bei Regeln für Hover, Fokus und deaktivierte Buttons. Es verändert weder das HTML noch die Dateien im npm-Paket. Es erzeugt aber keine fehlenden HTML-Elemente: Regeln für .kern-btn--primary .kern-label greifen weiterhin nicht auf den direkten Textinhalt. Deshalb setzt der Adapter Textfarbe, Typografie und Innenabstand ausdrücklich auf dem Button und verwendet dafür KERN-Token.

Mit installiertem Dart Sass kannst du die Datei beispielsweise so kompilieren:

npx sass --load-path=node_modules portal-adapter.scss portal-adapter.css

Binde portal-adapter.css als globales Stylesheet ein. Es enthält bereits die mit @use geladenen KERN-Regeln; lade kern.min.css daher nicht zusätzlich. Die Schriftdateien bindest du weiterhin wie unter Einbinden von KERN beschrieben ein. Ein optionales custom-theme.css wird nach dem Adapter geladen. Ein separat verlinktes KERN-CSS allein reicht für @extend nicht aus, weil Sass die zu erweiternden Regeln beim Kompilieren kennen muss.

Was passiert bei KERN-Updates?

Der Adapter bleibt im eigenen Projekt, während KERN als npm-Abhängigkeit aktualisiert wird. Kompiliere den Adapter danach erneut, damit Änderungen an den erweiterten KERN-Regeln in dein Stylesheet gelangen. Eigene Ergänzungen für das abweichende Markup werden nicht automatisch angepasst. Vergleiche sie mit der aktuellen Button-Referenz und prüfe Darstellung, Interaktionen, Farbmodi und Barrierefreiheit. Dieser Weg ist enger an die KERN-Selektoren gekoppelt als reines Theming über CSS-Variablen.