/* ============================================================================ CHROME CARRYOVER — the rules a WORKING chrome needs that CD's export does not contain. Loaded immediately after chrome-unified.css. Why this file exists at all: chrome-unified.css is kept BYTE-IDENTICAL to the _15 export (15,296 B, md5 7c501d19710dea79ba98b777eb7c8896) so that "the served sheet is CD's design, unmodified" stays a provable assertion rather than a claim. The moment we edit that file to add our own rules, it stops being the artefact and every future comparison against _15 is worthless. So our additions live here, named, small, and reviewable on their own. Both rules below came from chrome-b3.css, the implementation this replaces. Neither is a preference — each was measured as a real loss before the swap: 1. .dsh { display: contents } CD's demo page has a whole document to lay out. Ours does not: the shell wraps ONLY the header, so it is a ~64px box, and a sticky .dch-header inside a 64px box has nothing to stick to — it scrolls away. b3 solved this with display:contents, which removes the shell box from layout so .dch-header becomes a child of the real page flow. chrome-unified.css has no bare .dsh rule at all, so without this the header stops being sticky on all 72 surfaces. (Sid's check step: "scroll down — does the header stay stuck to the top?") 2. .dch-search__btn Our search field has a clickable submit button; CD's _12 demo has a bare input with none, so the export never needed the rule. Drop it and the magnifier becomes an unstyled button sitting in the field. (Sid's check step: "a visible search button, not a bare field.") ⛔ Do not add anything here that CD's export DOES contain — that recreates the duplicate-definition problem the b3/unified swap was meant to end. This file is for the delta between a design export and a working chrome, and it should stay short enough to read in one screen. ========================================================================== */ /* 1 — the shell box must not exist in layout, or the sticky header is not sticky */ .dsh { display: contents; } /* 3 — SID'S LOGO LOCK, restored. pillar-landing.css carries `.pl-logo img{height:40px}` (34px mobile) under the comment "Sid-LOCKED chrome logo prominence — ONE size across anon + post-login (matches .dch-logo)". That comment asserted a match that was not true: chrome-unified.css sizes .dch-logo img at 22px, so adopting the _15 export silently overrode a locked decision. Nothing decided to change it — it died as a side effect, and Sid re-requested 40px independently without being reminded the lock existed. Two arrivals at the same answer from different directions. ⛔ PRE-REGISTERED, so it is not reported as a regression: CD sized the header bar around a 22px mark, so 40px may make the BAR TALLER. That is the correct outcome. The logo is brand prominence; the bar is a container, and containers give way. Do NOT shrink the logo to preserve the bar height, and do not let a later tidy-up do it either. ⛔ It lives here and not in chrome-unified.css because that file stays byte-identical to _15 — comparability against the export is worth more than keeping related rules adjacent. This is that file's second use, and it is exactly the job it was built for. */ .dch-logo img { height: 40px; } .dcf__brand img { height: 24px; } /* matches the pillar footer, not the export's 22 */ @media (max-width: 720px) { .dch-logo img { height: 34px; } } /* 2 — the search submit button (b3:236-238, verbatim) */ .dch-search__btn { position: absolute; left: 6px; top: 50%; transform: translateY(-50%); width: 28px; height: 30px; display: inline-flex; align-items: center; justify-content: center; background: none; border: 0; padding: 0; cursor: pointer; color: rgba(255,255,255,0.6); z-index: 1; } .dch-search__btn:hover { color: #fff; } .dch-search__btn svg { position: static; transform: none; } /* 4 - A11Y REGRESSION, and we had already fixed it once under the old class names. On the pillar landings a `.pl` ancestor wraps the unified chrome, and pillar-landing.css carries `.pl a{color:inherit}` at (0,1,1). That outranks chrome-unified.css's `.dch-btn--outline-light{color:#fff}` at (0,1,0), so the Sign in button inherits dark body text onto the navy bar and becomes unreadable. Sid reported it twice. landing-build.css already holds the ORIGINAL fix for this exact bug, logged as a contrast fix - but its selector is `.pl .pl-header .pl-btn--outline-light`, and `.pl-header` / `.pl-btn--*` are the OLD chrome. It matches nothing now, so a live a11y fix silently stopped applying when the chrome was replaced. ⛔ NOT patched in pillar-landing.css: `.pl a{color:inherit}` is legitimate for page links; the button is what needs pinning, not the link rule. ⛔ NOT patched in chrome-unified.css, which stays byte-identical to _15. Scoped to `.dsh` so it can only ever affect the chrome. */ .dsh .dch-btn--outline-light, .dsh .dch-btn--ghost-light { color: #fff; } /* 5 - THE HERO GLOBE. Sid, on the homepage hero: "it shows a bright area but it should be the dice globe icon." ⚠️ DEPARTURE, flagged not hidden: the ruling specified an in the markup, matching how pillar-landing.css did it. `.mk-hero` appears in EIGHT views (hub, for-buyers, for-sellers, dice-sports, solutions-partners, about, contact, request-access), so an would be eight copies of one construct - the exact shape that has cost this build four times this week. As a decorative element it also does not belong in markup at all. One ::after on .mk-hero gives every hero the motif with no markup change and no per-page drift. Revert to the in one edit if the shape is wanted. ⛔ ASSET: the source dice-globe-white.png is 3,036,227 B, rendered 560px wide at 6% opacity. Serving that would be absurd. dice-globe-white-hero.webp is the same art at 1120px (2x for a 560px box), 79,024 B - a 38x reduction. The 3 MB original is KEPT, untouched, per the no-delete default. 📌 The .06 opacity and the WHITE variant are both 25-July rulings, not defaults: a build once shipped the colourful globe at full saturation and it was flagged. ✅ .mk-hero__g stays exactly as CD wrote it - the glow is correct and the globe sits on top of it. */ .mk-hero::after { content: ""; position: absolute; right: -110px; bottom: -150px; width: 560px; height: 560px; pointer-events: none; opacity: .06; background: url("/assets/store/img/dice-globe-white-hero.webp") no-repeat center / contain; } /* 6 - THE MOBILE DRAWER WAS 76px TALL. Sid opened the burger and saw a blank panel. CAUSE, verified independently here before fixing: .dch-header carries backdrop-filter: blur(10px), and backdrop-filter CREATES A CONTAINING BLOCK for position:fixed descendants - the same spec clause as transform, filter, perspective, contain and will-change. nav#bcNav is INSIDE .dch-header, and at <=860px it is position:fixed with top:0;left:0;bottom:0. Those offsets therefore resolved against the 64px HEADER rather than the viewport, so the drawer was a 76px-tall box with overflow-y:auto clipping all seven links inside it. The links were never missing and the JS was never broken. Every static check passed because every static thing was correct - which is why nothing found it until someone opened a browser. ⛔ WE ALREADY HAD A RULE FOR THIS AND IT MISSED ON BOTH AXES: ours said "no transform/filter/contain/will-change on an html/body SUBJECT rule". The property here is backdrop-filter (not on our list) and the subject is .dch-header (not html/body). Restated as the mechanism rather than a list: ANY ancestor of a position:fixed element carrying transform, filter, backdrop-filter, perspective, contain or will-change makes that element resolve against the ancestor instead of the viewport. Scoped to the breakpoint where the drawer exists. The header background is rgba(7,30,50,.94) - 94% opaque - so the blur contributes almost nothing visible, and at mobile widths there is very little behind it to frost. Desktop keeps CD's blur untouched. ⛔ NOT fixed in chrome-unified.css: that stays byte-identical to _15. This file exists for exactly this. */ @media (max-width: 860px) { .dch-header { backdrop-filter: none; } } /* 7 - THE DRAWER OPENED BUT ITS LINKS WERE NOT CLICKABLE. The layer under #6. .dch-header is position:sticky WITH a numeric z-index, which CREATES A STACKING CONTEXT. .dch-nav lives inside it, so its z-index:60 competes only INSIDE that context. .dch-scrim is a SIBLING of , so it sits in the ROOT context. At root the comparison is therefore HEADER 50 vs SCRIM 55 - the scrim wins and paints over the entire header subtree, drawer included, whatever the drawer's own z-index says. So the scrim dimmed the drawer AND swallowed every click, and the scrim's handler closes the menu - which is exactly "the links do nothing". ⛔ THIS WAS NEVER OUR BUG AND IT IS NOT A REGRESSION FROM #6. The stacking values are CD's, verbatim in _15, and CD's own demo places the scrim after too - so their drawer cannot have been clickable either. #6 was masking it: a 76px clipped drawer has no clickable links to lose. THE INVARIANT: the stacking context CONTAINING the drawer must outrank the scrim. Two ways - raise the header above 55, or lower the scrim below 50. ▶️ Chose LOWERING THE SCRIM, on the measured band rather than on instinct: 70 .cat-selbar · 60 .dch-nav/.cat-rail · 55 scrims · 50 .dch-header 40 .pl-header/.cat-header/.pl-nav · 20 .lst-tabs 45 sits ABOVE every page-content layer (which tops out at 40) and BELOW the header (50). Raising the header instead would change its relationship to every element on every page; the scrim exists in one state only and is display:none otherwise, so it has by far the smaller blast radius. ⚠️ EXPECTED VISUAL CONSEQUENCE, pre-registered so it is not reported as a bug: the HEADER BAR is no longer dimmed while the menu is open. That is inherent - the drawer lives inside the header, so anything that lifts the drawer above the scrim lifts the header with it, and raising the header would have done exactly the same. Page content behind still dims, which is what the scrim is for. ⛔ chrome-unified.css untouched. */ @media (max-width: 860px) { .dsh--menuopen .dch-scrim { z-index: 45; } } /* 9 - THE NAV ACCENT SET, all three declarations together (DH 2026-08-11). CD's default is .dch-nav{--nav-accent:var(--ps)} - the SPORTS teal - with overrides for --ent, --channels and --solutions and none for marketing. Two consequences, both real: every MARKETING page drew its active underline in the sports colour, and a missing modifier on /sports was undetectable because the default happened to be its own accent. ⛔★★★ THE DEFAULT MOVES, and that is the actual fix rather than the override. While the default IS Sports, a missing modifier on /sports is invisible. Once it is the neutral brand accent, a missing modifier is VISIBLE on every pillar INCLUDING Sports. ⇒ DH's rule, which is stronger than the observation it came from: CHOOSE A DEFAULT THAT IS SAFE-BUT-NEVER-CORRECT FOR ANY MEMBER OF THE SET. I had "a default that is right for one member hides that member's omission"; DH turned it into something actionable: pick one that is right for none. var(--accent) #0B599C is the brand accent, already shipping in dice-tokens.css on every page - no new token, no new sheet. ⛔ chrome-unified.css stays byte-identical to _15; all three live here. */ /* ⚠️ :where() IS LOAD-BEARING, NOT STYLE. A plain `.dch-nav{...}` here is (0,1,0) and this sheet loads AFTER chrome-unified.css - so at EQUAL specificity it wins, and it silently overrode CD's own .dch-nav--ent / --channels / --solutions. Measured when I first wrote it that way: /entertainment, /channels and /solutions ALL resolved to var(--accent), i.e. moving the default broke every pillar accent the commit was meant to protect. :where() contributes ZERO specificity, so it changes the DEFAULT while losing to every explicit modifier, including CD's. */ :where(.dch-nav) { --nav-accent: var(--accent); } .dch-nav--marketing{ --nav-accent: var(--accent); } /* 8 - .dch-nav--sports, which CD never defined. CD's sheet gives an accent override to --ent, --channels and --solutions, but not to sports, because .dch-nav's DEFAULT is already var(--ps) - the sports teal. That is why /sports looked right while emitting no modifier at all, and it is exactly what hid /solutions wearing the sports colour instead of its own --pso blue: the same omission is invisible on one page and wrong on another. This rule changes NOTHING visually. It exists so the class is real, so the markup can emit all four, and so the absence of a modifier is never again untestable on the one page where the default happens to be correct. ⛔ chrome-unified.css untouched - the artefact stays byte-identical to _15. */ .dch-nav--sports { --nav-accent: var(--ps); }