12 KiB
12 KiB
Entscheidungen
Status: Aktiv
Diese Datei haelt Entscheidungen fest, die spaeter wieder auffindbar sein sollen.
Entscheidungslog
| Datum | Thema | Entscheidung | Grund | Status |
|---|---|---|---|---|
| 2026-07-02 | D03 Text-Rhythmus | Page Title zu Page Description nutzt 0px Gap, Page Header zu erstem Content 24px, Section Title zu Section Description 0px und Section Description zu Content 12px. Beschreibende Page-/Section-Texte muessen 150%-Texttokens nutzen; 0px ist ein bewusst definierter Auto-Layout-Gap, kein fehlender Abstand. 0-Line-height-Tokens sind nur fuer garantierte Einzeiler erlaubt. |
150%-Line-height erzeugt bereits optische Hoehe im Textblock. Der Abstand soll deshalb zwischen gerenderten Textboxen stabil bleiben, auch wenn Beschreibungstexte umbrechen. | Entschieden |
| 2026-07-02 | D06 Table Layout Ownership | Row Height, Cell Padding, Header-Dichte und Tabellenvarianten werden ueber die Table-Komponente abgedeckt. Screen-Layouts sollen Tabellen-Padding oder Row-Hoehen nicht manuell nachbauen. IBM Carbon dient als Referenz fuer Row-Size-Systematik (xs 24px, sm 32px, md 40px, lg 48px, xl 64px) und 16px Column Padding; konkrete HiveGrid-Werte kommen aus der Table-Komponente. |
Tabellen sind komponentengetrieben. Einzelne Screens sollen keine eigenen Tabellen-Padding- oder Row-Height-Regeln einfuehren. | Entschieden |
| 2026-07-02 | D05 Form Layout Gap | Komplette Formular-Field-Komponenten stehen standardmaessig 16px auseinander. 12px bleibt kompakter Sonderfall, 24px ist fuer getrennte Formular-Sections. Label/Input-Abstand, Help-/Description-Text, Error-/Message-Abstand und Input-Padding gehoeren zur Form-Input-Komponente. | Formularlayout soll auf Screen-Ebene konsistent bleiben, ohne die Field-Anatomy der Komponenten zu ueberschreiben. | Entschieden |
| 2026-07-02 | D04 Button Layout Ownership | Button-Hoehen, Button-Padding und Button-Varianten werden ueber die Button-Komponente abgedeckt. Standardaktionen nutzen die Default-Variante der Button-Komponente; diese ist Medium und 36px hoch. |
D-D0b soll keine Button-Komponentenregeln duplizieren. Screens sollen den Komponentenstandard verwenden. | Entschieden |
| 2026-07-02 | D08 Dialog Internal Gaps | Normale Dialoge nutzen die Balanced-Gap-Logik: Title -> Description 8px, Field/Form Row Gap 16px, Section Gap 24px, Footer Button Gap 8px. Footer Actions sind standardmaessig rechts ausgerichtet. Mehrzeiliger Text nutzt die 150%-Texttoken; die Gap-Werte bleiben zwischen den gerenderten Bloecken gleich. |
Die Dialoge sollen dicht, aber lesbar bleiben und nicht je Screen eigene Innenabstaende bekommen. Die 150%-Lineheight macht mehrzeilige Textbloecke von selbst hoeher, ohne zusaetzliche Sonderabstaende. | Entschieden |
| 2026-07-02 | D07 Dialog Sizes | Zentrierte Dialoge nutzen XS 420px, S 560px, M 720px und L 1200px max. Dialoge wachsen auf 4K nicht automatisch mit, sondern bleiben in ihrer Breitenklasse zentriert. Fullscreen Dialog nutzt Fill fuer Width und Height innerhalb des Overlays mit aeusserem Rand; Arbeitswert Desktop: width: calc(100vw - 48px), max-width: 2512px, height: calc(100vh - 48px). 2512px entspricht 2K-Breite 2560px minus 24px Rand pro Seite. |
Vier neutrale Groessen decken kurze Bestaetigungen, kleine Formulare, normale Formulare und grosse Editor-Dialoge ab. Fullscreen Dialog bleibt ein temporaeres Overlay und ersetzt keine Page. Auf sehr breiten Monitoren wird er zentriert und nicht unendlich breit. | Entschieden |
| 2026-07-02 | Page, Dialog, Fullscreen Dialog und Drawer | Settings und vergleichbare Verwaltungsbereiche sind Pages, keine Dialoge. Dialoge sind temporaere Overlays ueber einer Page. Fullscreen Dialoge sind grosse temporaere Overlays fuer abgeschlossene Arbeitsmodi, aber keine dauerhaften App-Bereiche. Drawer/Side Panels sind seitliche Bearbeitungsflaechen mit sichtbarem Kontext und brauchen eigene Breitenregeln. | D07 Dialogbreiten duerfen nicht mit Pages, Settings oder Side Panels vermischt werden. | Entschieden |
| 2026-07-02 | Dialog Padding Varianten | Die Subframe-Dialog-Komponente bekommt zwei Padding-Varianten: 16px als Default und 32px als groessere/ruhigere Variante. Diese Werte sollen ueber die Dialog-Komponente kommen, nicht durch freie Padding-Overrides im Screen. |
Dialoge brauchen je nach Groesse und Inhalt unterschiedliche Dichte. Gleichzeitig soll 32px nicht als beliebiger Surface-Standard missverstanden werden. | Entschieden |
| 2026-07-02 | D02 Page, Card und Grid Padding | Page Padding ist immer mindestens 24px und wird nicht fuer kompakte Momente reduziert. Card/Surface Padding und Detail-/Editor-Surface Padding sind standardmaessig 16px. Grid/Card Gap Standard ist 16px, mit 12px als kompaktem Sonderfall fuer enge Teilbereiche. Section Gap Standard ist 24px. 32px Innenabstand ist kein frei verwendbarer Surface-Standard; Ausnahme ist die eigene 32px-Variante der Subframe-Dialog-Komponente. |
HiveGrid soll als Admin-/CRM-App dicht und einheitlich wirken, ohne dass Seiteninhalte zu nah an App Shell oder Browserrand kleben. Kompaktheit entsteht lokal ueber Gaps, nicht ueber weniger Page Padding. Auch grosse Arbeitsflaechen sollen erst konsistent dicht bleiben. | Entschieden |
| 2026-06-30 | Layout Spacing Scale | HiveGrid nutzt fuer Layout-Abstaende einen 8px-Rhythmus mit den Standardwerten 4, 8, 12, 16, 20, 24, 32, 40, 48, 64, 80, 96. Komponenten-Defaults bleiben fuehrend, wenn sie diesen Standard bereits abbilden. |
D-D0b braucht eine klare Spacing-Basis, ohne bestehende Subframe-Komponenten durch manuelle Padding-Overrides zu umgehen. | Entschieden |
| 2026-06-29 | HiveGrid-Integration | Die Subframe UI Standards werden als eigenes Standards-Projekt in das HiveGrid-Wireframe-Repo aufgenommen. | Layout- und Komponentenstandards sollen zentral versioniert werden, ohne die HiveGrid Screen-/Flow-Arbeitsregeln zu vermischen. | Entschieden |
| 2026-06-29 | Aenderungsschutz | Die Subframe UI Standards duerfen nicht nebenbei in normaler Screen-Arbeit geaendert werden; Aenderungen brauchen explizite Aufgabe oder validierte Entscheidung. | Es ist ein eigenes Standards-Projekt und globale Standards duerfen nicht aus einzelnen Screens abgeleitet werden. | Entschieden |
| 2026-06-02 | Speicherung | Das Regelwerk wird als Obsidian-kompatibler Markdown-Ordner gespeichert. | Es soll durchsuchbar, verlinkbar und leicht erweiterbar sein. | Entschieden |
| 2026-06-02 | Scope | Start mit Benennung, States, Varianten, Defaults, Gruppenregeln und komponenteninternen Abstaenden. | Farben, Shadows, Radius und globale Tokens werden groesstenteils in Subframe gepflegt. | Entschieden |
| 2026-06-02 | Regelmodell | Das Modell ist Global -> Gruppe -> Komponenten-Notiz. | Nicht jede Regel gilt fuer jede Komponente und Dopplungen sollen gering bleiben. | Entschieden |
| 2026-06-02 | Sprache | Der Start ist auf Deutsch, weil es fuer die gemeinsame Arbeit einfacher ist. | Spaeter kann auf Englisch umgestellt werden. | Entschieden |
| 2026-06-02 | Komponenten-Seiten | Komponenten-MDs werden fuer relevante Komponenten angelegt, aber nur leichtgewichtig mit Bereich, Subframe-Link, Regeln und Notizen. | Die Tabelle ist keine zentrale Regelquelle; sie soll nur beim Finden und Pruefen helfen. | Entschieden |
| 2026-06-02 | Komponenten-Index | 05_Komponenten-Index.md ist nur eine Link- und Statusuebersicht mit Fertig?-Checkbox, nicht die Regelquelle. |
Wiederverwendbares Vokabular gehoert in 03_Benennung.md, globale API-Regeln in 07_Global-Rules.md und Gruppenregeln in 04_Gruppenregeln.md. |
Entschieden |
| 2026-06-11 | Global Rules | Globale Component-API-Regeln werden in 07_Global-Rules.md gesammelt. |
Die Regeln gelten ueber Komponenten-Gruppen hinweg und sollen nicht mit Gruppenregeln oder Benennungen vermischt werden. | Entschieden |
| 2026-06-04 | Size-Namen | Erlaubte Size-Namen sind 3X Small, 2X Small, Extra Small, Small, Medium, Large, Extra Large, 2X Large und 3X Large. Medium ist der Default, wird aber nicht Default genannt. |
Die Size-Namen gelten global fuer alle Komponenten, sobald eine Komponente Groessen benennt. | Entschieden |
| 2026-06-04 | Bereichsnamen | Komponentenbereiche heissen Actions, Form Inputs, Data Display, Feedback, Overlays, Navigation, Layout, Typography, Utility und Patterns. |
Die Library soll eine klare, englische Taxonomie haben und Data Display nicht doppelt uebersetzen. |
Entschieden |
| 2026-06-04 | Control-Hoehen | Fuer Button- und formularnahe Controls gelten erstmal Small 32px, Medium 36px und Large 48px. |
Buttons, Inputs, Selects und Toggle-artige Controls sollen dieselbe Grundlogik fuer Groessen nutzen. | Entschieden |
| 2026-06-11 | Radius-Namen | Radius-Tokens heissen Radius Small, Radius Medium, Radius Large und Radius Round. Die Werte sind 4px, 8px, 12px und 9999px. |
Radius-Namen sollen zentral benannt werden und nicht pro Komponente neu entstehen. | Entschieden |
| 2026-06-11 | Form Input Padding | Einzeilige textnahe Form Inputs nutzen horizontal 12px Randabstand und 8px Gap zwischen Icon und Text. | Text- und Icon-Ausrichtung soll ueber Form Inputs hinweg konsistent bleiben. | Entschieden |
| 2026-06-11 | Form Input Radius | Textnahe Form Inputs nutzen Radius Small mit 4px. |
Form Inputs sollen eine gemeinsame Corner-Radius-Basis haben. | Entschieden |
| 2026-06-11 | Form Input Breiten | Textnahe Form Inputs bekommen definierte Min Widths und Default Max Widths; Fill Container bleibt optional. | Inputs sollen konsistente Standardbreiten haben, aber in Layout-Kontexten flexibel ausfuellen koennen. | Entschieden |
| 2026-06-20 | Control-Hoehen Scope | Icon Button, Number Input, Search Input, Combobox Autocomplete und der Single-date Date Picker folgen der gemeinsamen Control-Hoehen-Regel fuer Small, Medium und Large. |
Einzeilige Controls und Trigger sollen ueber Actions und Form Inputs hinweg dieselbe Groessenlogik nutzen. | Entschieden |
| 2026-06-20 | Date Picker Basisregeln | Die Single-date Version des Date Picker nutzt vorerst dieselben Basisregeln wie textnahe Inputs: Standardbreite, horizontales Innenpadding und Radius Small. Date-range / von-bis wird separat geklaert. |
Die Basisversion soll konsistent sein; Range-Varianten haben vermutlich andere Breiten und Verhalten. | Entschieden |
| 2026-06-23 | Form Field-Anatomy | Form Inputs nutzen bei Field-Kontexten die Reihenfolge label, helpText, Control und message. Abstaende: Label zu Help text 8px, Help text zu Control 6px, Control zu Message 4px. message ist 12px Medium und heisst in der Naming Convention immer message. |
Label, Hilfetext und unterer Field-Text sollen ueber Form Inputs hinweg gleich benannt, positioniert und getaktet sein. | Entschieden |
| 2026-06-20 / 2026-07-18 | Laufende Aufgaben | 08_Todo.md bleibt die eigenstaendige Quelle fuer konkrete Pruefpunkte und Nacharbeiten der Subframe UI Standards; 06_Backlog.md bleibt fuer langfristige Standards-Themen. Die projektweite Todo.md bindet die Liste nur ein. |
Das Standards-Projekt bleibt self-sufficient, waehrend die zentrale Projektansicht Aufgaben ohne Duplikate aggregiert. | Entschieden |
| 2026-06-04 | State-Namen | default, hover, active, focus, disabled, loading, error und selected sind als State-Namen zugelassen. |
Subframe regelt viele States intern, aber das Regelwerk braucht konsistente Begriffe fuer Dokumentation und Varianten. | Entschieden |
| 2026-06-04 | Focus vs Selected | focus und selected bleiben getrennte States. |
Focus beschreibt aktuellen Interaktionsfokus; Selected beschreibt eine Auswahl oder aktiven Zustand. Beides kann gleichzeitig auftreten. | Entschieden |
Vorlage
| Datum | Thema | Entscheidung | Grund | Status |
|---|---|---|---|---|
| YYYY-MM-DD | Offen |