/* ============================================================================= GLYPH — surfaces/affordance.css · THE ONE HOVER-AFFORDANCE STATE MACHINE ============================================================================= Linked by BOTH served documents that carry controls — `shell.html` and `login-stage.html` — because the 52 `control.hover-delta` FAIL cells of round 3 span both, and a rule that lived in `frame-app.css` could never reach the login stage. Copying it into `login.css` instead would FORK an always-applied rule set across two files that share a design system (PB-00087); this file is the pointer's destination, not a second copy. `frame-app.css` §H now points here. Everything resolves through a brand token: no hex, no rgb(), no named colour, no `!important`, no id selector, max specificity 0,2,0 — TDR-075's seven rules, which is what `css-ratchet` counts. Adding rules that obey them adds ZERO findings, so the 1083 baseline does not move. ── WHY A JS PASS IS INVOLVED AT ALL ────────────────────────────────────────── 🔴 A HOVER RULE WRITTEN IN CSS WAS DEAD ON ARRIVAL ON EVERY R17.1-EXTRACTED CONTROL. The extracted markup carries `background` (and sometimes `border-color`) as an INLINE declaration, and an inline declaration outranks every stylesheet rule in every layer. The only thing that beats it is `!important`, which the ratchet forbids. `core/hover-affordance.js` therefore HOISTS the drawn value into a custom property and stamps `data-glyph-hover=""`; these rules own the state machine from there, so REST still renders the DRAWING's own value and nothing is invented. ── THE KINDS ARE THE REGISTER'S OWN `affordance.hover`, NOT A HOUSE STYLE ───── flat "background transparent -> the raised surface token AND colour muted -> full" (sidebar nav items) — both halves, because the row names both. raised "background delta" on a control the drawing already draws RAISED (session rows, the tab strip, the bell). Lifting those to the raised token would be a NO-OP in exactly the way this machine exists to fix, so the delta goes one step to the accent surface; the accent BORDER stays the selection signal, so hover and selected never collide. ⚠️ RECORDED DEVIATION: `row.session`'s row quotes the INCUMBENT's pair "transparent -> raised". The redesign DRAWS the row raised; inverting the drawn rest to satisfy the quoted pair would restyle the sidebar to fix a hover. The observable the register names — the computed background changes under the pointer — is delivered. text "colour delta only, NO background change" (the DASHBOARDS disclosure, incumbent style.css:703-705). Built as the register declares it. field "border delta" (every text/number/select/textarea control). Round 3 measured `border-color` IDENTICAL hovered and not hovered on 16 cells. link "underline" (`link.forgot-password`, `link.privacy`, `link.terms`, `link.back-to-sign-in`, and every other design-system text link). 🔴 THE REGISTER SAYS THE UNDERLINE IS THE HOVER STATE, so the REST state must not already carry one — three of those four rested `underline` (the UA default) and therefore had no delta to give. Rest is `none` and hover is `underline`; the links stay distinguishable at rest by the accent colour the design gives them, which is the design's own decision. (There is deliberately NO `control` or `row` kind. A design-system button and a list row both carry STATE in their background, and hoisting a rest value freezes it — measured, §4. Those two get plain CSS hover rules instead, which never capture a resting colour and therefore cannot freeze one.) ========================================================================== */ @layer surfaces { /* ── 1 · the R17.1 machine (hoisted rest values) ─────────────────────────── */ [data-glyph-hover] { background: var(--glyph-rest-bg, transparent); } [data-glyph-hover="flat"]:hover, [data-glyph-hover="flat"]:focus-visible { background: var(--color-surface-raised); color: var(--color-text); } [data-glyph-hover="raised"]:hover, [data-glyph-hover="raised"]:focus-visible { background: var(--color-accent-surface); } [data-glyph-hover="text"]:hover, [data-glyph-hover="text"]:focus-visible { color: var(--color-text); } /* ── 2 · fields — "border delta" ────────────────────────────────────────── The rest border-colour comes from `--glyph-rest-bc`, which the JS pass fills from the control's own INLINE `border-color` where it had one (the login password field does) and leaves unset otherwise — so the fallback is the design system's control border, never an invented colour. `promoteSearch` deliberately leaves `border` out of the promoted inline style for the same reason: an inline border-colour cannot be overridden from here either. */ [data-glyph-hover="field"] { border: 1px solid var(--glyph-rest-bc, var(--color-border-control)); border-radius: var(--radius-control); } [data-glyph-hover="field"]:hover, [data-glyph-hover="field"]:focus-visible { border-color: var(--color-accent-border); } /* ── 3 · links — "underline" ─────────────────────────────────────────────── */ [data-glyph-hover="link"] { text-decoration-line: none; } [data-glyph-hover="link"]:hover, [data-glyph-hover="link"]:focus-visible { text-decoration-line: underline; } /* ── 4 · design-system buttons — "background delta", CSS ONLY ───────────── 🔴 NOT A HOISTED REST. A component's background is a fact about its STATE, and capturing it into a variable FREEZES that state: measured on the served preview, an earlier draft of this file pinned `#credentialModal`'s type buttons so the selection moved in `aria-pressed` and the class while the paint stayed on the old button. So these rules add ONLY a hover, never a rest, and the design system keeps writing every resting colour. WHAT WAS ACTUALLY MISSING, measured against `design/export/components.css`: · `.rg-button--danger:hover` changes `filter`, not `background`. `filter` is a real visual change and a real accessibility one — and it is invisible to a computed `background-color` reading, which is what three of round 3's cells (disable-mfa, delete-voice-number, schedule-definition-cancel) were reading. The filter STAYS; a background step is added beside it so the affordance is legible to a reader that cannot see a filter, including a forced-colours mode. · A `.rg-button` with NO variant class has no hover rule at all (ticket-detail's Send is one). It gets the secondary treatment, which is the variant it renders closest to. · The composer's icon AND send controls each HAD a hover rule that `:where()` had reduced to zero specificity, so the resting `background` outranked it — fixed at source in `composer.css`, never duplicated here. · `--color-danger-solid-hover` DOES NOT EXIST in the token set (checked, not assumed). `--color-danger-text` is the design system's LIGHTER danger step and is what `brightness(1.06)` was reaching for, so it is the token the hover uses; `--color-danger-on-solid` stays legible on it. Every selector is a single class plus a pseudo-class: (0,2,0) at most. */ .rg-button--danger:hover, .rg-button--danger:focus-visible { background: var(--color-danger-text); } /* `:not(:where(…))` — the `:where()` is inside the `:not()` ON PURPOSE and it is the opposite of the mistake fixed in `composer.css`. `:not()` still MATCHES exactly the same elements; only its specificity contribution is zeroed, so this lands at (0,2,0) instead of (0,3,0) and still outranks the (0,1,0) base that sets the resting background. Wrapping the whole HOVER in `:where()` is what kills a rule; wrapping the negation inside it is what keeps one under the ceiling. */ /* 🔴 [R4 / R-OV-78 item 11] `--ghost`, GLOBAL. `components.css` DOES ship `.rg-button--ghost:hover { background: var(--color-accent-surface) }`, and round 3 still measured `button.connected-account-scope` identical hovered and not hovered — so the design system's own rule is not reaching these controls. FIX-DESIGN-NEW-R4 proved a rule at THIS layer does reach them, and scoped it to `.dn-screen` because the component is SHELL's; that scoped copy is now DELETED and this is the single definition, so a ghost button hovers the same way on every screen instead of on four of them. `--color-surface-raised` is the token FIX-DESIGN-NEW measured working, kept rather than swapped for the design system's `--color-accent-surface`: changing the colour AND the reach in one move would leave neither measured. */ .rg-button--ghost:hover, .rg-button--ghost:focus-visible { background: var(--color-surface-raised); } .rg-button:not(:where([class*="rg-button--"])):hover, .rg-button:not(:where([class*="rg-button--"])):focus-visible { background: var(--color-surface-overlay); } /* ── 4b · [R7 · C6-15] THE THREE VARIANTS THAT STILL HAD NO GLOBAL HOVER ───────── MEASURED, not assumed. Of this lane's 116 `control.hover-delta` cells I resolved 62 at 1440; 37 carried no `data-glyph-hover`, and **36 of those 37 are design-system components with NO inline background** — `.rg-button--primary`, `--secondary`, `.rg-icon-button`, on `settings/security`, `settings/users`, `settings/plans`, `login-reset`, `remote-machines` and the shell header. So the cause was NOT the R17.1 inline-declaration problem this file was built for (that explains exactly ONE of the 37): `components.css` simply ships no hover for these variants, and the only rules that did exist were `modal.css`'s — SCOPED to the modal layer, so a Save button hovered inside a dialog and did not on a settings page. That is PB-00087's fork class again, and this file is the single definition it forks from. 🔴 THESE ARE CSS-ONLY, AND THAT IS THE SAFETY PROPERTY. §5's measured lesson is that HOISTING a component's rest background freezes a SELECTION (the credential modal's type toggle carries its state in `--primary` vs `--ghost`). A plain `:hover` rule never captures a resting value, so it cannot freeze one — which is why these belong here and not in `core/hover-affordance.js`'s GROUPS. Values are the ones `modal.css` already uses, read from the SAME tokens rather than re-chosen, so the two definitions cannot drift to different colours; every token was confirmed to RESOLVE at runtime (`--color-accent-solid-hover` = #56B3FE), never assumed to exist — §4 records what assuming cost last time. `.rg-input` / `.rg-select` are deliberately NOT here: their register rows declare a BORDER delta and the design system already ships one; adding a background would contradict the row rather than satisfy it. Selectors are one class + one pseudo-class — (0,2,0), inside TDR-075's ceiling, so the ratchet does not move. */ .rg-button--primary:hover, .rg-button--primary:focus-visible { background: var(--color-accent-solid-hover); } .rg-button--secondary:hover, .rg-button--secondary:focus-visible { background: var(--color-surface-overlay); } .rg-icon-button:hover, .rg-icon-button:focus-visible { background: var(--color-surface-raised); } /* ── 5 · [R5 · C4-01] the five real hover gaps left after the round-4 re-read ───── Every one was MEASURED under a REAL POINTER first (`Input.dispatchMouseEvent`, not a synthetic `mouseover`, which never sets `:hover`): of the 138 hover cells in this lane's slice, 84 already PASS and 19 genuinely have no delta. These rules close the ones a stylesheet can reach; the three carrying an INLINE background are hoisted by `core/hover-affordance.js` instead, because nothing in a stylesheet outranks an inline declaration and the ratchet forbids the one thing that does. · `.rg-choice__control` — the checkbox-style switches (`toggle.user-mfa-required`, `toggle.spam-score-visible`, `toggle.email-verify-visible`, `toggle.voice-number-soul`). All four rest transparent and had no rule at all; four register rows read "background delta" and none was delivered. · `.header-logo` — `img.logo` AND `gesture.logo-double-tap` are the SAME element and both rows read "opacity delta". It already renders `cursor: pointer`, so it claims to be a control while looking identical under the pointer. · `[data-to="login"]` — `link.back-to-sign-in` is rendered as an anchor with `.rg-button--ghost`, which the §3 `link` group deliberately excludes, so it got the ghost BACKGROUND hover while its register row reads "underline". Selected by the register's own `element:` attribute rather than by tag+class, which keeps this at (0,2,0) — `a.rg-button[data-to]:hover` would be (0,3,1) and fail the ratchet. */ .rg-choice__control:hover, .rg-choice__control:focus-visible { background: var(--color-surface-raised); } .header-logo:hover { opacity: var(--glyph-logo-hover-opacity, 0.72); } [data-to="login"]:hover, [data-to="login"]:focus-visible { text-decoration-line: underline; } /* `row.session-rename` — the register's affordance is "underline". The ROW is the hover target and the drawn title span is what changes. */ [data-slot-repeat="sessionRows"]:hover :where(.session-name-text) { text-decoration: underline; } /* ── 6 · [R7 · C6-17] THE TOUCH FLOOR — ONE DEFINITION FOR THE DESIGN SYSTEM ─── `control.touch-target` RAN FOR THE FIRST TIME IN ROUND 6 (R-OV-97(c)) and measured 91 controls below the 44 px the register declares. On this lane's slice the failures are not scattered: every real one is a design-system control class whose floor exists on SOME surfaces and not others — `design-new.css:194-195` `.dn-screen .rg-button|.rg-input { min-block-size: 44px }` `overlays.css:240` `.glyph-overlays .rg-button { min-block-size: 44px }` …so a `.rg-input` is 44 px on a DESIGN-NEW screen and 38 px on the tickets and spam-score screens, and an `.rg-button` with no `--sm` modifier (the new-ticket Create) has no floor at all while the `--sm` modifier does. That is PB-00087's fork class in CSS: three per-surface copies of one design-system decision, drifting. This is the single definition; the scoped copies are left in place only because they belong to other lanes' files, and they are now no-ops. 🔴 THE MEDIA CONDITION IS AN `OR`, ON PURPOSE. `(pointer: coarse)` is the honest condition, but it is only TRUE under `Emulation.setTouchEmulationEnabled` — the media call alone does not move it in this engine (measured; the harness's own `coarse()` carries the note). A leg that drives 390 without touch emulation would therefore read this floor as absent and re-file the whole class. `(max-width: 768px)` is the frame's own mobile breakpoint and is true at 390 however the leg is configured, so the floor holds under either. DESKTOP IS UNTOUCHED by construction: neither condition is true at 1440, so not one drawn desktop control moves. Sized with `min-block-size` / `min-inline-size` rather than `height`: the logical min/max properties are the only lever that beats a component's own `height`, and they CLAMP rather than replace, so a control that is already taller keeps its drawn height (v3.20.8 `[MOBILE-VIEWPORT-FIT]` measured the same asymmetry from the other side). Every selector is a single class: (0,1,0), well under TDR-075's 0,2,0 ceiling. */ @media (pointer: coarse), (max-width: 768px) { .rg-button { min-block-size: 44px; min-inline-size: 44px; } .rg-input { min-block-size: 44px; } .rg-select { min-block-size: 44px; } .rg-textarea { min-block-size: 44px; } /* ── [R7 · C6-15/C6-17 · R-OV-103 grant 1] THE REST OF THE MEASURED SET ───────── Extending the ONE definition rather than adding a scoped floor (R-OV-101). POPULATION, stated so the count is auditable: 100 controls resolved at 390 across 14 routes. **51 are ZERO-AREA** — inside a closed menu or an unopened overlay — and a zero-area node is UNMEASURABLE for this oracle, never "below floor" (ROUND-6 §7b ruled exactly that about `link.privacy`, and the round before had filed it as a finding). 35 already meet the floor. **14 are real**, and every one of them was outside the four selectors above: .rg-link 15-21px link.privacy · link.terms · link.approved-plans .rg-choice__control 16px the three preference/user toggles (checkboxes) .glyph-settings-rail__item 31px link.section-security · -notifications · nav-item.connected-accounts notifications bell 36px (addressed by its ARIA name — its only classes are extractor-generated `dcx-*`, which a re-export is free to rename) .skip-link 37px .header-logo 20px — see the PADDING note below 🔴 AN INLINE BOX IGNORES `min-block-size`, so the three `.rg-link`s need `inline-flex` before the floor can bind at all. Adding the floor without it is the inert-fix shape: the rule ships, the ratchet passes, and the control is still 15px. `inline-flex` keeps them on the same line as their neighbours, so the login footer does not reflow into a column. 🔴 THE LOGO GETS PADDING, NOT A FLOOR, AND THAT DISTINCTION IS THE WHOLE POINT. `min-block-size` on an `` grows the IMAGE, not a hit area around it — the drawn 26px mark would render 44px tall and the masthead would visibly change. R17.1 says the drawn element keeps its drawn geometry, so the TARGET is enlarged with `padding-block` while the rendered mark stays exactly the size the drawing gives it. `box-sizing` is not assumed either way: the padding is stated in the block axis only and the image's own `height` is untouched. ⚠️ `toast.container` (1px) IS DELIBERATELY ABSENT. It is `.sr-only` — a visually-hidden live region, not a control — and giving it a 44px box would drag a screen-reader-only node into the layout. It is EXCLUDED, not missed; the oracle reading it as a below-floor control is an instrument artefact, reported not fixed. */ .rg-link { display: inline-flex; align-items: center; min-block-size: 44px; } .rg-choice__control { min-block-size: 44px; min-inline-size: 44px; } .glyph-settings-rail__item { min-block-size: 44px; } .skip-link { min-block-size: 44px; } button[aria-label^="Notifications"] { min-block-size: 44px; min-inline-size: 44px; } /* 🔴 `content-box` IS LOAD-BEARING, AND WITHOUT IT THIS RULE IS INERT. Measured after the first draft shipped: the padding applied (`9px/9px`) and the rendered box was still **26px**, because the mark inherits `box-sizing: border-box` and padding is then taken OUT of the declared height instead of added to it. The image keeps its drawn 26px; only the target grows to 26+9+9 = 44. */ /* 🔴 [PP-FIX-SHELL-R8 · R-OV-129 item 3, orphan seam] THE OTHER AXIS. The rule above fixed the BLOCK axis and the control was still below the floor on the INLINE one: measured on the served preview at 390, `header img.header-logo` renders **20.1 x 44**, so its short side is 20.1px against a declared 44. The drawn mark is 791x1024 — TALL — so `padding-block` alone can never square it, and `min-inline-size` would stretch the IMAGE (it is a replaced element), which is the distortion R-OV-104(b) ruled against and `screen.image-aspect` measures. Padding grows the TARGET and leaves the mark alone, in both axes, which is the same argument the block-axis note above makes. 12px each side takes 20.1 -> 44.1: the value is derived from the MEASUREMENT, not chosen — `(44 - 20.1) / 2 = 11.95`, rounded up so the floor is cleared rather than met exactly. `content-box` (declared above) is what makes padding ADD to the box. */ .header-logo { box-sizing: content-box; padding-block: var(--glyph-touch-pad, 9px); padding-inline: var(--glyph-touch-pad-inline, 12px); } } @media (prefers-reduced-motion: reduce) { [data-glyph-hover] { transition: none; } } } /* ═══════════════════════════════════════════════════════════════════════════════ 7 · [PP-HOVER-CLOSE · R-OV-131(e)] THE OVERLAYS CHIPS — AND THE ONLY REASON THIS BLOCK IS IN `@layer overrides` INSTEAD OF `surfaces` WITH EVERYTHING ELSE. ═══════════════════════════════════════════════════════════════════════════════ 🔴 THE MECHANISM IS A SOURCE-ORDER TIE, NOT AN INLINE DECLARATION — measured with Chromium's OWN cascade resolution (`CSS.forcePseudoState` + `CSS.getMatchedStylesForNode`, evidence `.audit-tools/hover-close/out/why-before.txt`), because reading the sheets is exactly how the previous two readings of this class disagreed: [regular] layer=surfaces .glyph-overlays [aria-pressed="false"] => background: transparent [regular] layer=surfaces .rg-button--ghost:hover, …:focus-visible => background: var(--color-surface-raised) `overlays.css`'s REST rule is (0,2,0) in `@layer surfaces`. This file's HOVER rule is (0,2,0) in `@layer surfaces`. `overlays.css` is injected LAZILY by `linkSurfaceCss()`, so it is LATER in the layer — and a tie on specificity inside one layer breaks on source order. The rest rule therefore wins IN THE HOVER STATE, and no rule this file can write in `@layer surfaces` will ever reach these chips. 🔴 THE HOIST WOULD HAVE BEEN INERT, AND THAT IS WHY THE MECHANISM HAD TO BE MEASURED FIRST. `core/hover-affordance.js` exists to beat an INLINE declaration; these chips carry only `min-block-size` inline (measured). A hoisted `[data-glyph-hover]{background: var(--glyph-rest-bg)}` scores (0,1,0) and would lose to the same rest rule by MORE than the rules already here. Applying the named pattern without measuring which blocker is in force would have shipped a rule that changes nothing and been reported as a fix. WHY A LAYER AND NOT MORE SPECIFICITY: `.glyph-overlays [aria-pressed="false"]:hover` is (0,3,0) and `css-ratchet` pins `selector-max-specificity: 0,2,0` with `overlays.css` at a baseline of ZERO findings — so out-specifying it is forbidden, and `!important` is forbidden estate-wide. A later LAYER wins at ANY specificity, which is what layers are for. `overrides` is the last name in the estate's own declared order (`css/layers.css:47`), and `glyph-bridge.css` already uses it for this same reason on the legacy document. MEASURED for THIS document: `shell.html` loads neither `layers.css` nor `style.css`, and its only layer STATEMENT is `@layer tokens, base, components, utilities;` (design/export/tokens.css:20), so `surfaces` and then `overrides` are created in first-appearance order by this very file — `overrides` last. Nothing else on this document uses it. WHY IT IS SCOPED AND NOT DOCUMENT-WIDE: a bare `[aria-pressed="false"]:hover` in a layer that beats everything would also override the 79 hover cells that ALREADY PASS on their own surfaces' rules (settlement count, whole register). The scope is the population the settlement measured, and nothing else. `:where()` supplies it at zero specificity so the pair stays (0,2,0) and the ratchet does not move. WHY IT CANNOT FREEZE A SELECTION — the hazard R-OV-126(c) names: the selector matches `[aria-pressed="false"]` ONLY. Selection MOVES that attribute, so a chip that becomes selected stops matching this rule in the same frame, and the selected rendering (`.glyph-overlays [aria-pressed="true"]`: accent surface + accent border + accent text) is untouched. `--color-surface-raised` is deliberately NOT the selected token, so hover and selected stay distinguishable (ui-consistency §7). THE SWITCH: `overlays.css:155` already ships `.glyph-overlays [role="switch"] { cursor: pointer }` — the control CLAIMS to be a control and then looks identical under the pointer, which is the same defect `.header-logo` carries in §5. Its drawn track is a known design gap (`GAP-STUB:G-P3-10`, and inventing a track WOULD be a defect), so what is added here is a STATE on the wrapper, never a resting element the drawing does not have. Same layer, same reason: the `cursor` rule is in `overlays.css` and later. */ @layer overrides { :where(.glyph-overlays) [aria-pressed="false"]:hover, :where(.glyph-overlays) [aria-pressed="false"]:focus-visible { background: var(--color-surface-raised); } :where(.glyph-overlays) [role="switch"]:hover, :where(.glyph-overlays) [role="switch"]:focus-visible { background: var(--color-surface-raised); } /* 🔴 THE SELECTED MESSAGES CHIP KEEPS ITS DRAWN COLOUR — A SIDE EFFECT THIS PASS CAUSED AND MEASURED ON ITSELF, NOT A DESIGN OPINION. Rerouting `paintSelected()` off an inline `background` and onto `--glyph-rest-bg` REMOVED the one declaration that outranked `frame.css:75` `.glyph-frame [aria-pressed="true"] { background: var(--color-accent-surface) }` — (0,2,0) against the hoisted read-back's (0,1,0) — so `messages/filter.inbox`'s SELECTED chip silently moved rgb(26,35,50) -> rgb(11,39,64) the moment the hover fix landed. Two reasons that is a defect and not an improvement, and only the second is a preference: · R17.1 — the drawing wins. Restyling a control to fix its HOVER is the trade this whole build exists to refuse, and the register's own `rendered_as` for this chip reads "raised surface with accent text". · it collides with the hover. `--color-accent-surface` is exactly what the `raised` kind hovers to (§1), so a hovered UNSELECTED chip would have rendered identical to a SELECTED one — and `filter.inbox`'s register row says `selected != hover` in so many words. The hover oracle cannot see that: it compares rest against hovered and never against the selected sibling. It was caught by this lane's selection round-trip leg, which reads both. SCOPED TO THIS SURFACE ONLY. `.glyph-overlays [aria-pressed="true"]` keeps the accent surface (it never had an inline write to lose), and `row.channel`/`row.dm`/ `filter.account` carry `aria-current`, which `frame.css:75` does not match — measured, not assumed. (0,2,0): two attribute selectors, `:where()` contributes nothing. */ :where(.glyph-messages) [data-glyph-hover][aria-pressed="true"] { background: var(--glyph-rest-bg, transparent); } @media (prefers-reduced-motion: reduce) { :where(.glyph-overlays) [aria-pressed="false"] { transition: none; } } }