/* SHARED PIECE-BODY RULES — the ONE definition of what a placed piece looks like undressed (before
   any per-instance override). Both the builder canvas (editor.css @imports this) and the live served
   page (build_site links this directly, factory.py) load this exact file, so a change here reaches
   every surface at once instead of drifting into two hand-typed copies.

   Moved out of editor.css on 2026-08-15: editor.css is the BUILDER's own stylesheet (panels, trays,
   drag handles, #settings, .tab, ...) and must never reach a visitor's page wholesale — only these six
   piece-body rules are shared ground between the canvas and the live render. See factory.py's
   build_site() (the served page's <head>) and _fxInplaceStyle (the member in-place editor, which still
   reaches these through editor.css's @import — no change needed there).

   --ink is a BUILDER-only custom property (editor.css's own :root, light+dark). The live served page
   never defines it — verified 2026-08-15 by reading build_site()'s assembled <style> text: its :root
   only carries --accent and --fx-surface. So hr.blk's color-mix falls back to currentColor, which on
   the live page equals the page's own authored ink: options.json's "ink" row paints `color` directly
   on <section class="page">, and `color` inherits — currentColor picks that up with no extra wiring.

   hr.blk sets `color:inherit` for a real reason, not tidiness: browsers' own UA stylesheet gives <hr>
   a default `color:gray` that wins over inheritance whenever nothing else on the element sets `color`
   (a directly-specified value, even from the UA origin, always beats an inherited one). Without this
   line, currentColor inside the color-mix below resolves to that UA gray instead of the page's ink —
   confirmed 2026-08-15 in a clean iframe: dropping var(--ink) to its currentColor fallback rendered
   rgb(128,128,128) even with the ancestor's color explicitly set to something else entirely. */
h2.blk{font-size:26px;font-weight:700;line-height:1.25}
p.blk{white-space:pre-wrap;overflow-wrap:anywhere}
a.blk{display:inline-block;padding:9px 18px;border-radius:9px;background:var(--accent,#3a7d6e);color:#fff;text-decoration:none;font-weight:600}
img.blk,video.blk{width:100%;height:100%;object-fit:contain;border-radius:10px;display:block}
audio.blk{width:100%;display:block}
hr.blk{border:none;color:inherit;border-top:1px solid color-mix(in srgb, var(--ink, currentColor) 30%, transparent);margin-top:12px}

/* WORDS INSIDE A CONTROL ARE STILL THE PIECE'S WORDS (2026-09-08). The six word settings are written by
   cfg_extra() as plain inline CSS on the `.el[data-piece]` box and reach every ordinary element inside it
   by inheritance. They did NOT reach two of them: the Chat Starter's prompt is an <input> and the Group
   Chat's label sits inside a <button>, and the UA stylesheet gives form controls their OWN
   letter-spacing / text-transform / text-shadow / font-style / text-decoration -- a directly-specified
   value, which always beats an inherited one. That is why Italic appeared to work on some controls and
   Letter Spacing, Text Case and Text Glow never did: nothing was broken upstream, the settings were
   arriving and being overruled at the last element.
   One rule, here rather than in either renderer, so both surfaces inherit it and neither piece needs a
   class of its own. Deliberately only the properties the UA resets and the word settings write -- not
   `all:inherit`, which would also drag the control's box, cursor and appearance off it. */
.el input,.el textarea,.el select,.el button{
  letter-spacing:inherit;text-transform:inherit;text-shadow:inherit;
  font-style:inherit;text-decoration:inherit}

/* fx-empty-media — the "no file uploaded yet" placeholder for a media piece (image/video/etc.), moved
   here 2026-08-15 so BOTH renderers emit the exact same markup for the same state: factory.py's
   _empty_media_html() and editor.js's fxEmptyMediaHTML() (shared_client.js) each build one
   `<div class="fx-empty-media">` with no inline styling of their own — this rule is the only place the
   look is defined, so it can never drift between the two independently-implemented renderers again. */
.fx-empty-media{width:100%;height:100%;min-height:70px;box-sizing:border-box;display:flex;align-items:center;justify-content:center;border:1px dashed rgba(255,255,255,.4);border-radius:10px;background:rgba(255,255,255,.05);color:rgba(255,255,255,.62);font-size:12px;text-align:center;padding:10px}

/* THE STYLE GALLERY'S CARDS — Katri's Google Docs ruling: you see the thing set the way it is really
   set, and you change it right there on the specimen. ONE renderer draws these (renderStyleCards,
   shared_client.js) for BOTH the builder's SITE STYLE panel and a member's Display & preferences panel,
   so the look lives in the file both surfaces load rather than in the builder's own stylesheet. The
   builder's tokens (--line/--ink/--dim/--bg/--panel) do not exist on a served page, so every one of them
   carries the live page's value as its fallback — on the builder the token wins and the card is
   unchanged; on a member's page the fallback paints it.

   editor.css still carries an identical `#sitepanel .stcard` block from the owner-only first cut. It is
   byte-for-byte these same values (which is why adding the class to #site-more changes nothing on the
   builder), and it should be DELETED in favor of this block the next time editor.css is opened — it was
   left in place only because that file is carrying unrelated uncommitted work. */
.fxstylecards .stcard{border:1px solid var(--line,rgba(255,255,255,.16));border-radius:10px;padding:10px 11px 4px;margin:0 0 12px;background:var(--bg,rgba(255,255,255,.03))}
.fxstylecards .stcardhd{font-size:12px;font-weight:600;letter-spacing:.3px;color:var(--ink,inherit);margin:0 0 3px}
.fxstylecards .stblurb{font-size:11px;line-height:1.45;color:var(--dim,rgba(255,255,255,.55));margin:0 0 8px}
.fxstylecards .stsubhd{font-size:11px;font-weight:600;color:var(--ink,inherit);margin:10px 0 3px;padding-top:9px;border-top:1px solid var(--line,rgba(255,255,255,.16))}
/* THE SPECIMEN WEARS THE BUILD'S OWN LOOK, not a neutral card (2026-08-23). This carried a hardcoded
   #f4f2ee ground, on the reasoning that neutral let a build's colors "read honestly" -- backwards, and a
   design default invented rather than asked for: the point of the gallery is seeing it as it REALLY is,
   and her builds are dark. NO GROUND IS SET HERE AT ALL NOW, because a build does not have one ground --
   page text stands on the page, a window's trim stands on the window, and painting both on the same
   color is just the same lie pointing the other way. The stage is per card, in style_cards.json's
   `stage`, applied by fxStylePaint; see the _stage_note there. */
.fxstylecards .stspec{border:1px solid var(--line,rgba(255,255,255,.16));border-radius:9px;padding:12px;margin:0 0 9px;
  font:15px/1.5 -apple-system,'Segoe UI',Roboto,sans-serif;overflow:hidden;overflow-wrap:anywhere}
.fxstylecards .stspec [data-part=panel]{background:var(--fx-surface)}
.fxstylecards .stchips{display:flex;gap:6px;flex-wrap:wrap;margin:0 0 9px}
/* A chip on a card is a LABEL, not a placer — nothing here adds a piece. */
.fxstylecards .chip{font:inherit;font-size:13px;padding:8px 12px;border-radius:10px;border:1px solid var(--line,rgba(255,255,255,.16));background:var(--bg,rgba(255,255,255,.05));color:var(--ink,inherit);white-space:nowrap}
.fxstylecards .stchip{font-size:11px;padding:4px 8px;border-radius:8px;cursor:default;pointer-events:none;opacity:.85}
/* At a 280px panel a control row must WRAP rather than push the card wide. */
.fxstylecards .stctl label{margin:0 0 8px;flex-wrap:wrap}
.fxstylecards .stctl label span{flex:1;min-width:0;overflow-wrap:anywhere}
.fxstylecards .stctl input[type=range]{min-width:0}

/* A NAME THAT IS A DOOR (2026-09-08). fxNameEl (shared_client.js) draws every username in the program
   and puts this class on it, so what a door LOOKS like is one rule in a stylesheet rather than an
   inline style repeated at thirteen call sites. It inherits color deliberately: a name sits inside a
   chat bubble, a card head, a circle post and an account panel, and it must read as that surface's
   own text with a door under it — never as a blue link stamped on top of somebody's design. */
.fxname{cursor:pointer;text-decoration:underline;text-decoration-color:color-mix(in srgb, currentColor 35%, transparent);text-underline-offset:2px;text-decoration-thickness:1px}
.fxname:hover{text-decoration-color:currentColor}

/* A SELECT ON A PIECE WEARS THE PROGRAM'S FIELD, NOT THE OPERATING SYSTEM'S (Katri, 2026-09-11, of the
   search bar's "Everywhere" picker: "that dropdown needs to match the rest of the program's UI"). The
   same border, radius, padding and drawn arrow as the builder's own selects (editor.css `.wspanel
   select`), declared here because this is the stylesheet the LIVE page loads -- editor.css never
   reaches a visitor. The builder's tokens do not exist on a served page, so each carries the live
   fallback; on the canvas the token wins. */
.fxsel{font:inherit;font-size:12px;padding:5px 24px 5px 7px;border:1px solid var(--line,rgba(128,128,128,.4));
  border-radius:7px;color:inherit;background-color:var(--fieldbg,transparent);cursor:pointer;
  appearance:none;-webkit-appearance:none;
  background-image:linear-gradient(45deg,transparent 50%,currentColor 50%),
                   linear-gradient(135deg,currentColor 50%,transparent 50%);
  background-position:calc(100% - 14px) calc(50% + 1px),calc(100% - 9px) calc(50% + 1px);
  background-size:5px 5px,5px 5px;background-repeat:no-repeat}
.fxsel option{color:#111;background:#fff}