/* AI Cloud component plugin: Foundation */ /* Web font loading (Inter + weights) now lives in the Typography module's typography.css @import. */ /* ===== Design tokens ===== */ :root{ /* ===== Shell geometry ================================================ --mp-rail is the VISIBLE rail width; the sidebar element is drawn --mp-pane-lap wider and runs UNDER the content pane, which starts at --mp-rail and paints over it. That is what lets .content carry a rounded corner: behind the curve there is always sidebar, so there is no gap to see through. The invariant is radius == lap and it is derived, not agreed — a radius LARGER than the lap exposes a wedge of page background where the rail and the bar meet at a right angle. The lap is also added to the sidebar's right padding, so the nav column keeps the width it had before the overlap and the white space either side of it stays equal. */ --mp-rail:268px; --mp-sb-pad:14px; --mp-pane-lap:18px; /* The page gradient lives on the CONTENT PANE, not on . Two reasons, and the second is not cosmetic. It is only visible on the pane now that the pane is an opaque surface of its own. And the rail and the app bar are both var(--mp-sidebar) at 75% over a 22px backdrop blur — identical layers — which rendered as two different shades purely because the backdrop under them differed: the logo sits deep in the top-left radial, the bar beside it is past its 35% falloff. With flat they resolve to the same colour by construction, so they read as one piece without either of them naming a literal. */ --mp-pane-bg: radial-gradient(circle at top left,#10335f 0%,transparent 35%), radial-gradient(circle at bottom right,#0a7d49 0%,transparent 30%), linear-gradient(180deg,#050816 0%,#09111f 100%); --mp-pane-shadow:rgba(0,0,0,.35); --bg:#060816; --black:#06111d; --panel:#0f1729cc; --panel-solid:#101828; --border:rgba(255,255,255,.08); --text:#f8fafc; --muted:#94a3b8; --purple:#8b5cf6; --blue:#0ea5e9; --amber:#f59e0b; --orange:; --pink:#ff6b8a; --red:#f43f5e; --green:#00EA5E; --green-soft:rgba(0,234,94,.12); --green-light: #00e676; --grad-brand:linear-gradient(135deg,#00ea5e,#38bdf8); --shadow:0 10px 40px rgba(0,0,0,.35); --radius:5px; --highlight:var(--green); --highlight-soft:rgba(0,234,94,.12); /* ===== Scheduling block grammar ===== ONE definition of what a dated block looks like, shared by every surface that draws one. --acc carries the accent; consumers compose: background: color-mix(in srgb, var(--acc) var(--mp-block-fill), var(--panel)); box-shadow: inset 0 0 0 var(--mp-block-hair) color-mix(in srgb, var(--acc) var(--mp-block-border), transparent); border-left: var(--mp-block-rail) solid var(--acc); Percentages are tokens too, so a density change is one edit here. The ring may also be a BORDER, and the calendar composes it that way: its blocks are dragged and hover-expanded, and those states own box-shadow. The timeline cannot pay a border's half pixel on a time axis. Same numbers, two compositions. Provisional is part of the grammar: --mp-block-fill-soft plus a dashed ring at --mp-block-hair-soft, rail left solid. The hairline is not used for the dash because Chromium snaps 0.5px and 1px to the same painted line, and a dash needs more than that to read. */ --mp-block-radius:8px; --mp-block-fill:22%; --mp-block-fill-soft:14%; --mp-block-border:55%; --mp-block-hair:0.5px; --mp-block-hair-soft:1px; --mp-block-rail:3px; /* Direct-manipulation knob: hidden at rest, revealed on hover. Sized here so the calendar's resize handles and the timeline's edge handles cannot diverge. */ --mp-knob-size:8px; --mp-knob-ring:2px; --mp-knob-hit:14px; /* The content column's gutter. SINGLE SOURCE: .content pads by it, and the app bar bleeds through it with a matching negative margin (navigation-shell). Anything that has to line up with the page's left/right edge reads this — never a literal. Two copies of this number is how the bar ended up 10px short of the column edge. */ --mp-content-pad:42px; /* The gap under a page's HEAD ROW — the control row a page opens with — and the surface beneath it. SINGLE SOURCE: .mp-seg-shell--rail (actions-badges) reads it for a standalone tab rail, .mpdg-toolbar (surfaces-data) reads it for a grid toolbar. Those were 20px and 16px, and before the rail modifier existed each module had invented its own third number. Two copies of this value is how Mail's tab bar ended up sitting 36px from its grid where Tasks sat 16px — the copies do not overwrite one another, they ADD, and neither stylesheet was wrong on its own. Held by tests/behavior/tab_rail_gap_test.js, which measures both contexts against this token in a real browser rather than against a literal of its own. */ --mp-head-gap:16px; --btn-radius: 5px; --pill-radius: 999px; --transition: .16s ease; } /* ===== Base reset ===== */ /* RESTORED IN v1.12.469, ON THE ARCHITECT'S CALL, AFTER BEING REMOVED IN v1.12.468. The removal's measurement still stands and is worth keeping written down: dropping this produced byte-identical screenshots at 1440, 1024, 980 and 760 in Chromium at dpr 2, against a control that moved 241 of 255 on 3.94% of pixels. So it buys nothing visible on Chrome, which already applies kerning and standard ligatures by default. What the removal was WRONGLY credited with was fixing a resize stall on Chrome/macOS. It did not. Nor did the content-visibility rule that replaced that credit at v1.12.469, which was measured to skip 0 of 100 rows during a drag and removed again at v1.12.471. The cause was `backdrop-filter:blur(8px)` on the base .btn class - 600 backdrop roots on a page of 100 rows - and a trace from the installation puts checkerboarded_needs_raster at 130 before and 0 after. Since the only argument left for removing THIS was a cost with no demonstrated symptom, it goes back rather than staying out on a rationale that collapsed. If it is ever removed again, remove it for a measured symptom, not for a measured cost. */ *{box-sizing:border-box;text-rendering: optimizeLegibility!important;} html{ /* Flat on purpose — the gradient is on .content. See --mp-pane-bg. Everything that sits on is translucent chrome (the rail, the app bar), and a gradient here makes two identical layers resolve to two different colours. */ background:var(--bg); height:100dvh; } /* The DOCUMENT does not scroll — .content does, so the pane always reaches the bottom edge and its rounded corner never moves. Consequence: window.scrollY is permanently 0 and window.scrollTo() a no-op; anything needing the page scroll asks window.mpPageScroller(el) for the nearest scrolling ancestor. */ body{ height:100dvh; overflow:hidden; margin:0; font-family:var(--mp-ff-sans,'Inter',sans-serif); font-size:var(--mp-fs-base,13px); color:var(--text); } a{color:inherit;text-decoration:none} /* ===== Typography ===== */ h1, .page-header h1{ font-size:var(--mp-fs-4xl,32px); line-height:var(--mp-lh-tight,1.1); letter-spacing:var(--mp-ls-tighter,-0.03em); font-weight:var(--mp-fw-black,900); margin-top:0; margin-bottom:0; } h2{ font-size:var(--mp-fs-3xl,24px); line-height:var(--mp-lh-snug,1.25); letter-spacing:var(--mp-ls-tight,-0.01em); font-weight:var(--mp-fw-heavy,800); margin-top:0; } h3{ font-size:var(--mp-fs-xl,18px); line-height:var(--mp-lh-snug,1.25); letter-spacing:var(--mp-ls-tight,-0.01em); font-weight:var(--mp-fw-heavy,800); } strong,b{ font-weight: var(--mp-fw-heavy,800); } .hidden{ display:none; } .card h2{margin-bottom:16px} .section-header h2{margin-bottom:6px} @media(max-width:768px){ h1, .page-header h1{font-size:var(--mp-fs-3xl,24px)} h2{font-size:var(--mp-fs-2xl,20px)} h3{font-size:var(--mp-fs-lg,16px)} } /* ===== Layout ===== */ /* The content column is a SURFACE, not a transparent gutter: it carries the page gradient, one rounded corner where the rail and the bar meet, a z-index above the fixed sidebar so it laps over it, and its own scroll so it is always exactly viewport-high. NOTE FOR ANYTHING ADDED HERE: no transform, filter, backdrop-filter, contain or will-change on this element or its ancestors. Each makes .content a containing block for position:fixed and silently offsets every popover and modal rendered inside the page. tests/behavior/app_shell_pane_test.js asserts it. */ .content{ margin-left: var(--mp-rail); padding: var(--mp-appbar-gap) var(--mp-content-pad) var(--mp-content-pad); border-radius: var(--mp-pane-lap) 0 0 0; background: var(--mp-pane-bg); background-repeat: no-repeat; background-size: cover; /* position WITHOUT z-index, deliberately. The pane has to paint over the fixed rail, and the obvious way to do that — a z-index above the rail's — makes .content a stacking context, which caps EVERY descendant at the pane's own level. Modals are rendered inside the page: position:fixed, z-index 10000, and still painted under the app bar at 60, because 10000 inside a context at 20 is still 20. Measured on the tasks page at v1.12.433: elementFromPoint over the bar returned the bar's search input while a full-viewport modal was open. With both the rail and the pane at z-index:auto they sit on the same level and are painted in DOM order —