diff --git a/.codex/skills/styleguide-anwendung/SKILL.md b/.codex/skills/styleguide-anwendung/SKILL.md deleted file mode 100644 index 5676958..0000000 --- a/.codex/skills/styleguide-anwendung/SKILL.md +++ /dev/null @@ -1,63 +0,0 @@ ---- -name: styleguide-anwendung -description: Verwenden fuer die verbindliche Anwendung des zentralen Styleguides in konsumierenden Portalen. Erzwingt 1:1-Uebernahme von Patterns/Components, verbietet Inselloesungen und regelt strikt die Trennung von Upstream, Output und Portal-spezifischen Styles. ---- - -# Styleguide-Anwendung - -## Zweck - -Dieser Skill regelt verbindlich die fachlich korrekte Anwendung des zentralen Styleguides in konsumierenden Portalen. - -## Scope - -- Gilt nur fuer konsumierende Portal-Repositories. -- Gilt fuer die Anwendung von Tokens, Components, Patterns, Layouts und Templates aus dem Styleguide. - -## Verbindliche Regeln - -1. Reuse first: Styleguide-Bausteine MUESSEN 1:1 angewendet werden; visuelle Nachbauten sind verboten. -2. Components MUESSEN in Struktur, Klassenlogik und Semantik unveraendert bleiben. -3. Wenn ein passender Baustein existiert, SIND lokale Sondervarianten und Inselloesungen verboten. -4. Lokale Designentscheidungen ausserhalb des Styleguide-Systems sind verboten (Farben, Spacing, Typography, Radius, Shadow, States). -5. Ueberschreibungen von Component-Internals aus dem Portal-Kontext sind verboten. -6. Portal-spezifische Regeln sind nur zulaessig, wenn kein passender Baustein existiert, der Need fachlich belegt ist und keine Duplikation entsteht. -7. Jede lokale Abweichung MUSS minimal, rueckbaubar, klar begruendet und auf den konkreten Portal-Kontext begrenzt sein. -8. `public/assets/styles.css` ist read-only; manuelle Portal-Styles darin sind verboten. -9. `public/assets/styleguide.upstream.css` ist read-only; Upstream wird nie lokal gepatcht. -10. Eigene Portal-Styles duerfen ausschliesslich in `public/assets/styles.portal.css` gepflegt werden. - -## 1:1-Uebernahmepflicht (kritisch) - -Wenn ein Pattern oder Component aus dem Styleguide vorgegeben ist, gilt: - -1. HTML-Struktur wird 1:1 uebernommen (kein vereinfachtes oder umgebautes Markup). -2. Klassenbezeichnungen werden 1:1 uebernommen (keine Umbenennungen, keine Teilmengen). -3. Alle dokumentierten States werden umgesetzt (z. B. default, hover, focus, active, disabled, selected). -4. Alle dokumentierten Interaktionen/Funktionalitaeten werden umgesetzt (keine Teilimplementierung). -5. Accessibility-Merkmale werden 1:1 uebernommen (ARIA, Labels, Keyboard-Fokus, semantische Elemente). -6. "Sinngemaesse" Nachimplementierung ist unzulaessig; erlaubt ist nur die vollstaendige Uebernahme oder eine explizit freigegebene Abweichung. - -## Guardrails - -- Keine Umgehung des Styleguides durch Inline-Styles oder seitenlokale Ad-hoc-CSS-Dateien. -- Keine erneute Einfuehrung von Legacy-CSS-Bloecken oder lokalen Vollkopien von Styleguide-Regeln. -- Keine Mischung von Upstream-Logik und Portal-Logik in derselben Quelldatei. -- Konflikte mit Upstream werden nicht durch Hotfixes in Output-Dateien geloest. - -## Arbeitsmodus bei Aenderungen - -1. Zuerst pruefen: Deckt ein bestehender Styleguide-Baustein den Fall ab. -2. Wenn ja: unveraendert uebernehmen (Pfad endet hier). -3. Wenn nein: minimalen Portal-Zusatz in `styles.portal.css` umsetzen, ohne Component-Internals zu beruehren. -4. Betroffene Views auf visuelle und funktionale Regressionen testen. -5. Lokale Abweichung im Commit mit kurzer fachlicher Begruendung dokumentieren. - -## Abnahmekriterien - -- Vorhandene Styleguide-Bausteine wurden priorisiert und nicht lokal dupliziert. -- Keine Portalregel greift in Component-Internals ein. -- Alle lokalen Regeln sind auf das notwendige Minimum begrenzt. -- `styles.css` und `styleguide.upstream.css` sind frei von manuellen Portal-Handedits. -- Lokale Regeln in `styles.portal.css` sind fachlich begruendet und rueckbaubar dokumentiert. -- Vorgegebene Patterns/Components sind in HTML, Klassen, States, Interaktionen und A11y vollstaendig 1:1 uebernommen. diff --git a/.codex/skills/styleguide-erstellung/SKILL.md b/.codex/skills/styleguide-erstellung/SKILL.md index 7f4251d..ab465e8 100644 --- a/.codex/skills/styleguide-erstellung/SKILL.md +++ b/.codex/skills/styleguide-erstellung/SKILL.md @@ -1,261 +1,144 @@ + --- name: styleguide erstellung -description: Verwenden für jede Weiterentwicklung des Styleguides. Erzwingt eine sauber kaskadierende, skalierbare Design-System-Architektur mit klarer Trennung von Foundations, semantischen Tokens, Components, Patterns, Layouts, Templates und Usage Guidelines. Nutze diesen Skill immer, wenn CSS, HTML, Tokens, Components, Patterns, Layouts, Templates, Dokumentation oder Styleguide-Strukturen geändert, erweitert oder geprüft werden. +description: Verwenden für jede Weiterentwicklung oder Prüfung des zentralen Styleguides: CSS, HTML, Tokens, Components, Patterns, Layouts, Templates, Doku oder Styleguide-Struktur. Erzwingt ein kaskadierendes, portalübergreifendes Design-System ohne lokale Insellösungen, Workarounds, Hardcoded Design Values oder redundante UI-Bausteine. --- # Styleguide-Erstellung ## Ziel -Pflege und erweitere den Styleguide als skalierbares Design-System für große Webportale. +Pflege den Styleguide als zentrales Design-System für mehrere modulare Webportale. -Jede Änderung muss: +- Core: allgemeine Foundations, semantische Tokens, Components, Patterns und Guidelines für alle Portale. +- Portal-spezifisch: nur klar benannte Layouts/Templates/Pages, z. B. mit Portalname im Dateinamen. +- Ergebnis: cleanes, produktionsreifes Template ohne lokale Styles, Overrides, Workarounds, Legacy-Reste oder visuelle Nachbauten. -- sauber kaskadieren, -- der richtigen Styleguide-Ebene zugeordnet sein, -- bestehende Bausteine respektieren, -- langfristig wartbar und wiederverwendbar sein, -- zentral über Foundation Tokens und semantische Tokens in `styleguide.css` steuerbar bleiben, -- ohne lokale Sonderlösungen, visuelle Nachbauten oder Workarounds auskommen. +## Kaskade -## Verbindliche Struktur und Kaskade - -Der Styleguide wird nach dieser Kaskade entwickelt: +Immer diese Ebene wählen und einhalten: ```text -Foundations / Grundlagen -→ Semantische Tokens / Design Tokens -→ Components / Komponenten -→ Patterns / Muster -→ Layouts -→ Templates / Seitentemplates -→ Usage Guidelines / Anwendungsrichtlinien +Foundations → semantische Tokens → Components → Patterns → Layouts → Templates/Pages → Usage Guidelines ``` -Jede neue oder geänderte Lösung muss der passenden Ebene zugeordnet werden; Component- und Pattern-Kapitel dokumentieren dabei die semantischen Tokens, die dort verwendet werden. - -## Modul-CSS-Konvention (verbindlich) - -Wenn der Styleguide modularisiert ist (z. B. `styles/*.css`), gelten zusätzlich: - -- `styleguide.css` ist der einzige CSS-Einstiegspunkt und enthält ausschließlich die verbindliche `@import`-Reihenfolge. -- Neue CSS-Datei nur anlegen, wenn eine klar abgegrenzte fachliche Verantwortung entsteht (z. B. neues Pattern, neues Layout, neue Page/Template-Sektion). Bestehende Verantwortung wird in bestehender Datei erweitert. -- Foundations und semantische Tokens werden zentral gepflegt (Foundations + semantische Token-Definitionen in `styleguide.css`/zentralem Token-Bereich), nicht verteilt über Pattern-/Layout-Dateien. -- Components, Patterns, Layouts und Templates liegen in eigenen Moduldateien der jeweiligen Ebene; keine Vermischung fachfremder Ebenen in einer Datei. -- Nomenklatur neuer Moduldateien: - - Dateiname klein, kebab-case, ASCII. - - Präfix mit Ordnungsgruppe, z. B. `01-`, `10-`, `20-`, `30-`, `40-`. - - Danach Ebenenbezug + fachlicher Name, z. B. `22-patterns-object-card.css`. -- Neue oder umbenannte Moduldateien müssen im selben Change-Set in `styleguide.css` per `@import` ergänzt/aktualisiert werden. -- Import-Reihenfolge bleibt strikt kaskadierend: - - Foundations/Base/Helpers - - Components - - Patterns - - Layouts - - Templates/Pages -- Pro Datei genau ein primärer fachlicher Verantwortungsbereich; Sammel-/Restdateien ohne klare Verantwortung sind zu vermeiden. - -## Ebenenregeln - -### Foundations - -Foundations sind die einzige Quelle für konkrete visuelle Werte, z. B. Farben, Typografie, Spacing, Grid, Icons, Shadows, Border-Radius, Motion, Breakpoints, Z-Index und Containergrößen. - -Neue oder geänderte Foundation-Werte nur nach Rückfrage und expliziter Freigabe einführen. - -### Semantische Tokens / Design Tokens - -Semantische Tokens abstrahieren Foundation Tokens nach Bedeutung, Zweck oder Verwendung im Interface und werden zentral in `styleguide.css` gepflegt. - -Sie benennen nicht den konkreten visuellen Wert, sondern die Rolle im System, z. B. `surface-button-active`, `text-button-process` oder `layout-input-label-width`. - Regeln: -- Keine hardcoded Design Values außerhalb der Foundations. -- Semantische Tokens sind Aliase oder Kaskaden auf Foundation Tokens. -- Neue oder geänderte semantische Tokens an der fachlich passenden Stelle in `styleguide.css` ergänzen. -- Semantische Tokens für `Patterns` und `Layouts` werden jeweils in eigenen CSS-Moduldateien unter `styles/` gepflegt und über `styleguide.css` importiert. -- Struktur, Reihenfolge, Gruppierung, Kommentarlogik und Benennungssystematik von `styleguide.css` einhalten. -- Wenn CSS in Moduldateien (z. B. unter `styles/`) ausgelagert ist, muss jede neue oder umbenannte Moduldatei explizit per `@import` in `styleguide.css` eingehängt werden; unimportierte Moduldateien sind unzulässig. -- HTML-Dateien dürfen keine lokalen Token-Blöcke, keine eigenen `:root`-Definitionen und keine abweichenden Token-Definitionen enthalten. -- HTML-Dateien dürfen semantische Tokens nur aus `styleguide.css` referenzieren. +- Foundations sind die einzige Quelle konkreter Designwerte: Farben, Typografie, Spacing, Radius, Shadows, Motion, Breakpoints, Z-Index, Containergrößen. +- Neue Foundation Tokens nur nach expliziter Freigabe; bestehende Foundation Tokens bevorzugt wiederverwenden. +- Semantische Tokens sind Aliase/Kaskaden auf Foundation Tokens; nie hardcoded Design Values. +- Components, Patterns, Layouts, Templates, Pages und HTML dürfen keine eigenen Foundation Tokens, lokalen `:root`-Blöcke oder hardcoded Design Values enthalten. +- Jede neue/geänderte CSS-Datei muss in `styleguide.css` importiert sein; `styleguide.css` ist der einzige CSS-Einstiegspunkt. -Ergänzungen semantischer Tokens dokumentieren mit: +## Ebenenregeln -- Token-Name -- Token-Typ: Foundation oder semantischer Token für Component, Pattern, Layout oder Template -- Wert oder Alias-Ziel -- kurzer Zweck +### Core vs. Portal -Wenn Foundation Tokens ergänzt oder geändert werden, `foundations.html` nachführen. -Wenn semantische Tokens für Components, Patterns, Layouts oder Templates ergänzt oder geändert werden, die passende Token-Dokumentation nachführen, insbesondere `semantic-tokens-components.html`, sofern dort die bestehende Struktur dafür vorgesehen ist. +- Foundations, globale semantische Tokens, Components und generische Patterns sind portalübergreifend. +- Portal-spezifische Layouts/Templates/Pages dürfen Core-Bausteine komponieren, aber nicht duplizieren, überschreiben oder visuell nachbauen. +- Portal-spezifische Dateien müssen eindeutig nach Portal benannt sein. +- Wird eine portal-spezifische Lösung für mehrere Portale relevant, abstrahiere sie in den Core. +- Fachliche Bedeutung oder Dateninterpretation gehört ins jeweilige Portal/owning Fachmodul, nicht in den Styleguide. ### Components -Components sind kanonische, wiederverwendbare UI-Bausteine. - -Component-Kapitel dokumentieren die semantischen Tokens, die eine Komponente verwendet, jeweils mit zugeordnetem Foundation Token und Verwendungszweck innerhalb der Komponente. - -Ohne explizite Freigabe nicht erlaubt: - -- Component-HTML verändern -- Component-Klassen verändern, ergänzen oder entfernen -- Component-Nesting verändern -- Component-Semantik verändern -- Component-Varianten erfinden -- Components visuell nachbauen -- Component-Internals von außen überschreiben +- Components sind kanonische UI-Bausteine. +- Ohne Freigabe nicht verändern: HTML, Klassen, Nesting, Semantik, Varianten. +- Component-Internals nie von außen überschreiben. +- Components nie visuell nachbauen. ### Patterns -Patterns kombinieren bestehende Components für konkrete Anwendungsfälle. +- Patterns komponieren bestehende Components für Anwendungsfälle. +- Erlaubt: Pattern-Klassen, Wrapper, Layout, Responsiveness. +- Verboten: Component-Optik duplizieren, Component-Internals stylen, Components ersetzen. +- Falls ein Pattern Component-Internals stylen müsste: stoppen und Component-Token/-Variante oder andere Architekturentscheidung vorschlagen. -Pattern-Kapitel dokumentieren die semantischen Tokens, die ein Pattern verwendet, jeweils mit zugeordnetem Foundation Token und Verwendungszweck innerhalb des Patterns. +### Layouts und Templates/Pages -Erlaubt: +- Layouts regeln Struktur, Container, Raster, Anordnung und Responsiveness. +- Templates/Pages sind reine Komposition aus Layouts, Patterns und Components. +- Sie dürfen keine neuen Foundations, Token-Logiken, Component-Varianten, lokalen Styles oder visuellen Regeln einführen. -- eigene Pattern-Klassen -- eigene Layout-/Wrapper-Strukturen -- Pattern-spezifische Responsiveness -- Pattern-spezifische Komposition +### Dokumentation -Nur erlaubt, wenn bestehende Components unverändert eingebettet werden. +Nachführen, wenn betroffen: -Verboten ohne Freigabe: +- `index.html` bei neuen HTML-Seiten +- `foundations.html` bei Foundation-Änderungen +- semantische Token-Seiten bei Token-Änderungen +- betroffene Component-, Pattern-, Layout-, Template- oder Page-Doku -```css -.pattern .component-internal-class { ... } -.pattern .sg-card-segment { ... } -.pattern .sg-button__label { ... } -``` +## CSS-Struktur -Wenn ein Pattern Component-Internals stylen müsste, nicht umsetzen. Rückfrage stellen und begründen, ob ein Component-Token, eine Component-Variante oder eine andere architektonische Lösung nötig ist. - -### Layouts - -Layouts regeln Struktur, Container, Raster und Anordnung. - -Layouts dürfen Flächen strukturieren, Spalten und Container definieren, Abstände zwischen größeren Bereichen steuern und responsive Seitenanordnung regeln. - -Layouts dürfen keine Component-Optik ersetzen, keine Pattern-Logik nachbauen, keine Component-Internals überschreiben und keine lokalen Designwerte einführen. - -### Templates - -Templates beschreiben wiederkehrende Seitentypen. - -Templates verwenden bestehende Layouts, Patterns und Components. Sie dürfen keine neuen visuellen Grundlagen, Component-Varianten oder Pattern-Logiken erfinden. - -### Usage Guidelines - -Usage Guidelines dokumentieren die korrekte Verwendung des Systems. - -Sie klären insbesondere: - -- wann welches Pattern verwendet wird, -- responsive Verhalten, -- Accessibility, -- Dos & Don’ts, -- Abgrenzung ähnlicher Components, Patterns, Layouts oder Templates. - -Guidelines müssen präzise, praxisnah und konsistent mit der bestehenden Styleguide-Struktur formuliert werden. +- Foundation Tokens: nur in vorgesehenen Foundation-/Base-Dateien, insbesondere `01-foundations.css` und, falls vorhanden/strukturell vorgesehen, `02-base.css`. +- Semantische Tokens: nur in vorgesehenen zentralen Token-Bereichen oder klar zugeordneten Component-/Pattern-/Layout-/Template-Dateien; immer über `styleguide.css` importiert. +- Components, Patterns, Layouts und Templates liegen in eigenen Dateien der passenden Ebene; keine Ebenen vermischen. +- Neue CSS-Datei nur bei klar neuer Verantwortung; sonst bestehende Datei erweitern. +- Portal-spezifische CSS-Dateien nur für klar abgegrenzte Layouts/Templates/Pages und mit Portalname im Dateinamen. +- Import-Reihenfolge: Foundations/Base → globale semantische Tokens → Components → Patterns → allgemeine Layouts → portal-spezifische Layouts → allgemeine Templates/Pages → portal-spezifische Templates/Pages. ## Arbeitsablauf -Vor jeder Umsetzung: +Vor Umsetzung: 1. Task-Scope bestimmen. -2. Bestehenden Code und relevante Dokumentation im Scope analysieren. -3. Styleguide-Ebene der Änderung bestimmen. -4. Prüfen, ob bestehende Foundation Tokens, semantische Tokens, Components, Patterns, Layouts oder Templates verwendet werden können. -5. Offene oder nicht belegte Punkte klären. +2. Relevanten Code und Doku im Scope prüfen. +3. Ebene bestimmen. +4. Core oder portal-spezifische Erweiterung bestimmen. +5. Bestehende Tokens, Components, Patterns, Layouts und Templates auf Wiederverwendung prüfen. +6. Nötige Doku-Nachführung bestimmen. +7. Bei nicht belegten Punkten Rückfrage stellen. -Nicht umsetzen, solange eine notwendige Grundlage fehlt. -Wenn etwas nicht eindeutig im Code, in der Dokumentation oder in der Aufgabe belegt ist, Rückfrage stellen. +Nicht belegte Punkte nicht umsetzen. Aussagen klassifizieren als: belegt, plausibel, nicht belegt. -## Scope und Grenzen +## Verbote -Keine Änderungen außerhalb des expliziten Task-Scopes. +Nie einführen oder stehen lassen: -Nicht erlaubt ohne Freigabe: +- lokale Styles, lokale `:root`-Blöcke, lokale Token-Blöcke +- hardcoded Design Values außerhalb Foundations +- überlagernde Korrektur-Styles statt Ursachenbehebung +- visuelle Nachbauten bestehender Components/Patterns +- portal-spezifische Duplikate von Core-Bausteinen +- Workarounds, Quickfixes, Legacy-Fehlmuster +- unimportierte oder verwaiste CSS-Dateien +- Refactorings außerhalb Scope ohne Freigabe -- bestehende Components umbauen -- Foundation Tokens oder semantische Tokens umbenennen -- Kaskade von Foundation Tokens zu semantischen Tokens verändern -- CSS-Struktur aufräumen -- HTML-Struktur verbessern, wenn nicht beauftragt -- neue Foundation-Werte einführen -- neue Component-Varianten erfinden -- bestehende Dokumentationsstruktur neu sortieren +Technische CSS-Werte ohne Designentscheidung sind erlaubt, z. B. `display`, `position`, `overflow`, `width: 100%`, `height: auto`, `flex`, `min-width: 0`. -Neue HTML-Seiten nur dann in `index.html` ergänzen, wenn tatsächlich neue Seiten angelegt werden. Bei reinen Änderungen bestehender Seiten ist keine `index.html`-Anpassung erforderlich. +## Selbstbereinigung vor Abschluss -## Anti-Insellösung +Vor jeder Abschlussmeldung aktiv bereinigen: -Jede Lösung muss systemfähig sein. - -Verboten: - -- lokale Styles zur Umgehung der Architektur -- seitenlokale Sonderregeln statt zentraler Foundation Tokens oder semantischer Tokens -- visuelle Nachbauten bestehender Components -- Workarounds, die Architekturdefizite verdecken -- Legacy-Fehlmuster kopieren -- direkte Designwerte in Components, Patterns, Layouts, Templates oder HTML-Dateien - -Technische CSS-Werte sind erlaubt, wenn sie keine Designentscheidung darstellen, z. B.: - -```css -display: flex; -position: relative; -overflow: hidden; -min-width: 0; -width: 100%; -height: auto; -flex: 1 1 auto; -``` - -Wenn unklar ist, ob ein Wert eine Designentscheidung ist: Rückfrage stellen. - -## Unsicherheiten - -Bewerte relevante Aussagen als: - -- **belegt**: direkt im Code oder in der Dokumentation nachweisbar -- **plausibel**: ableitbar, aber nicht eindeutig belegt -- **nicht belegt**: benötigt Rückfrage oder Freigabe - -Nicht belegte Punkte dürfen nicht umgesetzt werden. +- lokale Insellösungen, Overrides, Workarounds, Legacy-Reste und unsaubere Zwischenlösungen im bearbeiteten Scope entfernen +- lokale Korrekturen auf die richtige Ebene zurückführen: Foundation, semantischer Token, Component, Pattern, Layout oder Template +- keine Aufgabe als fertig melden, solange lokale Styles, hardcoded Werte, visuelle Nachbauten, doppelte Token, unimportierte CSS-Dateien oder veraltete Doku vorhanden sind ## Abschlusscheck -Vor Abschluss prüfen: +Vor Abschluss bestätigen: -- richtige Styleguide-Ebene gewählt -- Kaskade Foundations → semantische Tokens → Components → Patterns → Layouts → Templates → Usage Guidelines eingehalten -- Lokale Overrides sind streng verboten!! Nur sauber kaskadierende Tokens!! -- keine hardcoded Design Values außerhalb der Foundations -- neue oder geänderte semantische Tokens in `styleguide.css` gepflegt -- bestehende Struktur von `styleguide.css` eingehalten -- bei modularisiertem CSS: alle relevanten Moduldateien sind in `styleguide.css` importiert, keine verwaisten `styles/*.css` -- betroffene Dokumentation nachgeführt -- Components unverändert verwendet -- keine Component-Internals überschrieben -- Pattern-CSS steuert nur Komposition, Layout und Responsiveness -- Layout-CSS steuert nur Struktur und Anordnung -- Templates verwenden bestehende Layouts, Patterns und Components -- keine lokalen Token-Blöcke oder `:root`-Definitionen in HTML-Dateien -- keine Refactorings außerhalb Scope -- keine Insellösungen oder Workarounds eingeführt -- Nach der Bearbeitung konsequent alle Legacy entfernen und nur ein cleanes production-reifes Styleguide als Resultat zulassen +- `AGENTS.md` und dieser Skill beachtet +- richtige Ebene und Core/Portal-Zuordnung gewählt +- Kaskade eingehalten +- keine lokalen Styles, Overrides, Workarounds, Legacy-Reste oder hardcoded Design Values +- neue/geänderte Foundation Tokens korrekt gepflegt und freigegeben +- neue/geänderte semantische Tokens korrekt gepflegt, importiert und dokumentiert +- alle relevanten CSS-Dateien in `styleguide.css` importiert +- Components unverändert bzw. nur mit Freigabe geändert +- Patterns bauen auf Components; Layouts/Templates/Pages bauen auf Patterns/Components +- betroffene Doku nachgeführt +- bearbeiteter Scope ist clean und produktionsreif ## Ergebnisbericht -Nach Umsetzung kurz berichten: +Kurz berichten: -- geänderte Dateien -- relevante geprüfte Dateien -- gewählte Styleguide-Ebene -- verwendete oder ergänzte Foundation Tokens und semantische Tokens -- verwendete Components, Patterns, Layouts oder Templates -- nachgeführte Dokumentation -- offene Punkte oder benötigte Freigaben +- geänderte und geprüfte Dateien +- Ebene und Core/Portal-Einordnung +- verwendete/ergänzte Tokens und Bausteine +- nachgeführte Doku +- entfernte Insellösungen/Workarounds, falls vorhanden +- Bestätigung von Abschlusscheck und Selbstbereinigung +- offene Punkte/Freigaben diff --git a/styles/32-patterns-card-group-keyboard-nav.css b/styles/32-patterns-card-group-keyboard-nav.css index 951aa6f..b6f1602 100644 --- a/styles/32-patterns-card-group-keyboard-nav.css +++ b/styles/32-patterns-card-group-keyboard-nav.css @@ -7,7 +7,10 @@ flex-direction: column; gap: var(--spacing-small); width: 100%; - --surface-tab-unselected: var(--color-white); + --surface-tab-selected: var(--color-white); + --surface-tab-unselected: var(--color-dark-grey); + --text-tab-selected: var(--color-dark-grey); + --text-tab-unselected: var(--color-font-light); } .sg-content-block-card-group__tabs,