/* Mirror — shared chrome corrections ========================================================================== ❄️ GENERATED from the FROZEN shared-shell prototype. Do not hand-edit. source : docs/mirror-web-shared-shell-2026-09-01/prototype/chrome-fixes.src.css sha256 : 54d73e194aff68bcd85df7a83ed81cade9b9b3cd832cc7322f5032433e6cb4b1 (pinned in FROZEN.sha256) built : docs/mirror-web-shared-shell-2026-09-01/prototype/ship.py buster : ?v=mwu-sharedshell-20260902a ⚖️ OD-SS-3 and OD-SS-4. Six corrections to Home's OWN chrome, applied at the shared level so Home receives them too. ⛔ LOADED BY BOTH SHELLS — layouts/site/head.blade.php AND layouts/customer/master.blade.php. A sheet loaded only by the customer layout would leave Home with the defects, which the ruling forbids. ⛔ custom.css is SHA-256 pinned (R3), so F-3 and F-4 are corrected here rather than at the line that causes them. The comments say which line. ========================================================================== */ /* ═══════════════════════════════════════════════════════════════════════════ SHARED CHROME CORRECTIONS — ⚖️ OWNER RULINGS OD-SS-3 and OD-SS-4 Five defects the customer shell inherits from Home, plus the WhatsApp collision. All ruled 2026-09-01: OD-SS-3 "Fix these defects in the shared chrome, and apply the fixes to Home as well. Since these are shared Home chrome defects, do not create page-specific overrides to hide them. Fix them at the shared chrome/source level so Home and the customer pages remain consistent. Before changing anything, document each defect and verify its exact current behavior. Preserve the existing approved Home design everywhere else." OD-SS-4 "Move/lift the WhatsApp floating button so it never overlaps the bottom customer navigation. Apply the correction at the shared chrome level, including Home. Preserve the existing WhatsApp button design; only correct its position/stacking." ⛔ NOT page-specific. Every selector below is a CHROME selector — the header, the footer, the bottom-bar spacer, the floating button. Nothing here names a surface class, and nothing here can reach inside a frozen surface. ⛔ NOT AN EDIT TO A PINNED FILE. `assets/site/css/custom.css` is SHA-256 pinned by S5CustomerAppIconsTest (R3), so F-3 and F-4 cannot be corrected where they were written. They are corrected ADDITIVELY here instead, which is the same discipline the three MWU sheets already follow. ⚠️ At implementation this ships as ONE new file loaded by BOTH shells — `layouts/site/head.blade.php` AND `layouts/customer/master.blade.php` — or Home would not receive the fixes the ruling asks for. See ../05-laravel-integration-strategy.md §3.1d. ⚠️ `dark-mode.css` is NOT pinned and no test references it, so F-10 and F-11 could alternatively be corrected in place. They are kept here so that ONE new file carries all six corrections and NO existing stylesheet changes at all — the lower-risk option, and the one that keeps the rollback a single `` removal. Recorded as a choice, not an omission. REVIEW CONTROL: everything is gated on ``, which the shell panel can switch off. That is how the ruling's "verify its exact current behavior" precondition is met — the before and the after are both in the artefact, one click apart. ⛔ The gate is prototype-only; the shipped sheet carries the declarations unconditionally. ═══════════════════════════════════════════════════════════════════════ */ /* ── F-2 · The bottom-bar spacer is shorter than the bar ────────────────── DEFECT, verified: `.mirror-cnav-spacer` is a hard-coded `72px` (nav.blade.php:138) while `.mirror-cnav` is content-sized and measures 74.2px at 360 and 75.4px from 390 up. The last 2.2–3.4px of the footer's bottom bar therefore sits underneath the fixed navigation — on Home exactly as on these three pages. FIX: the spacer takes the bar's MEASURED height instead of a magic number, through a variable a ResizeObserver keeps current. Nothing about the bar changes — its height, padding, type and icons are the approved chrome; only the reservation behind it becomes correct, at every width and in both directions, and it cannot drift again if the bar's content ever changes. */ .mirror-cnav-spacer { height: var(--mirror-ss-cnav-h, 72px); } /* ── F-3 · The footer's bottom bar stacks onto three lines ──────────────── DEFECT, verified: `custom.css:6790-6797` sets `display: block` on `.mirror-footer a`. That rule is written for the four link COLUMNS, where a block anchor is correct — but it also matches `.mirror-footer-link` in `.mirror-footer-bottom`, so "© 2021-2026 Mirror App. All Rights Reserved | Privacy Policy | For Salons" renders on three lines with its two separators orphaned on the ends of the lines above. FIX: restore inline flow for the bottom bar only. The column links keep `display: block` exactly as approved — this adds a rule, it does not weaken the existing one. */ .mirror-footer-bottom a { display: inline; line-height: inherit; } /* ── F-4 · The header wraps to three lines at 1024 ──────────────────────── DEFECT, verified: at 1024 the container is ~994px and `.main-menu ul li a` carries `padding: 14px 20px !important` (custom.css:499-507), so the six nav links plus the theme toggle, the language toggle, the provider CTA and the account link do not fit one line. `.navbar-nav` wraps and the header grows from 168px to 182px. At 1200 and above it fits and nothing wraps. FIX: reclaim 120px of horizontal padding in the 992–1199 band ONLY, by halving the link padding there. Above 1200 nothing changes, so Home's approved desktop header is untouched at the width it was designed for; below 992 the links are in the SlickNav dropdown and this rule cannot apply. ⚠️ `!important` is required and is not decoration: the declaration being corrected is itself `!important`, so a normal declaration of any specificity would lose to it. */ @media (min-width: 992px) and (max-width: 1199.98px) { .main-menu ul li a { padding: 14px 10px !important; } } /* ── F-10 · The footer's social icons are not themed ────────────────────── DEFECT, verified: `dark-mode.css` themes `.mirror-footer .footer-links a` to `#a0a0b0` but has NO `.footer-social` rule, so the four brand glyphs keep the light `#8a8a9a` on the dark `#0f1929` footer — legible at ~4.3:1, but visibly dimmer than the links beside them. FIX: give them the same treatment their neighbours already have, hover included. No new value is introduced. */ html[data-theme="dark"] .mirror-footer .footer-social a, html.dark-mode .mirror-footer .footer-social a { color: #a0a0b0; } html[data-theme="dark"] .mirror-footer .footer-social a:hover, html.dark-mode .mirror-footer .footer-social a:hover { color: #d4a574; } /* ── F-11 · dark-mode.css misspells the brand ───────────────────────────── DEFECT, verified: `#721d43` appears four times in dark-mode.css where the brand is `#711D43` everywhere else in the system — one digit out. :119 [data-theme="dark"] .mirror-chip:hover (a Home component) :181 [data-theme="dark"] .mirror-step-circle (a Home component) :221 .mirror-theme-toggle:hover ⭐ IN THE SHARED HEADER :251 .mirror-lang-toggle:hover ⭐ IN THE SHARED HEADER ⚠️ The last two carry NO theme prefix, so they are wrong in LIGHT mode too — hovering the theme or the language control on any Mirror page today paints the near-brand. That is the only one of the four these three pages can demonstrate; the first two are Home-only components and are corrected here for Home's benefit rather than this prototype's. FIX: the brand, spelled correctly. Invisible to the eye by design — the point is that one system has one brand value. */ .mirror-theme-toggle:hover, .mirror-lang-toggle:hover { border-color: #711D43; color: #711D43; } html[data-theme="dark"] .mirror-chip:hover, html.dark-mode .mirror-chip:hover, html[data-theme="dark"] .mirror-step-circle, html.dark-mode .mirror-step-circle { background: #711D43; } /* ── OD-SS-4 · The WhatsApp button must never overlap the bottom bar ────── DEFECT, verified: `master.blade.php:41-44` places the button at `bottom: 30px` (20px below 768) with `z-index: 1000`, while the customer navigation is `position: fixed; bottom: 0` at `z-index: 1200` and measures 74–76px tall. The button therefore sits BEHIND the bar and is partly unclickable — on Home today, and on any page that renders the bar. FIX, and it is a position change only: lift the button clear of the bar by the bar's own measured height. Same size, same colour, same shadow, same pulse animation, same side, same RTL mirroring (`rtl.css:106-116` still puts it on the left) — only `bottom` moves, and it moves by a measured value rather than a guess, so it stays correct if the bar's height ever changes. ⚠️ Applies wherever the bar renders, Home included. Where the bar is NOT rendered — a signed-in provider or admin, per ruling 10.7 — the variable is 0 and the button returns to Home's original 30px / 20px exactly. */ html body .floating-whatsapp { bottom: calc(var(--mirror-ss-cnav-h, 0px) + 30px); /* ⚠️ F-12, and without this the correction above silently does nothing. master.blade.php:47 gives the button `transition: all 0.3s ease` while :53 runs `animation: pulse 2s infinite`. A blanket `all` therefore puts `bottom` under a transition that the infinite animation keeps from ever settling — measured: the rule computed correctly, the button did not move, and `getComputedStyle().bottom` stayed pinned at its start value INDEFINITELY, not for 300ms. Killing the transition on the element made `bottom` jump straight to the correct 106px. The fix narrows `all` to the two properties the transition was written for — the hover lift and its shadow (master.blade.php:49-51). The hover feel, the pulse and every visual property are preserved exactly; only `bottom` stops being animated, which it was never meant to be. */ transition: transform 0.3s ease, box-shadow 0.3s ease; } @media (max-width: 768px) { html body .floating-whatsapp { bottom: calc(var(--mirror-ss-cnav-h, 0px) + 20px); } }