/* * Satoshi — the real brand typeface, self-hosted (redistribution rights * for web use confirmed directly by the site owner before bundling — * CLAUDE.md's "use a system-font fallback until confirmed" boundary no * longer applies as of that confirmation). Only the three weights this * theme's own CSS actually requests are bundled (Regular/Medium/Bold — * grepped every font-weight declaration site-wide first, not guessed): * body copy uses weight 500 (Medium), headings/buttons use 600, which * has no exact Satoshi face and — per the CSS font-matching spec, which * searches upward first for targets above 500 — resolves to the nearest * one actually shipped here, Bold (700). Shipping only 3 of the type * family's 10 weights (raw .otf, ~50KB each — no WOFF2 encoder available * in this environment to shrink them further, flagged as a real, * disclosed gap, not a silent one) keeps this from becoming the * heaviest thing on the page. font-display:swap so real content is * never invisible while these load; the system-font stack stays as the * fallback chain, not removed. */ @font-face{font-family:"Satoshi";src:url("../fonts/Satoshi-Regular.otf") format("opentype");font-weight:400;font-style:normal;font-display:swap} @font-face{font-family:"Satoshi";src:url("../fonts/Satoshi-Medium.otf") format("opentype");font-weight:500;font-style:normal;font-display:swap} @font-face{font-family:"Satoshi";src:url("../fonts/Satoshi-Bold.otf") format("opentype");font-weight:700;font-style:normal;font-display:swap} /* --psg-secondary: confirmed via the Elementor kit's global "Sekundær" system color (post 51, _elementor_page_settings) — #7FA287, same value as --psg-leaf. */ /* Design-system tokens (Phase 0). Brand colors are the real, confirmed Elementor-kit values above — everything below builds on them, none are new brand decisions. */ :root{ --psg-ink:#242424;--psg-copy:#767676;--psg-forest:#3f7a5c;--psg-forest-dark:#2f5f47;--psg-leaf:#7fa287;--psg-sand:#eef1ef;--psg-paper:#fff;--psg-page:#f5f7f8;--psg-line:#dfe4df;--psg-secondary:var(--psg-leaf); --psg-error:#b3261e;--psg-success:var(--psg-forest); --psg-radius-sm:6px;--psg-radius:10px;--psg-radius-lg:18px;--psg-pill:35px;--psg-shell:1320px; --psg-shadow-sm:0 2px 10px rgba(20,35,26,.06);--psg-shadow:0 10px 30px rgba(20,35,26,.08);--psg-shadow-lg:0 24px 60px rgba(20,35,26,.14); --psg-space-1:.25rem;--psg-space-2:.5rem;--psg-space-3:.75rem;--psg-space-4:1rem;--psg-space-5:1.5rem;--psg-space-6:2rem;--psg-space-7:3rem;--psg-space-8:4.5rem; --psg-font:"Satoshi",-apple-system,BlinkMacSystemFont,"Segoe UI",Arial,sans-serif; --psg-ease:cubic-bezier(.4,0,.2,1); } *{box-sizing:border-box}html{scroll-behavior:smooth} /* * Round 166 — direct report: rapid taps anywhere (explicitly called out: * spamming a product's quantity +/- stepper) make the page zoom in. Real * cause: mobile browsers' native "double-tap to zoom" gesture, which * fires whenever two taps land close together in time and position — * exactly what a fast-repeated tap on a small stepper button is. `touch- * action` isn't inherited (confirmed against spec: initial `auto`, * `Inherited: no`), so this has to sit on the universal selector, same * as `box-sizing` just above, not just `html`/`body`, to reach every * element reliably. `manipulation` is the correct value for "kill this * gesture, keep everything else": per spec it still allows panning AND * pinch-zoom, only removing double-tap-zoom and the ~300ms click-delay * browsers otherwise wait to see if a second tap is coming — this is * NOT the accessibility-harmful `user-scalable=no`/`maximum-scale=1` * viewport-meta approach (which disables pinch-zoom entirely and was * deliberately never used on this site, header.php's own viewport tag is * untouched) — pinch-to-zoom keeps working everywhere. */ *{touch-action:manipulation} /* * Universal overflow guard, added after several real mobile-overflow * reports (a checkout field label was one specific cause, fixed at the * source in checkout.css, but this class of bug — some element ending * up wider than the viewport and forcing the whole page to scroll * horizontally — has shown up in more than one place). overflow-x:hidden * on body is the actual backstop: it clips any descendant that would * otherwise force horizontal scroll, regardless of which element or page * is responsible, without needing to find and fix every individual cause * first. Deliberately only on body, not html: html is the true root * scrolling element in most browsers, and position:sticky (used by the * checkout order-summary card) stops working correctly for any * descendant of an ancestor whose overflow is anything but visible on * both axes — body{overflow-x:hidden} is a widely-used pattern that * doesn't trigger that in practice, since body doesn't become a distinct * scroll container from the page's own scrolling; setting it on html too * would carry more of that risk for no real benefit. overflow-wrap on * body catches long unbroken text (a long word, a URL, a long option * label) doing the same thing. img's own max-width:100% is extended to * the other common wide-media elements that can overflow the same way. */ /* * overflow-x is declared TWICE on purpose, and the second one is the fix for a * bug that took two rounds to understand. * * `overflow-x:hidden` makes an element a scroll container on BOTH axes — the * other axis resolves from `visible` to `auto`. A body that is a scroll * container is not propagated to the viewport, so on mobile the page scrolled * inside the body box rather than the viewport, and every * `body.{overflow:hidden}` lock in this theme governed a box that was * not the one scrolling. Working around that by locking the root instead * (`html{overflow:hidden}`) stopped the scrolling but changed which element * scrolls while an overlay was open, which is what broke the search sheet * against the sticky header. * * `overflow-x:clip` clips without creating a scroll container, so overflow-y * stays `visible`, the body propagates to the viewport as normal, and * `overflow:hidden` on the body then locks the viewport the ordinary way — * same scroller, same offset, nothing moves. The `hidden` line above it is the * fallback for browsers without `clip` (pre-16 Safari), which get exactly the * behaviour they had before. */ body{margin:0;overflow-x:hidden;overflow-x:clip;overflow-wrap:break-word;color:var(--psg-copy);background:var(--psg-page);font:500 16px/1.6 var(--psg-font)} body.psg-drawer-open{overflow:hidden} img,svg,video,iframe,table{max-width:100%} img{height:auto} a{color:var(--psg-forest);text-underline-offset:.18em}a:hover{color:var(--psg-forest-dark)} /* * Full-width shell with edge padding only — no max-width cap. Previously * capped at var(--psg-shell) (1320px, before that 1660px), which read as * a narrow boxed layout on any monitor wider than that instead of a * genuinely full-width site. --psg-shell itself is kept (still used as * a max-width for the rarely-rendered wc-block-cart/checkout markup in * woocommerce.css) but no longer constrains .psg-shell itself. */ .psg-shell{width:calc(100% - 3rem);margin-inline:auto} .site-main{min-height:50vh}.psg-content{padding-block:clamp(2rem,5vw,5rem)}.screen-reader-text{position:absolute!important;width:1px;height:1px;padding:0;margin:-1px;overflow:hidden;clip:rect(0,0,0,0);white-space:nowrap;border:0}.screen-reader-text:focus{position:fixed!important;top:1rem;left:1rem;width:auto;height:auto;padding:.75rem 1rem;background:#fff;color:#000;clip:auto;z-index:100000}:focus-visible{outline:3px solid var(--psg-leaf);outline-offset:3px;border-radius:2px} /* * Round 166 — direct report: clicking/tapping certain icons leaves the * green focus ring showing and it never goes away; it should never * appear at all for a pointer interaction (fields being typed into keep * their own indicator, which is a different mechanism entirely — see * base.css's own `.woocommerce input.input-text:focus` rule further * down: that one already sets `outline:none` and shows state via * background/border-color/box-shadow instead, so it is untouched by * anything here). * * `:focus-visible` (the rule directly above) is SUPPOSED to handle this * on its own — browsers are meant to match it only for keyboard focus, * never for a mouse/touch activation. In practice that heuristic is a * real, well-known cross-browser inconsistency, not a bug in this site's * markup: WebKit in particular has long matched `:focus-visible` on a * plain tap of a real `