Component Options / Vocabulary
Component Glossary
This is the page to bumble through when a route feels almost right but the structure is still fuzzy. Every specimen below is here to be touched, compared, re-staged, and wired back into a real page.
A component is a small machine for arranging attention.
Change a setting, inspect the slot order, then carry the result back to the design hub, the blog laboratory, recipes, or about.
the site needs a shared vocabulary for routes, cards, chips, wrappers, and the reasons they exist.
you need to compare a specimen, inspect its slots, or decide whether a pattern should become reusable.
component grammar, onboarding references, design notes, and patterns that can travel back into public pages.
Declare the ingredients before the performance: header, meta, body, figure, actions, footer. A component becomes teachable when its station is visible.
slots -> setup
Use soup logic when a component gathers many inputs: stock for inherited context, simmer for integration, garnish for emphasis, bowl for release.
inputs -> surface
Cut a busy surface until the remaining handles carry the work. Think barbecue sauce, gravy, or chili base: compression should leave stronger affordances, not weaker context.
trim -> signal
Some components bind unlike materials: image plus caption, data plus story, state plus action. Think buffalo sauce, vinaigrette, aioli, or chili crisp: the mediator is the interface contract.
relation -> coherence
A reusable pattern should mature under conditions: repeated use, visible failure, small mutation, and a stable name. Sourdough, pickles, hot sauce, and recurring UI states all need stewardship.
reuse -> culture
If someone is new to Spwashi, this is the safest place to learn the grammar. If someone already knows the grammar, this is where they can tune a surface until it becomes worth testing in a real route, a recorded walkthrough, or a social play loop.
Live specimens of the slot contract in action: the rendered cards from the character sheet builder and profile tool now emit the canonical data-spw-slot attributes (header, meta, body, footer) on their major regions. Open one, inspect the DOM, then come back here or to /design/slots/ to compare against the documented anatomy. This closes the loop between editing, rendering, and component composition.
Component diversity matters. A culture does not form from one card shape repeated forever. It forms when frames, chips, figures, SVG hosts, lists, captions, and control bands each do a different job well enough that people start remembering where to gather and how to move.
CSS should document the HTML, not hide it. A component session begins with the markup: name the slots, identify the states, then tune one visible behavior. Invite, focus, settle, select, disable, reduce motion, compact: each should be readable in the page before it becomes a shared token or selector name.
Treat the session like a chart. The markup sets the structure, the CSS voices the states, and the operator label keeps the action teachable. A sigil works when its mark, plain-language label, state, and destination can still be audited by someone skimming the page.
Topic links can work as metacognitive handles here. If a component problem is really about procedure, open algorithms. If it is about evidence and proof, open statistical analysis. If it is about scope drift, open scale intuition.
Designers curious about RPG Wednesday should treat this page as onboarding. Learn the frame and card grammar here, then inspect the live campaign surface for stress cases like screenshottable capture cards, screen-readable hooks, promptable URLs, SVG cleanup seams, and later JSON or video-wizard handoffs. If you want to help shape those surfaces, the next move after this page is contact.
Culinary technique is also a design-system metaphor. A component needs mise en place before it can be composed, reduction before it can be read quickly, emulsion when unlike materials need one contract, fermentation when repeated use should mature into a pattern, and service when the component meets a real audience.
Concept transfer: emulsion
- recipe
- oil and acid bind through motion without becoming identical
- component
- image, copy, state, and action share one readable card contract
- failure
- one medium dominates until the slots stop teaching the structure
- practice
- compare one recipe card with one mixed-media component before extracting a token
Small reference assignments belong here before they touch flagship routes. Compare a few live specimens, choose one behavior, make one change, and leave a result note. That keeps the experiment teachable: one riff, one take, one reason to keep playing.
- theme
- neutral paper
- mode
- auto
- density
- soft
- metadata
- off
Why this card exists
This card gives the glossary a clean return path so the vocabulary does not become its own dead end.
It helps the reader carry the structure back into a design route with less friction.
Why this card exists
This card exists because play is the harshest practical test of whether a component is actually legible.
It produces the kind of stress feedback that can improve a card, chip, or prompt before it becomes public canon.
Why this card exists
This route exists for readers who want to turn the vocabulary into support rather than just admiration.
It makes the page's usefulness concrete by tying it to a practical next action.
Why this card exists
This card makes collaboration legible when a route needs a small, specific contribution.
It helps a designer or builder name the exact surface they want to improve before starting a conversation.
macro layout wrapper
.site-frame
The primary block-level section element <section class="site-frame">. These define large vertical stopping points down the scroll. They often host id attributes and data-spw-* rendering attributes to bias their local contents.
- Supports
.frame-headingand.frame-toplinecomposition.
primary legible surface
.frame-card
The standard semi-transparent or material card. It usually implies backdrop-filter blur (when acting as glass) or warm opacity (when acting as paper). It serves as an isolated thought space.
sub-surface blocks
.frame-panel
A flatter, more structural tile. Commonly placed inside a .frame-grid to form reference tables or multi-column indices like this one.
the functional unit
.operator-chip
The standard ~chip format for interactions, anchors, state toggles, and metadata hints. Operator chips dynamically adjust color based on `data-spw-operator` syntax (e.g. #> teal frames vs ? violet probes).
discoverability ecology
.spw-demo-rail
A portable row of quick demos for discoverability, QA, grounded resources, and route handoff. Each .spw-demo-card names a reason, exposes a route, and gives the reader a low-pressure way to try or learn from a live surface before contacting, committing, or changing settings.
diagrams & vectors
.spw-svg-figure
The host wrapper for inline SVGs. Contains a scoped viewBox and exposes data attributes necessary to tie the SVG stroke/flow lines to the page's color resonance (e.g. inheriting the --craft-accent token).
the text renderer output
.pretext-flow
A readable annotation surface that handles text posture, wrapping, and cache volatility. Often accompanied by .pretext-flow-lines to split syntax decorators (like `#>` or `%`) from the prose.
grid systems
.frame-grid
The robust CSS Grid layout class that handles most interior spacing. Use variants like .frame-grid--dense or .frame-grid--2up for structural intent, and use data-spw-density="dense|soft|roomy" on the grid itself when the cards need a clearer spacing contract across compact, narrow, and tablet widths.
hero image wrapping
.image-study
Usually combined with .topic-photo-card. Provides a rich frame for surfacing screenshots or artwork, complete with accent palettes, responsive projection hints, and enough caption structure to survive screen reading, image prompting, and later SVG cleanup.
viewport-local affordances
Floating chrome
Skip links, section handles, toasts, non-modal notices, and similar dismissable shells are not card content. They should declare data-spw-floating-chrome="true" and data-spw-layout-owner="floating-chrome" so shared content-lifting rules do not pull them back into host flow.
This is a layout role, not a visual style. A floating affordance can still borrow card material tokens, but its geometry belongs to the viewport or host edge rather than the card body.
card interior anatomy
Slot-bearing content
Cards, frames, panels, and compare shells should spend their anatomy budget on header, meta, body, figure, actions, and footer. Dismissable overlays belong beside that anatomy as overlays or floating chrome, not as anonymous extra children that broad selectors have to guess about later.
The practical test is simple: if removing the element should not collapse the reading order, it probably is not flow content.
Dense Cards, Disclosure, and Sponsor Slots
These are useful when a route needs to stay mobile-legible, keep options collapsible, or host a sponsor/affiliate surface without blowing apart the reading flow.
Bench narrator: what if this route only needs a small expandable menu?
Use disclosure when the page should offer extra links, thinking handles, or supporting context without forcing every reader to pay the full cognitive cost up front.
A compact shell for time-bound offers, event support, or a politely timed ask. The infrastructure should be quiet, dismissible, and explicit about why it is present.
Frame Internals
Every .site-frame or .frame-card is composed from a fixed set of named slots. These are the sub-components available inside any frame-level container.
topline slot
.frame-topline
The compact header row sitting above the heading. Hosts sigils, pills, breadcrumbs, or mode switches. Rendered as a flex row with tight gap.
<div class="frame-topline">
<a class="frame-sigil" href="#id">#>label</a>
<div class="spec-strip">
<span class="spec-pill">pill</span>
</div>
</div>
heading slot
.frame-heading
The primary heading wrapper inside a frame. Contains h1–h3 and an optional sigil anchor. Adds appropriate vertical rhythm and max-width capping.
Section Title
anchor sigil
.frame-sigil
A small monospaced anchor that links to the section's own id. Visually marks the operator prefix (e.g. #>, ^, ?) and gets colored by the operator token system.
contextual annotation
.frame-note
A subdued p-level label used for role clarifiers, context hints, or sub-captions. Renders at a smaller size with reduced opacity.
↑ this text is a live .frame-note specimen
action row slot
.frame-actions
The footer action row for a frame or card. Hosts operator chips and primary commit actions. Sits at the bottom of the card slot order.
operator navigation row
.frame-operators
A horizontal run of operator chips — commonly placed after a section's main content as its navigation footer. Distinct from .frame-actions in that it navigates rather than commits.
identified narrator voice
Narrator specimen
Bench narrator: “This component still wants a clearer job. If it needs three explanations, the slot order is wrong. What if we move the topic link higher and let the note become the spoken hook?”
Some components should read like a person discovering what belongs on the page. That gives dialogue and characterization room to accumulate instead of making every surface sound like neutral documentation.
Chips & Strips
Inline labels, status badges, and horizontal runs of metadata. These are the smallest named vocabulary units.
metadata label
.spec-pill
A small rounded badge used to annotate content type, status, or topic. Used inside .spec-strip for horizontal runs.
reading analysis active
horizontal pill run
.spec-strip
A flex row of spec-pills. Used in toplines, frame headings, and card headers to annotate context without taking layout space.
<div class="spec-strip">
<span class="spec-pill">label</span>
<span class="spec-pill">label</span>
</div>
contextual kicker
.spec-kicker
An all-caps label above the main h1 on hero sections. Sets tone and topic family without competing with the heading hierarchy.
Component Type / Context
action verb strip
.plan-verb-strip
A strip variant focused on action verbs rather than labels. Used on planning and services pages where the reader needs to scan verbs quickly.
inline metadata badge
.meta-chip & .info-chip
Contextual badges for inline use within prose or cards. .meta-chip carries content metadata (dates, counts); .info-chip signals supplemental information.
draft ~reference
Metamaterial States
Any .frame-card or .frame-panel can receive a data-spw-metamaterial attribute to shift its visual posture. These are the four primary states.
Glass
Translucent with backdrop-filter: blur. Default interactive surface. Implies legibility over background content.
data-spw-metamaterial="glass"
Paper
Warm opaque surface. Signals a reading posture — settled, uninterrupted. No blur, no transparency.
data-spw-metamaterial="paper"
Matte
Flat, structural. Used for reference grids and documentation panels. Reduced shadow and border emphasis.
data-spw-metamaterial="matte"
Field
High-contrast bounded zone for active widgets, inputs, and tunable controls. Visible boundary, ready to react.
data-spw-metamaterial="field"
Inline Annotations
Prose-level sidenotes and callouts that don't require a card or panel. These live inside content flow without breaking the reading rhythm.
sidenote
.inline-note
A bordered aside with a ::before marker. Used to highlight caveats, implementation details, or process notes without interrupting the main argument.
.inline-note specimen. It gets a left-border marker and reduced-opacity prose styling. Use for caveats or technical asides.
editorial callout
.inline-note.editorial-note
A variant of .inline-note for editorial voice — opinions, author perspective, or contextual framing. Distinct tone from the neutral sidenote.
.editorial-note. It carries a slightly different visual register to signal that the text is the author's voice, not instructional content.
spacing variants
.inline-note spacing
Both spacing variants control the note's block padding via the data-spw-spacing attribute:
data-spw-spacing="tight" — minimal paddingdata-spw-spacing="loose" — generous paddingLive Composition Playground
This is the most direct-wired surface on the page. Nudge the room, watch the specimen respond, then decide whether the route wants to feel denser, calmer, sharper, or more explicitly inspectable.
- theme
- neutral paper
- density
- soft
- memory
- nearby
- metadata
- off
Scene
Jump to a meaningful room before tweaking local states.
Physical Density
Compact flow versus more breathing room.
Operator Resonance
Decide how loudly related operators should echo.
Material Kind
Treat the specimen as glass, paper, or matte support.
Physics Response Test
This specimen responds to the same settings that shape the rest of the site. The point is not only to see a card move. The point is to judge whether the interaction still means the same thing after the environment changes.
The data-site-setting-set and data-preset attributes let an ordinary button act like a remote handle for the runtime. That keeps the demos declarative enough for later passes to extend without inventing a new widget language.
Operator Intent Registry
Operators are the primary semantic markers in Spw. Each one carries a specific functional intent and a "wonder" category that drives sensory feedback (haptics, sound, and resonance).
| Op | Type | Wonder | Intent |
|---|---|---|---|
| #> | frame | orientation | orient a stable structural unit |
| ^ | object | memory | hold an inspectable structure |
| ? | probe | inquiry | open an investigation or inquiry |
| ~ | ref | resonance | point without forcing structural change |
| @ | action | projection | commit a local change or effect |
| < | topic | resonance | name or relate a conceptual cluster |
| * | stream | resonance | connect to an event-like flow |
Slot-Based Composition
Most Spw components follow a strictly ordered slot contract. This consistency allows the runtime to reliably find sub-elements for animations, metadata projections, and accessibility labels.
Component Body Slot
The primary content area for prose, data, or media controls. It handles text-wrap and local density.
- Header: Navigation, sigils, and mode switches.
- Meta: Contextual pills, timestamps, or status hints.
- Body: The core legible content.
- Figure: Images, SVG diagrams, or canvases.
- Actions: Primary interaction chips or commit handles.
- Footer: Secondary metadata or citation links.
Model the markup, then adapt it
When a human or external model wants to design a new component, the safest starting point is usually an existing Spw specimen. Copy the slot order, keep the same semantic family, and only change the pieces that the new job truly needs.
what to preserve
Canonical structure
Keep header, meta, body, figure, actions, and footer in the same order unless the new component has a different responsibility. Broad selectors and runtime projections already expect that slot rhythm.
what to change
Semantic responsibility
Change the data-spw-kind, data-spw-role, and route-local labels to match the actual job: route sorter, status board, product surface, commercial router, role model, kernel explanation, atlas, evidence shelf, or intake fallback.
what models need
Readable intent
A component should explain itself in the markup. If the purpose is hidden in a stylesheet or script, the surface is harder to reuse, harder to review, and harder for an external model to summarize accurately.
where to inspect
Reference surfaces
Use the runtime design page for query presets and the composition notes for portable bundles. Those pages show the same contracts with a smaller shell around them.
Brace Grammar Forms
The Spw language uses brace delimiters to anchor specific semantic intentions. We project these into HTML using data-spw-form="brace".
Objective braces ^"concept" imply a stable, shared truth or a schema definition. The visual grammar uses a hard vertical rail and a more technical posture.
data-spw-brace="objective"
Subjective braces %"opinion" imply a personal trace, a poetic deviation, or a temporary state. The visual grammar suggests a more fluid, organic connection.
data-spw-brace="subjective"
Data Attribute Distinction
We rarely invent new CSS classes for state or variations. Instead, we stack data-spw-* attributes onto the base components defined above. This makes the surface readable to CSS selectors without bloating the HTML with ad-hoc BEM modifiers.
Example 1: Paper Article
By declaring [data-spw-metamaterial="paper"] and [data-spw-affordance="read"] on a block, the component becomes opaque, warm, and static. It tells the browser (and the reader) to settle in for uninterrupted prose reading rather than active interaction.
<article class="frame-card"
data-spw-metamaterial="paper"
data-spw-context="reading"
data-spw-affordance="read">
Example 2: Inspectable Glass Tool
Using [data-spw-metamaterial="glass"] yields a translucent blur effect. Combined with [data-spw-affordance="inspect"], the block invites hover, ready to reveal contextual traces, metadata borders, or deeper layered hints.
<aside class="frame-card"
data-spw-metamaterial="glass"
data-spw-context="analysis"
data-spw-affordance="inspect">
Example 3: Active Input Field
When an area contains active widgets or tests, tagging it with [data-spw-metamaterial="field"] sets high contrast bounds, while [data-spw-affordance="tune"] prepares the component to visibly react to direct manipulation.
<div class="frame-panel"
data-spw-metamaterial="field"
data-spw-context="signal"
data-spw-affordance="tune">