Design / Coordination / Rendering Context
Design is now a first-class route, not only a trail of side notes.
This page exists to declare intent. It is the place to send a teammate when the question is not only “what should this look like?” but also “which layer is responsible for the behavior, what should stay global, what should stay local, and what still works on a phone?”
My current working model is simple enough to inspect: root attributes bias the environment, body-level attributes declare route intent, region and component attributes specialize local behavior, and slot or variant choices should carry the rest. If a concern needs permanent room in the anatomy, it belongs in the component contract. If it does not, it should stay opt-in.
Pretext feels most promising here as a selector for rendering posture and component variants, not as a bag of decorative badges. The cards below use real site attributes so this page can double as a manual rendering-context lab while the design model gets sharper.
Trails Through The Feature Set
The hub should shorten coordination time. Each circuit below is a different kind of design question, not just another content category.
Website Field Guide
The public rationale for readable HTML, inspectable frames, route-aware thresholds, and why this site acts like a publishing surface instead of a template portfolio.
Site Design
The visual reference shelf: cadence, resonance, palette probes, and examples of how atmosphere can support structure without hiding it.
Pretext Physics
The closest thing to a rendering grammar for text posture, wrap volatility, scaffolds, and inspectable projection behavior.
Renderers
The route for asking how authored structure becomes visible output, and which transforms belong in the renderer instead of living as ad hoc CSS patches.
Settings
The place to test what should remain global: color mode, palette resonance, wonder memory, and other browser-local preferences that change neighboring routes.
Architecture
The route for deciding whether a distinction is durable enough to become a named contract instead of a one-off local fix.
Palettes & Color Grammar
The spectral families, theme handles, and resonant color tests mapped out as a design space.
Component Glossary
The established structural vocabulary of CSS classes and wrappers used across the Spwashi runtime.
Global And Local Display Context
This is the working stack I would use for design decisions. The page also exposes live global controls so the neighboring cards can be tested under real site settings.
Global Context
Bias the environment first, then judge whether the local variants still make sense.
Current mode: auto. Palette resonance: route. Wonder memory: nearby.
Settings are stored locally in this browser.
Layer 1
Global / Root
Use this for environment-wide posture: theme, palette resonance, enhancement level, wonder memory, semantic density, and anything that should feel continuous as a person moves between routes.
html[data-spw-color-mode], html[data-spw-palette-resonance], and the settings model belong here.
Layer 2
Page / Body
Use page-level attributes to say what kind of route this is and how much horizontal structure it deserves. That is where surface family, route family, page modes, and shell layout should live.
data-spw-surface, data-spw-route-family, data-spw-page-role, and data-spw-layout are the main levers.
Layer 3
Region / Component
Use component-level attributes to specialize a local contract. This is the place for context, material, depth, accent, affordance, and whether a frame is acting as orientation, reference, control, or comparison.
data-spw-kind, data-spw-role, data-spw-context, data-spw-metamaterial, and data-spw-depth belong here.
Layer 4
Slot / Variant
Use slots and variants when the anatomy itself changes. A top line, action shelf, figure rail, or pretext variant should be selected because the component is instantiating differently, not because a generic badge has to float above every card forever.
This is the layer where Pretext looks strongest as a renderer selector: let the component instantiate, let context resolve, then let Pretext choose the local projection posture or slot map instead of stapling on another annotation channel.
Rendering Context Tests
These are intentionally small, comparable specimens. They use real attribute families so the question can be “does the contract feel right?” instead of “can we invent a new demo widget?”
reading / paper / stable
Reading Specimen
analysis / glass / responsive
Analysis Specimen
ambient / matte / supportive
Ambient Specimen
signal / field / volatile
Signal Specimen
Component Option Register
A utility to break down how surface options relate to underlying structures. Instead of asking "what should it look like", a design team can ask "what materials and states map to its purpose?"
structural constraints
The Universal Slots
Components expect a standard slot sequence. Reusing semantic slots keeps the DOM inspectable.
- header: Sigil, title, context pills
- meta: Timestamps, provenance, hints
- figure: Primary image or runtime SVG
- body: The prose and readable content
- actions: Operator chips and outbound links
- footer: Reference data and terminal trails
environmental response
Density & Measure
Spacing scales smoothly when driven by density keys rather than generic padding tokens.
- dense: High information per inch
- soft: The default, comfortable breathing room
- roomy: Expansive bounds for hero blocks
- ambient: Fades out horizontal boundaries entirely
rendering physics
Metamaterial Attributes
How the surface responds to the scroll canvas beneath it.
- paper: Opaque, warm, reads as a stationary document
- glass: Translucent blur, feels layered and lightweight
- matte: Flat, low-contrast, stays out of the way
- field: High-contrast, interactive staging environment
interaction language
State & Affordance
How a block communicates what you can do to it before you interact.
- read: Stable layout with no hover lifts
- tune: Contains active form controls or sliders
- inspect: Reacts to hover with more structural hints
- orient: Anchors the page flow
Mobile Interaction Notes
Phones are where the design model gets honest. If a structure only reads on hover, wide screens, or desktop breathing room, it is not yet a stable contract.
Header First
The header should touch the top edge unless a real shell layer needs the space. Decorative or inspectability metadata should not silently reserve vertical room before the primary controls.
Control Contrast
Mode switches and menu toggles need a resting state that still reads as actionable. Relying on low-opacity inactive buttons makes the strip look disabled instead of calm.
Rail Collapse
Side rails should degrade into ordinary document flow on narrow screens. The page should still make sense if the rail becomes “after the article” instead of “beside the article.”
Scroll Context
A subtle section handle or local return anchor can help on long pages, but the context marker should not compete with the header or consume anatomy space that most components do not need.
Questions Worth Asking Before Another Patch Lands
What Is Global?
If a decision should travel across routes, it probably belongs in settings, root data attributes, or shared shell grammar instead of route-local copy or card-specific ornament.
What Is Local?
If the change only clarifies one region, prefer a component or section attribute over a new root flag. Do not escalate a local rendering choice into global state too early.
Do We Need A Variant?
If the anatomy changes, name the variant or slot. If only the emphasis changes, bias the existing contract through context, material, or pretext posture before adding a new component family.
Will It Survive Mobile?
If the answer depends on hover, invisible metadata rows, or width that disappears on phones, the design is still provisional. Test the compact case early and often.
This route should stay useful even when the model changes. The point is not to freeze the design vocabulary. The point is to keep the decisions legible while the vocabulary evolves.