Swap tab background and text colors in card keyboard navigation pattern
This commit is contained in:
@@ -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
|
||||
|
||||
Reference in New Issue
Block a user