/* ==================================================================== WCPE INSTRUCTOR STUDIO — BASE + ACCESSIBILITY FLOOR ==================================================================== Cascade layer 2 of 7. Owns region 2 — base reset, typography, and the 65+ accessibility floor. LOAD ORDER IS LOAD-BEARING: tokens -> base -> shell -> stage -> panels -> producer -> responsive This file is #2. Nothing here may depend on a rule that loads later. The numbered region banners below are this file's own. The numbering is one flat sequence 1-22 shared across the seven cascade files and no two files repeat a number; it was inherited from the concept-6 "Studio Rail" mockup the cascade was first extracted from. That mockup is deleted and these banners are the source now. Region map: docs/CODEBASE.html#style-css-regions ==================================================================== */ /* ==================================================================== 2 · BASE RESET + UTILITIES Border-box everywhere; the page itself never scrolls — the app is a fixed viewport and each panel scrolls internally. Controls inherit the 19px base (65+ floor: computed text never below 15px anywhere). Global hover/focus: the hairline border goes cyan plus the canonical glow; focus rings are always-visible 3px cyan equivalents. .sr-only = screen-reader-only text; .svg-sprite parks the icon symbol defs off-canvas without removing them from the DOM. ==================================================================== */ *{box-sizing:border-box} /* item-32 audit: the page-never-scrolls premise. Legitimate only because every interior region scrolls or grows (the shell layout-clip family, shell.css §3); the booking page and the ≤240px band each release their layer of it. */ html,body{width:100%;height:100%;margin:0;overflow:hidden;background:var(--void)} /* ==================================================================== THE TYPEFACE, AND WHY IT IS THIS ONE ==================================================================== Instructors are 65+ and many have low vision, and the size is FIXED at 17px — so the only lever left is the face's own x-height, which is what "how big does this look" actually means. Measured in Chromium at 100em (x-height as a share of em, and a real product sentence's width): Arial (was) 0.5186 baseline Tahoma 0.5454 +5.2% apparent size, 1% NARROWER Verdana 0.5454 +5.2% apparent size, but +13% WIDER Atkinson Hyperlegible 0.4960 -4.4% — SMALLER at 17px, despite the name Inter / system-ui ~0.516 no gain So Tahoma reads about 5% larger than Arial at the same 17px, and sets no wider — Verdana's legibility without Verdana's width. It also fixes a real ambiguity Arial has: Arial's cap I and lowercase l are the same bare stroke, and this product puts session IDs and device strings in body text. Tahoma serifs the I (0.282em vs a 0.092em l). ATKINSON HYPERLEGIBLE WAS REJECTED ON THE NUMBERS, not on taste. It is the best face here for telling glyphs apart, and it is the WRONG choice under a fixed size: its x-height is 4.4% smaller than Arial's, so every surface would render visibly smaller. Its own foundation publishes no legibility study; the one "accessibility font" that was trialled, OpenDyslexic, measured WORSE than Arial (Wery & Diliberto 2017). Luciole has real peer-reviewed work behind it, but its measured advantage is over OpenDyslexic and Eido rather than Arial, its cohort was aged 6-35, and it sets 13% wider. No standards body — WCAG 2.2, the W3C low-vision note, Section 508 — names a typeface at all. THE OVERRIDES BELOW ARE LOAD-BEARING, NOT DECORATION. Tahoma's own vertical box is 8% taller than Arial's (hhea ascent 100.05% of em against Arial's 90.53%), and this app's 200%-text-zoom tiers are tuned to Arial's compact box: unpinned, the swap put the slide-nav under the stage header and pushed the session h1's first line 2-4px above its own scrollport. Pinning ascent/descent/line-gap to ARIAL'S EXACT RATIOS keeps every line box, every em-derived cap and every zoom tier measuring what it measured before, while the glyphs inside them are Tahoma's larger ones. This is the whole reason the change is layout-neutral rather than a re-tune. WHERE TAHOMA IS ABSENT THE ANSWER IS ARIAL, NOT "the next nice face". An earlier cut of this put Roboto and Noto Sans ahead of Arial for Android and Linux, which quietly broke the promise this whole change rests on: Noto Sans is 6.5% WIDER than Arial with a vertical box 21% taller, i.e. precisely the two metrics the overrides above exist to hold still, and every Linux machine — including the CI runner, which has no Tahoma — would have rendered on an unpinned wider face instead of on today's. The fallbacks are Arial and Helvetica in the FAMILY LIST — i.e. the exact declaration this file carried before the typeface commit — and the face's own src names ONLY Tahoma and Arial. NAMING Liberation Sans HERE WAS TRIED AND CI REJECTED IT, which is worth keeping: on a Linux runner that face DOES resolve, so the Arial vertical overrides above were applied to a substituted face whose native metrics are not Arial's, and rendering moved — "unreachable control Previous/Next at 200%" in producer-shell and a truncated chat placeholder in room-flow, both on run 31037734901. With only Tahoma and Arial named, the face does not resolve on Linux at all, the family list takes over untouched, and a machine without Tahoma renders exactly what it rendered before. The override is a correction to TAHOMA's metrics and must never be handed to a face whose metrics were not measured. Verdana is deliberately ABSENT for the same reason: same x-height, 13% wider. */ @font-face{ font-family:"Studio Sans"; src:local("Tahoma"),local("Arial"); font-weight:400; ascent-override:90.53%; descent-override:21.19%; line-gap-override:3.27%; } /* AND THE BOLD IS ARIAL'S, DELIBERATELY — this is the load-bearing half. macOS Tahoma ships Regular and Bold only, so any weight above 400 renders as Tahoma Bold, and TAHOMA'S BOLD DOES NOT FOLLOW ITS REGULAR. Measured at 30px, which is what 200% text zoom makes of this product's 15px labels: word Tahoma regular vs Arial Tahoma 900 vs Arial Previous -4.7% +2.7% Next -1.6% +10.0% Transcript -2.4% +5.7% Drop marker -0.2% +6.7% Every box this project measured to the pixel is a heavy label in a tight tier — the compact tabs, the slide nav, the transport, the instructor accordion's step names. Widening those 3-10% takes labels out of their columns, shrinks the stage cell until the 16:9 visual no longer fits, and wrapped a 78-character deck name far enough to push a pressed accordion step off screen (session-paths.mjs went 109/0 to 107/2 on exactly that). Mapping the heavy weights to ARIAL'S OWN BOLD fixes the whole class at the declaration instead of chasing it selector by selector — a context nobody tested cannot regress, because there is no Tahoma bold anywhere to regress into. The gain is kept where it is actually read: prose is regular weight, and regular is where Tahoma is both larger-looking and no wider. */ @font-face{ font-family:"Studio Sans"; src:local("Arial Bold"),local("Arial-BoldMT"),local("Arial"); font-weight:500 900; ascent-override:90.53%; descent-override:21.19%; line-gap-override:3.27%; } /* 19px/1.5, Tor's ruling of 2026-08-10 after a before/after screenshot review: the audience is instructors aged 65+, the larger default wraps the booking slot times whole instead of mid-phrase, and 1.5 is the line spacing WCAG's text-spacing criterion assumes users can apply. Text that inherits its SIZE moves: the 228 explicit px sizes across the CSS (stage included) keep their designed values, exactly as in the approved screenshots. The unitless line-height reaches FURTHER — a px-pinned descendant with no pinned line-height still gets the taller rhythm (the knock card's 16px strong proved it; see panels.css) — and harmonising the pinned sizes with the new default is its own slice. Was 17px/1.35. */ body{min-width:320px;color:var(--text);font:19px/1.5 "Studio Sans",Tahoma,Arial,Helvetica,sans-serif} button,input,select,textarea{font:inherit} button,select,textarea,input{color:var(--text)} button{cursor:pointer} button:disabled{cursor:not-allowed;opacity:.62} button,select,textarea{border:1px solid var(--line);background:var(--raised)} button:hover,select:hover,textarea:hover{border-color:var(--cyan);box-shadow:var(--glow)} button:focus-visible,select:focus-visible,textarea:focus-visible,input:focus-visible{ outline:3px solid var(--cyan); outline-offset:3px; box-shadow:var(--glow); } [hidden]{display:none!important} svg{display:block} .svg-sprite{position:absolute;width:0;height:0;overflow:hidden} .sr-only{position:absolute;width:1px;height:1px;padding:0;margin:-1px;overflow:hidden;clip-path:inset(50%);white-space:nowrap;border:0} /* Not a mockup class — the contract core/dom.js's row builders stamp on any element carrying user or server text (filenames, chat bodies, transcript segments, mark notes). Per the long-token policy (docs/CODEBASE.html#style-long-token-policy), "no truncation" and "no mid-word wrap" cannot both hold for an unbreakable 90-character filename at 200% zoom: anywhere breaks only strings with no legal break point, word-break:normal keeps ordinary prose intact, and nothing is ever ellipsised. The per-component rules in panels.css/producer.css say the same thing for the mockup's own classes; this makes it true for dynamically built rows too, which are the surfaces the frozen mockup never rendered with real data. */ .user-text{overflow-wrap:anywhere;word-break:normal}