diff --git a/.claude/settings.json b/.claude/settings.json new file mode 100644 index 0000000..02613c3 --- /dev/null +++ b/.claude/settings.json @@ -0,0 +1,9 @@ +{ + "permissions": { + "allow": [ + "Write", + "Edit", + "Bash" + ] + } +} diff --git a/.codex/skills/styleguide-erstellung/SKILL.md b/.codex/skills/styleguide-erstellung/SKILL.md index ab465e8..edcb8bc 100644 --- a/.codex/skills/styleguide-erstellung/SKILL.md +++ b/.codex/skills/styleguide-erstellung/SKILL.md @@ -1,144 +1,137 @@ - --- -name: styleguide erstellung -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. +name: styleguide-erstellung +description: Verwenden für Arbeiten am zentralen Styleguide: CSS, HTML, Foundation Tokens, semantische Tokens, Components, Patterns, Layouts, Templates, Pages, Doku oder Styleguide-Struktur. Erzwingt ein kaskadierendes, portalübergreifendes Design-System. Keine lokalen Styles, Insel-Tokens, Overrides, Workarounds, hardcoded Design Values, redundanten UI-Bausteine oder visuellen Nachbauten. --- # Styleguide-Erstellung ## Ziel -Pflege den Styleguide als zentrales Design-System für mehrere modulare Webportale. +Den Styleguide als zentrales Design-System für mehrere Webportale pflegen. -- 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. +Zwingende Kaskade: -## Kaskade +`Foundation Tokens → semantische Tokens → Components → Patterns → Layouts → Templates/Pages → Usage Guidelines` -Immer diese Ebene wählen und einhalten: +Ergebnis muss clean, produktionsreif und frei von lokalen Insellösungen, Legacy-Resten und visuellen Nachbauten sein. -```text -Foundations → semantische Tokens → Components → Patterns → Layouts → Templates/Pages → Usage Guidelines -``` +Downstream-Portale sollen Layout und Variation so weit wie möglich über CSS, semantische Tokens und vorhandene Bausteine lösen. HTML-Struktur nur ändern, wenn Semantik, Accessibility, Component-Grenzen oder fachliche Datenstruktur es erfordern. -Regeln: +## Token-Kaskade -- 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. +- Foundation Tokens sind die einzige Quelle roher Designwerte: Farben, Typografie, Spacing, Radius, Shadows, Motion, Breakpoints, Z-Index, Containergrößen. +- Neue Foundation Tokens nur nach expliziter Freigabe; bestehende bevorzugt wiederverwenden. +- Semantische Tokens kontextualisieren Foundation Tokens für konkrete Verwendung, z. B. Component, Pattern, Layout oder Page. +- Semantische Tokens müssen immer auf Foundation Tokens verweisen; nie auf hardcoded Design Values. +- Components, Patterns, Layouts, Templates, Pages und HTML dürfen keine direkten Foundation-Token-Zugriffe, lokalen `:root`-Blöcke, Insel-Tokens oder hardcoded Design Values enthalten. +- Lokale Tokens sind nur erlaubt, wenn sie echte semantische Tokens der passenden Ebene sind, zentral in der zuständigen CSS-Datei gepflegt und über `styleguide.css` importiert werden. + +Technische CSS-Werte ohne Designentscheidung sind erlaubt, z. B. `display`, `position`, `overflow`, `width: 100%`, `height: auto`, `flex`, `min-width: 0`. + +## Core vs. Portal + +- Core: Foundations, globale semantische Tokens, Components und generische Patterns. +- Portal-spezifisch: nur klar benannte Layouts, Templates oder Pages mit Portalname im Dateinamen. +- Portal-spezifische Dateien dürfen Core-Bausteine komponieren, aber nicht duplizieren, überschreiben oder visuell nachbauen. +- Wird eine portal-spezifische Lösung mehrfach relevant, in den Core abstrahieren. +- Fachlogik und Dateninterpretation gehören ins jeweilige Portal/Fachmodul, nicht in den Styleguide. ## Ebenenregeln -### Core vs. Portal - -- 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 UI-Bausteine. -- Ohne Freigabe nicht verändern: HTML, Klassen, Nesting, Semantik, Varianten. +- Ohne Freigabe keine Änderung an HTML, Klassen, Nesting, Semantik oder Varianten. - Component-Internals nie von außen überschreiben. - Components nie visuell nachbauen. +- Component-spezifische semantische Tokens in der zuständigen Component-Datei definieren; keine Insel-Tokens im Markup oder in Pages. ### Patterns -- Patterns komponieren bestehende Components für Anwendungsfälle. -- Erlaubt: Pattern-Klassen, Wrapper, Layout, Responsiveness. +- Patterns komponieren bestehende Components für wiederkehrende Anwendungsfälle. +- Erlaubt: Wrapper, Pattern-Klassen, 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-spezifische semantische Tokens nur für Pattern-Kontext definieren und aus Foundations ableiten. +- Wenn ein Pattern Component-Internals stylen müsste: stoppen und Component-Token, Variante oder Architekturentscheidung vorschlagen. -### Layouts und Templates/Pages +### Layouts, Templates und Pages - 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. - -### Dokumentation - -Nachführen, wenn betroffen: - -- `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 +- Templates/Pages sind Komposition aus Layouts, Patterns und Components. +- Layout, Abstände und Varianten primär über CSS und semantische Tokens lösen, nicht über zusätzliche HTML-Struktur. +- HTML-Struktur nur für Semantik, Accessibility, Component-Grenzen oder fachliche Datenstruktur erweitern. +- Keine neuen Foundations, Component-Varianten, lokalen Styles, Insel-Tokens oder visuellen Regeln einführen. ## CSS-Struktur -- 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. +- `styleguide.css` ist der einzige CSS-Einstiegspunkt. Jede neue/geänderte CSS-Datei muss dort importiert sein. +- Foundation Tokens nur in vorgesehenen Foundation-/Base-Dateien, insbesondere `01-foundations.css` und ggf. `02-base.css`. +- Semantische Tokens nur in zentralen Token-Bereichen oder in der zuständigen Component-/Pattern-/Layout-/Template-Datei. +- Components, Patterns, Layouts und Templates liegen in Dateien der passenden Ebene; keine Ebenen vermischen. +- Neue CSS-Dateien nur bei klar neuer Verantwortung; sonst bestehende Datei erweitern. +- Keine verwaisten oder unimportierten CSS-Dateien stehen lassen. + +Import-Reihenfolge: + +`Foundations/Base → globale semantische Tokens → Components → Patterns → allgemeine Layouts → portal-spezifische Layouts → allgemeine Templates/Pages → portal-spezifische Templates/Pages` ## Arbeitsablauf Vor Umsetzung: -1. Task-Scope bestimmen. -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. +1. Scope bestimmen. +2. Relevanten Code und Doku prüfen. +3. Richtige Ebene bestimmen. +4. Core oder portal-spezifisch entscheiden. +5. Bestehende Foundations, semantische Tokens, Components, Patterns, Layouts und Templates auf Wiederverwendung prüfen. +6. Prüfen, ob Layout per CSS statt zusätzlicher HTML-Struktur lösbar ist. +7. Betroffene Doku bestimmen. +8. Nicht belegte Punkte nicht umsetzen; bei Bedarf Rückfrage stellen. -Nicht belegte Punkte nicht umsetzen. Aussagen klassifizieren als: belegt, plausibel, nicht belegt. +Aussagen bei Unsicherheit klassifizieren als: belegt, plausibel, nicht belegt. + +## Dokumentation + +Nachführen, wenn betroffen: + +- `index.html` bei neuen HTML-Seiten +- `foundations.html` bei Foundation-Änderungen +- Token-Doku bei semantischen Token-Änderungen +- betroffene Component-, Pattern-, Layout-, Template- oder Page-Doku ## Verbote Nie einführen oder stehen lassen: -- lokale Styles, lokale `:root`-Blöcke, lokale Token-Blöcke +- lokale Styles, lokale `:root`-Blöcke oder lokale Token-Blöcke +- Insel-Tokens in Components, Patterns, Layouts, Templates, Pages oder HTML +- direkte Foundation-Token-Zugriffe außerhalb semantischer Token-Definitionen - hardcoded Design Values außerhalb Foundations -- überlagernde Korrektur-Styles statt Ursachenbehebung +- Overrides statt Ursachenbehebung +- Workarounds, Quickfixes oder Legacy-Fehlmuster - visuelle Nachbauten bestehender Components/Patterns - portal-spezifische Duplikate von Core-Bausteinen -- Workarounds, Quickfixes, Legacy-Fehlmuster +- unnötige HTML-Wrapper nur für Optik/Layout - unimportierte oder verwaiste CSS-Dateien - Refactorings außerhalb Scope ohne Freigabe -Technische CSS-Werte ohne Designentscheidung sind erlaubt, z. B. `display`, `position`, `overflow`, `width: 100%`, `height: auto`, `flex`, `min-width: 0`. +## Abschluss -## Selbstbereinigung vor Abschluss +Vor Abschluss den bearbeiteten Scope aktiv bereinigen: -Vor jeder Abschlussmeldung aktiv bereinigen: - -- 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 bestätigen: - -- `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 +- Insellösungen, Insel-Tokens, Overrides, Workarounds und Legacy-Reste entfernen. +- lokale Korrekturen auf die richtige Ebene zurückführen: Foundation Token, semantischer Token, Component, Pattern, Layout oder Template. +- Doku und `styleguide.css` aktualisieren. +- sicherstellen, dass Layout-Änderungen primär über CSS und semantische Tokens gelöst sind. +- erst fertig melden, wenn der Scope clean und produktionsreif ist. Kurz berichten: -- geänderte und geprüfte Dateien -- Ebene und Core/Portal-Einordnung -- verwendete/ergänzte Tokens und Bausteine +- geänderte/geprüfte Dateien +- gewählte Ebene und Core/Portal-Zuordnung +- verwendete oder ergänzte Foundation/semantische Tokens +- verwendete oder ergänzte Bausteine +- ob Layout per CSS statt Struktur gelöst wurde - nachgeführte Doku -- entfernte Insellösungen/Workarounds, falls vorhanden -- Bestätigung von Abschlusscheck und Selbstbereinigung -- offene Punkte/Freigaben +- entfernte Insellösungen/Workarounds +- offene Punkte oder nötige Freigaben diff --git a/.tmp-mobile-clear-after.png b/.tmp-mobile-clear-after.png new file mode 100644 index 0000000..26d1650 Binary files /dev/null and b/.tmp-mobile-clear-after.png differ diff --git a/.tmp-mobile-clear.png b/.tmp-mobile-clear.png new file mode 100644 index 0000000..e9ad082 Binary files /dev/null and b/.tmp-mobile-clear.png differ diff --git a/components/interactive-elements.html b/components/interactive-elements.html index 72e11aa..1264bd9 100644 --- a/components/interactive-elements.html +++ b/components/interactive-elements.html @@ -221,7 +221,7 @@ Interactive styleguide variant: The panel opens and closes via the pulldown button above. It closes when clicking outside, when another pulldown opens, or when a sandwich menu opens. - If the panel would overflow the viewport, it aligns from the opposite side of the trigger. + If the panel is wider than the trigger or would overflow the viewport, it aligns from the opposite side of the trigger. Cross-dependencies between pulldowns are application logic and are not defined in this component. --> @@ -623,10 +623,10 @@

form-invalid

-
-
@@ -1173,7 +1173,7 @@ // Pulldown behavior: pulldown demos open their panel below the trigger. // Opening one closes all sandwich menus and any other open pulldown demo. - // If the panel would overflow the viewport, it aligns from the opposite trigger edge. + // If the panel is wider than the trigger or would overflow the viewport, it aligns from the opposite trigger edge. document.querySelectorAll('.sg-pulldown-demo').forEach((demo) => { const trigger = demo.querySelector('.sg-pulldown-demo__trigger'); @@ -1217,8 +1217,9 @@ return; } + const triggerRect = trigger.getBoundingClientRect(); const panelRect = panel.getBoundingClientRect(); - if (panelRect.right > window.innerWidth) { + if (panelRect.width > triggerRect.width || panelRect.right > window.innerWidth) { demo.dataset.align = 'right'; } diff --git a/docs/skill-styleguide-anwendung.md b/docs/skill-styleguide-anwendung.md deleted file mode 100644 index 015a6b2..0000000 --- a/docs/skill-styleguide-anwendung.md +++ /dev/null @@ -1,58 +0,0 @@ -# AGENTS.md — Skill: 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/docs/styleguide-integration-strategy.md b/docs/styleguide-integration-strategy.md deleted file mode 100644 index 4aeb4b0..0000000 --- a/docs/styleguide-integration-strategy.md +++ /dev/null @@ -1,136 +0,0 @@ -# Integrationsstrategie Styleguide -> WebApp_Aktienberater - -Stand: 18. Mai 2026 -Scope: Nur Einbindungsstrategie und Migrationsvorgehen fuer CSS. Keine Frontend-Umbauten in diesem Dokument. - -## 1. Zielbild - -`public/assets/styles.css` bleibt die produktiv eingebundene Datei, wird aber kuenftig deterministisch aus zwei klar getrennten Schichten erzeugt: - -1. `styleguide` (upstream, read-only im Projektkontext) -2. `portal` (lokale App-spezifische Regeln) - -Es gibt keine weitere manuelle Vollkopie von CSS-Bloecken in die Produktionsdatei. - -## 2. Aktueller Ist-Zustand (belegt) - -- Produktivseiten binden `public/assets/styles.css` ein. -- Es gibt keine lokale Styleguide-Kopie mehr im Zielrepo. -- `public/assets/styles.css` enthaelt derzeit einen Mischstand aus Styleguide-Teil plus Legacy-Teil. - -Konsequenz: Updates und Debugging sind aktuell fehleranfaellig, weil keine harte Trennung zwischen upstream und lokal besteht. - -## 3. Verbindliche Struktur (Soll) - -Neue Quellstruktur im Zielrepo: - -- `public/assets/styleguide.upstream.css` - Upstream-Quelle (aus dem Styleguide-Repo uebernommen, im Zielrepo read-only behandeln) -- `public/assets/styles.portal.css` - Lokale Portal-Ergaenzungen/Overrides (einzige lokale CSS-Quelle fuer App-spezifische Abweichungen) -- `public/assets/styles.css` - Build-Output fuer Produktivbetrieb (generiert, nicht manuell gepflegt) - -## 4. Build-Reihenfolge (verbindlich) - -Die Reihenfolge ist fix: - -1. `public/assets/styleguide.upstream.css` -2. `public/assets/styles.portal.css` -3. Ausgabe nach `public/assets/styles.css` - -Damit gilt: - -- Standard liegt im Styleguide. -- Lokale Abweichungen liegen nur im Portal-Layer. -- Keine dritte Ebene mit ad-hoc CSS in Produktivdateien. - -## 5. Migrationsphasen - -### Phase A: Freeze und Trennung - -- Bestehenden Zustand einfrieren (Baseline-Commit). -- Legacy-Abschnitte in `public/assets/styles.css` identifizieren. -- Lokale, weiterhin benoetigte Regeln nach `public/assets/styles.portal.css` verschieben. - -### Phase B: Build-Einfuehrung - -- Build-Skript einfuehren, das die zwei Quellen in fixer Reihenfolge zusammenfuehrt. -- `public/assets/styles.css` nur noch als Build-Output behandeln. - -### Phase C: Bereinigung - -- Doppelte `:root`-Definitionen und ueberschneidende Token schrittweise entfernen. -- Jede entfernte Legacy-Regel gegen produktive Screens verifizieren. - -### Phase D: Regelbetrieb - -- Neue UI-Änderungen nur noch in: - - Styleguide-Repo (globale Patterns/Tokens) oder - - `styles.portal.css` (projektlokale Spezifika) - -## 5a. Verbindliche Migrationsreihenfolge - -Die Ablösung erfolgt in fester Reihenfolge: - -1. Login -2. Hauptliste -3. Detail -4. Admin - -Pro Schritt gilt: - -- Legacy-Regeln nur fuer den jeweiligen Bereich ablösen. -- Smoke-Test direkt nach jeder Ablösung. -- Erst nach bestandenem Test den naechsten Bereich migrieren. - -## 5b. Verbindliche Exit-Kriterien (Legacy entfernt) - -Die Migration ist erst abgeschlossen, wenn alle Punkte erfuellt sind: - -1. `public/assets/styles.css` ist reiner Build-Output aus: - - `public/assets/styleguide.upstream.css` - - `public/assets/styles.portal.css` -2. In `public/assets/styles.css` existiert kein Legacy-Blockmarker mehr: - - `LEGACY STYLES` - - `To be migrated step by step to styleguide system` -3. Keine manuellen Produktivregeln mehr direkt in `public/assets/styles.css`. -4. Alle weiterhin benoetigten lokalen Abweichungen liegen ausschliesslich in `public/assets/styles.portal.css`. -5. Doppelte oder konkurrierende `:root`-Definitionen aus Legacy wurden entfernt. - -## 6. Update-Prozess bei Styleguide-Änderungen - -Ja, es braucht regulaere Updates im Zielrepo, sobald der Styleguide geaendert wurde. - -Minimalprozess: - -1. Neuen Styleguide-Stand nach `public/assets/styleguide.upstream.css` uebernehmen. -2. `public/assets/styles.css` neu bauen. -3. Kurztest der betroffenen Seiten (mindestens: Login, Hauptliste, Detail, Admin). -4. Falls Konflikte auftreten: nur `styles.portal.css` anpassen, nicht upstream patchen. - -## 7. Guardrails - -- Keine manuellen Hotfixes direkt in `public/assets/styles.css`. -- Keine Vermischung von Upstream-Regeln und Portalregeln in derselben Quelldatei. -- Keine erneute Vollkopie alter Legacy-Bloecke. -- Jede Portal-Abweichung braucht kurze Begruendung im Commit. - -## 7a. Verbindliche Abnahme-Checkliste je Migrationsschritt - -Vor dem Abschluss eines jeden Schritts: - -1. Seite rendert ohne visuelle Regressionen in den betroffenen Hauptbereichen. -2. Interaktive Elemente bleiben funktionsfaehig (Buttons, Tabs, Filter, States). -3. Keine neuen direkten Anpassungen in `public/assets/styles.css`. -4. Diff zeigt nur: - - Upstream-Update (`styleguide.upstream.css`) und/oder - - lokale Portal-Regeln (`styles.portal.css`) und Build-Output. -5. Commit-Text dokumentiert kurz, welcher Legacy-Abschnitt abgeloest wurde. - -## 8. Verantwortungsgrenze - -- Styleguide-Repo: Design-System-Wahrheit (Tokens, Components, Patterns). -- WebApp_Aktienberater: Integration, lokale Komposition, produktive Einbindung. - -Damit bleibt das System updatefaehig und driftarm, ohne laufende Frontend-Umsetzung zu blockieren. diff --git a/patterns/options-row.html b/patterns/options-row.html index 7acdec9..4a36238 100644 --- a/patterns/options-row.html +++ b/patterns/options-row.html @@ -264,13 +264,14 @@ return; } + const triggerRect = trigger.getBoundingClientRect(); const panel = demo.querySelector('.sg-pulldown-panel'); if (!panel) { return; } const panelRect = panel.getBoundingClientRect(); - if (panelRect.right > window.innerWidth) { + if (panelRect.width > triggerRect.width || panelRect.right > window.innerWidth) { demo.dataset.align = 'right'; } diff --git a/patterns/page-layout-basic.html b/patterns/page-layout-basic.html deleted file mode 100644 index e07db1e..0000000 --- a/patterns/page-layout-basic.html +++ /dev/null @@ -1,312 +0,0 @@ - - - - - - Styleguide – Page Layout Basic - - - - -

Layout – Page Layout Basic

- -
-
-
-

ValueStockFinder

- -
- - -
- Admin - Logout -
-
- - -
-
- -
-
-
- - -
-
    - - - - -
  • - Menüpunkt 5 -
    • -
-
-
- -
- - -
-
    - - - - -
  • - Menüpunkt 5 -
    • -
-
-
- -
- - - - - 0 Treffer -
-
- -
- - - - - - - Lorem ipsum dolor sit amet, consetetur sadipscing elitr, sed diam nonumy eirmod tempor invidunt. - - -
-
- -
-

H1 Überschrift

-

- Lorem ipsum dolor sit amet, consectetur adipiscing elit. Integer convallis purus sed urna ultricies, id aliquet justo malesuada. Morbi luctus, augue in cursus ultrices, justo lorem posuere mi, at suscipit est turpis vitae ipsum. -

-
- -
-
-

Seiteninhalt

-
- -
-
-
Inhalt
-
- -
-

- Zeile 01
- Zeile 02
- Zeile 03
- Zeile 04
- Zeile 05
- Zeile 06
- Zeile 07
- Zeile 08
- Zeile 09
- Zeile 10
- Zeile 11
- Zeile 12
- Zeile 13
- Zeile 14
- Zeile 15
- Zeile 16
- Zeile 17
- Zeile 18
- Zeile 19
- Zeile 20
- Zeile 21
- Zeile 22
- Zeile 23
- Zeile 24
- Zeile 25
- Zeile 26
- Zeile 27
- Zeile 28
- Zeile 29
- Zeile 30 -

-
-
-
-
- - - - - - diff --git a/patterns/vsf-meldungen.html b/patterns/vsf-meldungen.html index 0ed7495..f316bc8 100644 --- a/patterns/vsf-meldungen.html +++ b/patterns/vsf-meldungen.html @@ -202,7 +202,7 @@
-
+
Mehr laden
@@ -272,7 +272,7 @@
-
+
Mehr laden
@@ -342,7 +342,7 @@
-
+
Mehr laden
@@ -402,7 +402,7 @@
-
+
Mehr laden
@@ -452,7 +452,7 @@
-
+
Mehr laden
@@ -502,7 +502,7 @@
-
+
Mehr laden
@@ -624,13 +624,14 @@ return; } + const triggerRect = trigger.getBoundingClientRect(); const panel = demo.querySelector('.sg-pulldown-panel'); if (!panel) { return; } const panelRect = panel.getBoundingClientRect(); - if (panelRect.right > window.innerWidth) { + if (panelRect.width > triggerRect.width || panelRect.right > window.innerWidth) { demo.dataset.align = 'right'; } diff --git a/styles/36-layouts-page-layout-basic.css b/styles/36-layouts-page-layout-basic.css deleted file mode 100644 index ed2155d..0000000 --- a/styles/36-layouts-page-layout-basic.css +++ /dev/null @@ -1,8 +0,0 @@ -/* ========================================================= */ -/* Layouts: Page Layout Basic */ -/* ========================================================= */ - -.sg-page-layout-basic__heading-block { - margin-top: var(--spacing-large); - margin-bottom: var(--spacing-large); -}