section
#>design
structural vocabulary live specimens direct wiring

A component is a small machine for arranging attention.

Objective terminal: named slots, kinds, and layout contracts that stay inspectable in HTML. Subjective terminal: specimens you can touch, compare, and carry back into a real route.

Tune density above, then open the ?hook anatomy frame when nested entry peaks need a clearer contract.

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.

Change a setting, inspect the slot order, then carry the result back to the design hub, the blog laboratory, recipes, or about.

This surface exists because

the site needs a shared vocabulary for routes, cards, chips, wrappers, and the reasons they exist.

Use this when

you need to compare a specimen, inspect its slots, or decide whether a pattern should become reusable.

What it can produce

component grammar, onboarding references, design notes, and patterns that can travel back into public pages.

tune specimens more
Mise component

Declare the ingredients before the performance: header, meta, body, figure, actions, footer. A component becomes teachable when its station is visible.

slots -> setup
Soup component

Use soup logic when a component gathers many inputs: stock for inherited context, simmer for integration, garnish for emphasis, bowl for release.

inputs -> surface
Reduction component

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
Emulsion component

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
Ferment component

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
A threshold-like corridor image with pale paper walls, teal seams, and luminous structural depth.
Threshold corridor Good component work should feel like a route becoming clearer: the spacing, slots, and operator cues start telling you what kind of move the page wants next.
#>design_hub Return to the design hub Use the glossary to learn the parts, then go back to the atlas where those parts get arranged into whole routes and promptable surfaces.
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.

*playtest_surface Stress-test the parts in play RPG Wednesday is where cards, chips, prompts, capture frames, and read-aloud hooks have to read quickly enough for real people and screen-reading agents to use them without a guided tour.
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.

$support_register Back the work directly If this vocabulary is useful for your team, classroom, or production process, use the support register to turn that resonance into sustained time.
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.

@designer_dm DM about a component If you want to help shape RPG Wednesday capture lanes, SVG handoff hosts, promptable image routes, or component onboarding for curious designers, send a short note through contact with the route and the exact surface you want to touch.
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-heading and .frame-topline composition.

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.

Sample affordance

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.

@ learning demos * recipe demos ^ design demos

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.

inspect ownership see design circuits

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_disclosure_sponsor"

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.

#>dense_card High-density reference card Minimal enough for mobile, but still able to carry title, status, badges, and one useful sentence.
compact screen-readable fast scan
sponsor banner slot Quiet support lane

Useful for affiliate links, sponsorships, or a clearly marked supporter module that should feel native to the page instead of bolted on.

@ sponsor inquiry
sponsor popup shell Popover-sized support surface

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"

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.

#>
live specimen topline 
<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.

^"heading_slot"

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.

#>"this_section"    ?"probe_section"    ^"object_section"

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.

?"hook_region"

Hook Region Anatomy

A hook is a nested entry peak inside a frame body — more volatile than the stable hero, more interactive than a playable line alone. It participates in page locomotion even when it lives inside .frame-body.

A hook is a small machine for threshold attention: it names the invitation, carries the operator, and hands off to deeper prose.

Objective terminal: declare data-spw-kind="hook" plus role, variant, operator, and gesture contract. Subjective terminal: the reader should feel invited to relate, prime, and move — not only read past the top of the page.

Nested hooks surface in the section handle as data-spw-section-tier="hook". Compare with the live hook on about and the design hub.

authored contract

Kind + role

Use data-spw-kind="hook" with data-spw-role="call|invocation|gate". Runtime mirrors to data-spw-component-kind so CSS and JS can share one vocabulary.

<section data-spw-kind="hook"
  data-spw-role="call"
  data-spw-hook-variant="wonder"
  data-spw-operator="probe"
  data-spw-gesture-contract="tap:prime hold:inspect"
  aria-label="...">

placement

Nested inside frame-body

Place the hook as the first interactive threshold inside .frame-body or directly under .frame-topline when the frame has no body wrapper. Avoid treating dismissable floating chrome as hook content.

locomotion

Section handle participation

Nested hooks are collected by HOOK_REGION_SELECTOR and receive tiered locomotion state. Prev/next labels use the hook's aria-label or inner heading when present.

inspect locomotion

#>"chips_strips"

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.

structural vocabulary blocks 
<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.

design build ship

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.

2026-04 draft ~reference

^"metamaterial_states"

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

Glass

Translucent with backdrop-filter: blur. Default interactive surface. Implies legibility over background content.

data-spw-metamaterial="glass"
#>
paper

Paper

Warm opaque surface. Signals a reading posture — settled, uninterrupted. No blur, no transparency.

data-spw-metamaterial="paper"
#>
matte

Matte

Flat, structural. Used for reference grids and documentation panels. Reduced shadow and border emphasis.

data-spw-metamaterial="matte"
#>
field

Field

High-contrast bounded zone for active widgets, inputs, and tunable controls. Visible boundary, ready to react.

data-spw-metamaterial="field"
~"inline_annotations"

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.

This is a live .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.

This is an .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 padding
data-spw-spacing="loose" — generous padding
@ "interactive_physics_lab"

Live 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.

#> active specimen

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"

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
^"component_anatomy_slots"

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.

#> header / topline slot

Component Body Slot

The primary content area for prose, data, or media controls. It handles text-wrap and local density.

figure / media slot
actions / footer slot
  1. Header: Navigation, sigils, and mode switches.
  2. Meta: Contextual pills, timestamps, or status hints.
  3. Body: The core legible content.
  4. Figure: Images, SVG diagrams, or canvases.
  5. Actions: Primary interaction chips or commit handles.
  6. Footer: Secondary metadata or citation links.
#>"component_recipes_capture"

Copy a recipe, then capture the evidence

These small recipes preserve the slot order and portable CSS boundary without copying the full site shell. Start with the live HTML, adapt its labels and responsibility, then compare it at phone and desktop widths.

#>site_frame section recipe

Start a section with named slots

Use the site-frame recipe for a durable page section with a heading, body, and explicit next action.

Copy frame markup 
<!-- Minimal site-frame specimen: retain slots and semantic state when copying. -->
<section class="site-frame" data-spw-kind="frame" data-spw-role="reference">
  <header class="frame-heading" data-spw-slot="header">
    <span class="frame-sigil">#&gt;frame</span>
    <h2>Component title</h2>
    <span class="spw-component-tag" data-spw-slot="meta">reference</span>
  </header>
  <div class="frame-body" data-spw-slot="body">
    <p>One clear idea, with enough context to decide the next move.</p>
  </div>
  <footer class="frame-actions" data-spw-slot="actions">
    <a class="operator-chip" href="#next" data-spw-operator="action">! next move</a>
  </footer>
</section>
~frame_card card recipe

Keep one portable thought together

Use the frame-card recipe for a compact reference, comparison, offer, or artifact that still explains why it exists.

Copy card markup 
<!-- Minimal frame-card specimen: use for a compact route, artifact, or comparison. -->
<article class="frame-card" data-spw-kind="card" data-spw-role="reference">
  <span class="frame-card-sigil" data-spw-slot="meta">~reference</span>
  <h3 data-spw-slot="header">Card title</h3>
  <p data-spw-slot="body">A short reason this card exists and what it offers.</p>
  <a class="operator-chip" href="#detail" data-spw-slot="actions" data-spw-operator="frame">#&gt; inspect</a>
</article>
!tuning_strip control recipe

Group a few related moves

The portable strip is a wrapping row. Its links work before enhancement; a host can later replace them with real controls when state is necessary.

Copy strip markup 
<!-- Minimal tuning-strip specimen: static links work before optional stateful enhancement. -->
<nav class="tuning-strip" aria-label="Choose a component view" data-spw-kind="panel" data-spw-role="navigation">
  <a class="operator-chip" href="#overview" data-spw-operator="frame" aria-current="location" data-site-setting-active="true">#&gt; overview</a>
  <a class="operator-chip" href="#compare" data-spw-operator="probe">? compare</a>
  <a class="operator-chip" href="#apply" data-spw-operator="action">! apply</a>
</nav>
^capture_evidence review path

Review context, component, and template

Page captures show the surrounding route, component captures isolate packing, and template captures verify that a snippet still works with the portable composition bundle.

Run npm run component:screenshots -- --base <preview-url> for a local review pack. Capture packs are evidence, not permanent pixel baselines; keep a baseline only when a repeatable visual regression makes it useful.

#>"markup_model_kit"

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.

@specimen_builder_rail

Build a specimen from the component contract

A specimen is not a finished component yet. It is a named trial with slots, state, visible behavior, layout posture, and a clear next surface. Start with the living specimen on the design hub, watch how it packs, reflows, and settles, then choose a builder based on what kind of artifact should carry the state forward.

~living_component Tune the living specimen Open the message-surface lab in an inspectable collected atlas state, then copy the Spw expression or state link. ^character_card Create a character card Use when the specimen needs identity, badge logic, RPG hooks, and a readable card anatomy. ^profile_specimen Create a profile specimen Use when the specimen should become a person, project, or style packet with reusable context. ^proof_card Keep a proof card Use when the specimen needs to become a local record, ask, offer, pledge, or screenshot-ready artifact. ~prompt_packet Create a prompt packet Use when material behavior, palette, light, and identity should travel into generated image studies. ^svg_specimen Build an SVG specimen Use when the component needs named nodes, screenshot resilience, and image-model-readable labels.
^"brace_grammar_specimens"

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 form

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 form

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_decoration"

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">

Example 4: Kind mirror contract

Author with data-spw-kind when possible. Runtime backfills data-spw-component-kind through syncComponentKindMirrors() so route markers, metamaterial, haptics, and semantic tag colors stay aligned before and after hydration.

<article class="frame-card"
  data-spw-kind="card"
  data-spw-role="artifact">
  <!-- resolves to matching data-spw-component-kind -->
</article>

Page shells (body, main) are excluded from kind-mirror selectors so route markers do not attach to the whole page.