/* dashboard/css/dashboard-zoom.css * ───────────────────────────────────────────────────────────────────── * Laptop density tier for the member dashboard. * * Symptom it fixes: on a laptop panel with Windows display scaling (a 1920x1080 * screen at 150% reports a 1280 CSS-px viewport) the dashboard chrome — 80px * rail, reactor panel, card padding — is sized for a ~1900px desktop, so * everything reads oversized and only a sliver of the page fits on screen. The * workaround was Ctrl+minus to 75%; this file does that automatically. * * Loaded LAST in dashboard/index.php's so it beats the inline shell styles * above it, immediately followed by its companion script * dashboard/js/zoom-viewport-units.js — see "the other half" below. * * WHY `zoom` AND NOT A FONT/PADDING PASS: * • `zoom` scales LAYOUT (widths, flex bases, fixed chrome, the v2 iframe's * inner document) uniformly — one number, nothing else to keep in sync. * • `transform: scale()` would shrink the pixels but leave the original layout * box behind, so the page would render at 75% inside a 100%-sized hole and * every position:fixed overlay would land in the wrong place. * • A per-element font/padding pass would have to touch every SPA view CSS file * in the app (dashboard, v2, communities, deal lab, courses, EstiMate…), all * of which size in hardcoded px. * * WHY THE WHOLE 1024–1440 RANGE: a "1440p-class" laptop's real CSS innerWidth is * unpredictable — window chrome, Windows display scaling and browser zoom all * shift it (commonly ~1150–1440 on the same physical machine). A narrow pixel * band was too fragile to hit reliably. Above 1440 is a desktop monitor and is * left completely untouched. * * The floor is 1024 and not 1025 because dashboard/index.php redirects to * /coming-soon-mobile on `innerWidth < 1024` — so 1024 is the NARROWEST width that * still reaches the dashboard, and starting at 1025 left exactly that one width * rendering the full desktop layout unscaled, which is the case this tier exists * for. Keep the two numbers in agreement if either moves. * * ── THE OTHER HALF: VIEWPORT UNITS ── * `zoom` scales everything EXCEPT vh/vw, which keep resolving against the real * viewport. A `height:100vh` element therefore computes 632px inside a body whose * local space is 842px tall and paints at 632 × 0.75 = 474px — a quarter of the * screen left empty at the bottom. This app pins heights to viewport units in * ~380 places, so they are corrected mechanically at runtime rather than by hand: * dashboard/js/zoom-viewport-units.js re-emits every viewport-unit length divided * by the zoom factor, which is exactly the substitution real browser zoom does. * * That is why there are no `calc(100vh / 0.75)` overrides in this file, and why * you should NOT add any: the script would scale them a second time. Write plain * `100vh` anywhere in the app and it comes out right. * * The same script scales two other things `zoom` leaves behind — media-query * lengths (so the app's own breakpoints describe the space the layout actually * has, not the smaller screen) and viewport units in inline style attributes. And * JS that measures the viewport and writes pixels back must divide by * window.dashZoomFactor(); see that file's header for the full contract. * ───────────────────────────────────────────────────────────────────── */ /* Always defined so JS can read it unconditionally; 1 means the tier is off. Read by dashboard/js/zoom-viewport-units.js, dashboard/partials/dashboard_v2_frame.php and includes/js/tutorial.js, so it MUST track the `zoom` value below exactly. */ :root { --dash-zoom: 1; } @media (min-width: 1024px) and (max-width: 1440px) { /* Tune this one number to taste — 0.8 is milder, 0.67 tighter. Change it in BOTH places; nothing else in the app needs to know about it. */ :root { --dash-zoom: 0.75; } body { zoom: 0.75; } }