Files
metabuilder/docs/architecture/systems/css-as-abstract-system.md

280 lines
5.2 KiB
Markdown

# CSS as an Abstract System (Not a Language)
If you strip CSS of syntax and web-specific baggage, it becomes a deterministic styling function:
```text
CSS = f(Style Rules, Element Tree, Environment) -> Computed Styles
```
That abstraction is exactly what a GUI designer can expose.
Below is the clean, implementation-agnostic decomposition and how each layer maps to a visual designer UI.
---
## 1. CSS as a layered data model
At its core, CSS consists of five orthogonal systems:
| Layer | Abstract Concept | CSS Name |
| --- | --- | --- |
| Identity | "What is this thing?" | Elements, attributes |
| Selection | "Which rules apply?" | Selectors |
| Conflict resolution | "Which rule wins?" | Cascade, specificity |
| Value resolution | "What does this value mean?" | Computed values |
| Application | "How does it affect appearance?" | Layout / paint |
This separation is critical for GUI mapping.
---
## 2. Identity layer -> Object Inspector
**Abstract model**
Every node has:
- Type (component kind)
- ID (unique)
- Classes (tags/categories)
- Attributes (key/value metadata)
- State vector (hover, active, disabled, focus, etc.)
**GUI mapping**
Inspector panel:
- Tree view of objects
- Editable:
- ID field
- Class list (chip editor)
- Attribute table
- State toggles (simulate `:hover`, `:pressed`)
This directly mirrors how CSS selectors "see" the world.
---
## 3. Selection layer -> Selector Builder
**Abstract model**
A selector is just a predicate over a node and its context.
Formally:
```text
selector(node, ancestry, state) -> true | false
```
**GUI mapping**
Visual selector constructor:
- Base target:
- Type dropdown
- ID picker
- Class checkboxes
- Relationship:
- Descendant / direct parent (optional)
- State flags:
- Hover / Pressed / Focus / Disabled
Represent selectors as structured objects, not text:
```text
Selector {
targetType: Button
classes: ["primary"]
states: [hover]
}
```
Text CSS becomes a serialization, not the authoring format.
---
## 4. Cascade layer -> Rule Priority Stack
**Abstract model**
CSS conflict resolution is a total ordering problem. Rules are sorted by:
1. Importance
2. Origin
3. Specificity
4. Source order
**GUI mapping**
Rule stack view (like layers in Photoshop):
- Each rule is a card
- Visual priority indicators:
- Importance badge
- Specificity meter
- Order handle (drag to reorder)
- Disabled/enabled toggle
User intuition: "This rule overrides that one."
---
## 5. Value system -> Typed property editors
**Abstract model**
CSS values are:
- Typed
- Context-dependent
- Late-bound
Example:
```text
font-size: 1.2em
```
means:
```text
multiply inherited font size by 1.2 at compute time
```
**GUI mapping**
Property editor driven by types:
- Color -> color picker
- Length -> numeric field + unit dropdown
- Enum -> dropdown
- Boolean -> toggle
- Compound -> grouped editor (e.g. margin/padding)
Variables become tokens:
- Global palette
- Component tokens
- Overrides
Users never type `calc()` unless they want to.
---
## 6. Computed values -> Debug and explainability
**Abstract model**
Computed style is a resolved snapshot:
```text
ComputedStyle(node) = resolve(rules, inheritance, environment)
```
**GUI mapping**
Computed style panel:
- Read-only list of final values
- For each value:
- Source rule
- Overridden rules (collapsed)
- Resolved numeric/color result
This is the "why does this look like that?" tool.
---
## 7. Layout as constraint systems
**Abstract model**
Layout is constraint satisfaction, not painting.
- Flexbox -> linear constraints
- Grid -> 2D constraint matrix
- Positioning -> anchor constraints
**GUI mapping**
Layout mode switcher:
- Flow / Flex / Grid / Absolute
- Visual handles for:
- Alignment
- Gaps
- Sizing rules
- Optional overlay visualization
This maps CSS layout primitives to direct manipulation.
---
## 8. Paint and effects -> Layer compositor
**Abstract model**
Painting is a stack of visual effects:
- Background
- Border
- Content
- Shadow
- Filter
**GUI mapping**
Layered appearance editor:
- Background layer
- Border layer
- Shadow layer(s)
- Opacity/blend mode
Each layer editable independently.
---
## 9. Environment and media -> Context simulator
**Abstract model**
CSS rules depend on environment:
- Viewport size
- DPI
- Color scheme
- Platform hints
**GUI mapping**
Environment toolbar:
- Resize viewport
- Toggle dark/light
- DPI slider
- Platform profile selector
Media queries become conditional rule groups.
---
## 10. The unifying mental model for the designer
**What the user is really doing**
They are not "writing CSS". They are:
- Tagging objects
- Defining conditions
- Assigning visual outcomes
- Resolving conflicts visually
Therefore the GUI should expose:
```text
Object -> Conditions -> Effects -> Priority -> Result
```
---
## Key insight
CSS is already a declarative visual programming language. A QML CSS designer should:
- Treat CSS as data, not text
- Expose structure over syntax
- Make cascade and specificity visible and manipulable
---
## TODO
- Map this abstraction to a concrete Qt 6 QML UI layout
- Define a minimal internal schema for "CSS as objects"
- Show how this model round-trips to real CSS or QML styles