/** * Silvalue — base.css * * Small, dependency-free stylesheet for behaviour that theme.json cannot * express on its own: visible keyboard focus on *every* focusable element * (not just the core link/button block elements), a skip-link utility class, * and a global `prefers-reduced-motion` safety net. Colour, type and spacing * values stay tokens (WordPress preset custom properties) — no hex codes. * * Loaded after style.css, see functions.php. */ /* --------------------------------------------------------------------- * Visible keyboard focus * 2px outline + 2px offset, never `outline: none`. Applies to links, * buttons, form fields and anything else that can receive focus. * `:focus-visible` avoids showing the ring on mouse clicks while still * falling back for browsers without support. * * Colour: `sv-accent` (2.48:1 on sv-paper, 2.78:1 on sv-white) does not * clear the 3:1 WCAG non-text-contrast minimum on the light default * background, so the outline uses `sv-ink` there instead (well over * 3:1 on both sv-paper and sv-white). On the dark contrast-island * sections (hero, approach, footer — background set to `sv-ink` via * the block editor colour picker), WordPress automatically adds a * `has-sv-ink-background-color` class to that block; the override * below swaps the outline to `sv-white` (17.69:1 on sv-ink) so focus * stays visible there too. Future patterns do not need to add any * extra class for this to work — only use the `sv-ink` background * colour from the palette as the plan already requires. * ------------------------------------------------------------------- */ a:focus, button:focus, input:focus, select:focus, textarea:focus, summary:focus, [tabindex]:focus { outline: 2px solid var(--wp--preset--color--sv-ink); outline-offset: 2px; } a:focus:not(:focus-visible), button:focus:not(:focus-visible), input:focus:not(:focus-visible), select:focus:not(:focus-visible), textarea:focus:not(:focus-visible), summary:focus:not(:focus-visible), [tabindex]:focus:not(:focus-visible) { outline: none; } a:focus-visible, button:focus-visible, input:focus-visible, select:focus-visible, textarea:focus-visible, summary:focus-visible, [tabindex]:focus-visible { outline: 2px solid var(--wp--preset--color--sv-ink); outline-offset: 2px; } .has-sv-ink-background-color a:focus-visible, .has-sv-ink-background-color button:focus-visible, .has-sv-ink-background-color input:focus-visible, .has-sv-ink-background-color select:focus-visible, .has-sv-ink-background-color textarea:focus-visible, .has-sv-ink-background-color summary:focus-visible, .has-sv-ink-background-color [tabindex]:focus-visible { outline-color: var(--wp--preset--color--sv-white); } /* --------------------------------------------------------------------- * Dark contrast-island typography (heading / body text / link colour) * * theme.json sets the global default heading colour (sv-ink) and link * colour (sv-text / sv-ink on hover+focus) for the light default * background. Those defaults are unreadable on the dark contrast-island * sections (hero, approach, footer — background set to sv-ink via the * block editor colour picker), which is why WordPress core wraps its * own theme.json colour output for elements in `:where()`: zero * specificity, so the block-level colour a pattern author can still * pick from the editor always wins without needing `!important`. * * Same `has-sv-ink-background-color` class as the focus-ring fix above. * Originally this also wrapped `.has-sv-ink-background-color` itself in * `:where()`, on the assumption that a bare element selector (h1, p, * a, …) would already be enough to beat theme.json's zero-specificity * default while staying weak enough to lose to an explicit * `has--color` class an author sets on that exact heading/ * paragraph/link in the block editor. * * Hardening note (2026-08-23): that assumption was wrong — it only * happened to work while base.css loads after `global-styles-inline-css` * in ; it was never actually winning on specificity. Confirmed * empirically against the live global-styles-inline-css output on * silvalue-nz.local: * WordPress's own heading-colour rule is a bare, unwrapped element list, * `h1, h2, h3, h4, h5, h6{color: var(--wp--preset--color--sv-ink);...}` * — specificity 0-0-1 (only the element counts; comma-separated * selectors do not add up). Its base link-colour rule is * `a:where(:not(.wp-element-button)){color: var(--wp--preset--color--sv-text);...}` * — the `:where()` wrapper reduces the whole `:not()` clause to zero, * leaving 0-0-1 as well. `:where(.has-sv-ink-background-color) h1` etc. * above is *also* 0-0-1 (the `:where()` wrapper here contributes * nothing either) — a tie with both core rules, decided only by load * order, exactly the bug class already fixed once in header.css for * the mobile market-switch link. * * Fixed the same way: keep `.has-sv-ink-background-color` a plain, * unwrapped class (adds 0-1-0) while leaving the element itself bare — * `.has-sv-ink-background-color h1` etc. and `.has-sv-ink-background-color a` * are now 0-1-1, which beats both core defaults (0-0-1) outright, no * load-order dependency. * * That raises a second question the plan above already anticipated: does * 0-1-1 also beat an author's own explicit colour choice from the block * editor? Confirmed empirically: core prints that choice as * `.has-sv-ink-color{color: var(--wp--preset--color--sv-ink) !important;}` * (one class, 0-1-0, but with `!important`) directly on the heading/ * paragraph/link element. Because our rule here carries no `!important`, * the author's rule wins regardless of the specificity comparison — an * `!important` declaration always beats a normal one, independent of * specificity. So the two cases resolve cleanly with one selector: wins * against the unwrapped, non-important core default (0-1-1 > 0-0-1), * loses against an author's explicit, `!important` colour choice * (any specificity loses to `!important` as long as we do not add it * here too) — no selector had to be sacrificed for the other. * ------------------------------------------------------------------- */ .has-sv-ink-background-color h1, .has-sv-ink-background-color h2, .has-sv-ink-background-color h3, .has-sv-ink-background-color h4, .has-sv-ink-background-color h5, .has-sv-ink-background-color h6, .has-sv-ink-background-color p, .has-sv-ink-background-color li, .has-sv-ink-background-color dt, .has-sv-ink-background-color dd, .has-sv-ink-background-color blockquote, .has-sv-ink-background-color figcaption { color: var(--wp--preset--color--sv-white); } /* `:not(.wp-element-button)` added 2026-08-30, matching the same exclusion theme.json's own "link" element style already uses (`a:where(:not(.wp-element-button))`): without it, this unwrapped, 0-1-1 rule beat the button element style's `:where()`-wrapped (zero specificity) color/text-decoration on any button placed inside a sv-ink section (e.g. the Hero's primary button) — confirmed at the rendered AT startseite, the button rendered underlined and with white instead of its intended sv-ink text. Buttons keep their own contrast handling (theme.json styles.elements.button) regardless of the section's background colour. */ .has-sv-ink-background-color a:not(.wp-element-button) { color: var(--wp--preset--color--sv-white); text-decoration: underline; } :where(.has-sv-ink-background-color) a:not(.wp-element-button):hover, :where(.has-sv-ink-background-color) a:not(.wp-element-button):focus { color: var(--wp--preset--color--sv-accent); } /* --------------------------------------------------------------------- * Skip link * The visible header/navigation pattern (built in a later step) is * expected to place `