Design / Runtime / Browser Behavior
Runtime behavior should be inspectable before it becomes configurable.
This page is for learning how browser behavior is tuned: URL parameters declare temporary disposition, console helpers inspect the result, and data attributes explain why a surface may reflow.
Performance puppetry
For live use, runtime behavior can become puppetry: query strings set the stage, scripts pull named strings, CSS changes disposition, SVG art carries visible figures, and logs narrate which controller moved which surface.
const puppet = spwCompose.logger('stage-puppet', {
role: 'performance-controller',
owns: 'runtime-lab',
metaphor: 'puppet-string'
});
puppet.describe();
puppet.reflow('#runtime-lab', 'interaction', { scope: 'stage' });
SVG art as a controllable surface
SVG belongs in this model because it can be semantic markup, visual art, and a live puppet surface at the same time. Hosts can expose named palettes, brand color overrides, pointer modes, and repaint cost so screenshots remain interpretable by people and image models.
Newer power-user surfaces (observation beats and Screenshot QA Mode via ?qa=screenshot-qa) extend this legibility: short rhythmic capture windows pair what the page looks like with where the reader is, when the capture happened, and which semantic handles were active. Keyboard s or a long-press in QA mode can turn that moment into a cauldron ingredient for later comparison.
import {
applySvgQueryTunability,
SPW_SVG_PALETTES
} from '/public/js/compose.js';
applySvgQueryTunability(document);
console.table(SPW_SVG_PALETTES);
Query tuning links
These links keep behavior visible in the URL so a tester, teammate, or language model can see the configuration without opening storage. The short aliases are meant to be typed from memory; the longer spw-* names remain available for forks that want stricter namespacing. The same presets are also exposed at spwCompose.queryPresets and window.spwDebugPresets.
View and interaction presets
view tunes semantic density, interaction tunes motion and response, and debug reveals ownership. They compose cleanly because they target different layers of the runtime model.
Viewing
Use ?view=quiet, ?view=readable, ?view=inspect, or ?view=screenshot when the question is how much meaning should stay visible.
Interaction
Use ?interaction=calm, ?interaction=tactile, ?interaction=puppet, or ?interaction=screenshot when the question is how physically responsive a surface should feel.
Debug
Use ?debug=css for structure tags, ?debug=layout for ownership overlays, and comma-join them when the question is where a rule belongs.
Bundle handoff
The same query contract travels with the portable bundles, so vendors or teammates can read the URL, inspect the DOM, and know which runtime posture they are seeing.
Memory garden mirror
The cauldron and spell systems expose live lifecycle phases and gardening affordances. Root data attributes (data-spw-cauldron-phase, data-spw-cauldron-count, per-ingredient data-spw-ingredient-phase) plus bus events make the current "garden" of semantic memory observable and lightly tunable in any surface that loads the composition runtime.
Inline tuning: the same [data-spw-cauldron-action="prune|nourish|plant|mix|clear"] buttons that appear in the footer work anywhere. They respect the current garden phase and keep capturedAt / origin context for reflective learning.
The same memory garden and brace physics that appear in the public Library are observable and tunable here. The full composition + cauldron docs live alongside the gentler garden introduction for visitors coming from the fantasy surfaces.
Brace interaction contract
Brace targets need visible consequences in the viewport. The contract is simple: tap inspects, hold primes, drag projects, double-click inspects and primes, and keyboard commit follows the same collection path. This is the same attentive containment described in the Library's living tools disclosure.
Console contract
The portable bundle exposes a deliberate console API. Install it when a lab page needs inspection without mounting the whole site runtime.
import { installSpwCompositionConsole } from '/public/js/compose.js';
installSpwCompositionConsole(window);
spwCompose.query(document.documentElement);
spwCompose.inspect('#runtime-lab');
Namespaced logging
Loggers stay quiet unless debug mode or a namespace query enables them. Each logger can describe its role, metaphor, owned surface, and target snapshot.
?spw-log=spw-compose,spw-core&spw-log-level=debug
const logger = spwCompose.logger('demo-spell', {
role: 'query-lab',
owns: 'runtime-lab'
});
logger.describe();
logger.trace('after query disposition', '#runtime-lab');
Reflow reasons
When behavior can move layout, write the reason and tuning scope. The point is not to prevent reflow; it is to make the cause inspectable.
spwCompose.reflow('#runtime-lab', 'density', {
scope: 'document',
tuning: { density: 'compact' }
});
Resource readiness
The module loader now exposes what it can know before a module mounts: route and selector eligibility, effective timing, inferred module URLs, cache presence, connection posture, and whether a conservative prefetch hint was issued.
spwCompose.controls.modules.discovery()
window.__SPW_SITE__.discoverRuntimeResources()
Prefetch is intentionally selective. It is skipped for offline, data-saver, quiet, and manual postures. Cached/offline state appears as document-level tokens so CSS can calm rendering rather than pretending every context has the same bandwidth.