/* ==========================================================================
Design System v2.1 โ COMPONENTS
The dashboard shell: wallpaper, greeting, dock, status bar, pills โ plus the
library controls the panels are built from: cards, choice cards, buttons and
text fields.
--------------------------------------------------------------------------
Source: Figma "๐ฅ๏ธ Homepage" (798:407) โ Dashboard_Light 808:5045 /
Dashboard_Dark 808:3988, and the Dock (813:146), StatusBar (812:146) and
SecondaryButtons (811:76) components. The controls come from the panel
frames, which reuse them: ProductTypeCard and Section/FormField appear on the
Lead Times, Resources and Register-a-patient screens alike, which is why they
live here rather than with any one panel.
Consumes role tokens from semantic.css and primitives from scales.css.
Where a value comes straight off the Figma node it's noted with the node id
so it can be re-checked in dev mode.
ONE DEVIATION RUNS THROUGH THIS FILE: the design fixes widths and heights in
px (dock 1201px, pills 185px, bar 404px). Those are replaced with
min-width / min-height plus the designed padding, because the status-bar
panel has an "AA" font-size control โ text that scales inside a fixed box
clips. Same rendering at the default scale, but it survives being turned up.
========================================================================== */
/* โโ Utilities โโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโ
Text for assistive tech only. Used where the design conveys something
visually that a screen reader would otherwise miss โ e.g. the notification
badge, where "2" alone doesn't say two of what.
Not display:none, which removes it from the accessibility tree too, and not
a negative text-indent, which breaks in RTL. The clip-path/1px pattern is
the one that survives every combination. */
.v2-visually-hidden {
position: absolute;
width: 1px;
height: 1px;
margin: -1px;
padding: 0;
overflow: hidden;
clip-path: inset(50%);
white-space: nowrap;
border: 0;
}
/* Skip link. Hidden until focused, then a real, visible control โ a skip link
that never becomes visible is worse than none, because keyboard users can't
tell whether it worked. */
.v2-skip-nav {
position: absolute;
top: var(--space-2);
left: var(--space-2);
z-index: 100;
padding: var(--space-2) var(--space-4);
border-radius: var(--radius-button);
background: var(--surface-raised);
color: var(--text-strong);
font-weight: 600;
text-decoration: none;
transform: translateY(-200%);
}
.v2-skip-nav:focus-visible { transform: translateY(0); }
/* โโ Glass โโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโ
Guidelines ยง8 deliberately doesn't document the effect stack: "these are
complex and layered, so rather than documenting values here, pull the exact
effect settings directly from dev mode."
What the codegen DID give us, exactly, is the fill, border, radius and the
five-stop shadow. What it did NOT give is the blur radius โ Figma's
background-blur doesn't survive the export. So --glass-blur was derived by eye
from the rendered frame, and then reviewed against the design on 11-Aug-2026
and accepted at 20px. Settled, not a placeholder. */
:root {
/* โโ Shell measure โโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโ
1201px is the Dock's designed width (5 ร 205 tiles + 4 ร 34 gaps +
2 ร 20 padding). It doubles as the page's content column, because in the
Figma frame the greeting's left edge (x=120) and the status bar's right
edge (x=1320) both line up with the dock โ the dock IS the measure. So
one centred column of this width puts all three in the right place, at
any viewport, instead of three separate gutter guesses. */
--shell-max: 1201px;
--shell-gutter: clamp(20px, 3vw, 48px);
/* The rhythm down the bottom of the page: dock โ pills โ "Powered by".
ONE value, used for all three gaps, because the mock reads as equal
spacing and mine didn't โ the dock-to-pills gap was 20px while
pills-to-footer came to 44px, assembled accidentally out of a row-gap
plus two paddings. In the frame the measured gaps are 60px and 46px, so
48px sits in the middle of them and lands on the even-number scale. */
--nav-stack-gap: var(--space-12); /* 48px */
/* โโ Glyph translucency: GONE, and deliberately โโโโโโโโโโโโโโโโโโโโโโโ
There was a --dock-glyph-opacity here, 0.78 in light and 1 in dark, to make
the tile glyphs read as translucent in light mode. Its own docblock said
why it was a guess: the light and dark tile gradients were byte-identical,
so the effect had to be a layer opacity or blend mode the codegen had
flattened away, and plain opacity was the predictable stand-in.
Justin's redraw (26-Aug) settles it. The flat set โ now the shipping art โ
draws its glyph as #EFF7F5 at fill-opacity 0.9 IN THE SVG, which is the
translucency the token was approximating. Its own docblock had even noted
that.
So the token was doing it twice (0.9 ร 0.78 โ 0.70), and worse: every tile
is a full-bleed plate now, where three used to be bare glyphs, so it faded
the WHOLE TILE against the wallpaper rather than just the glyph. Daniel,
26-Aug: "in light mode the icons get washed by the background... in the
figma spec they seem to be unaffected by the background change?" They are
unaffected โ the spec renders both themes identically, and now so do we. */
--glass-blur: 20px; /* ESTIMATE โ confirm in dev mode */
/* ONE glass fill, and it is the only thing that changes between themes.
THE CODEGEN'S NUMBERS ARE NOT THE RENDERED RESULT. It reports 25% for light
and 10% for dark, and those were shipped โ but Daniel kept saying dark
looked like "not light mode" (14-Aug), so I measured the frames instead of
trusting the flattened values. Sampling the status-bar pill against the
wallpaper either side of it, in Dashboard_Light 808:5045 and Dashboard_Dark
808:3988, and solving pill = wall*(1-a) + tint*a:
R G B mean codegen
light 0.094 0.086 0.068 0.083 0.25
dark 0.398 0.321 0.320 0.346 0.10
So light is roughly 3x too opaque and dark roughly 3.5x too weak โ which is
exactly why dark read as washed out. The codegen's figures appear to be the
fill layer alone, with whatever Figma's background blur composites on top of
it discarded; see memory/reference_figma_codegen_flattens_effects.md.
DARK IS CORRECTED HERE. Light is left at 25% deliberately: Daniel said light
"feels good", and 8% would make it markedly more transparent than what he has
approved. Flagged for a decision rather than changed underneath him.
Method caveat, because it bounds how much to trust these: backdrop-filter
averages a ~20px neighbourhood, so the true backdrop under the pill is not
quite the strip sampled above and below it. Good to a few percent, not to the
third decimal.
Repointed in the theme blocks below.
The first pass had the dark dock fill and the light pill fill applied at
the same time, so the page rendered as half of each theme. The dock, the
status bar and the pills all take the SAME fill within a theme โ that is
what the two Dock variants show, and it is why there is no longer a
separate pill token to get out of step. */
--glass-fill: rgb(239 247 245 / 25%);
/* Hover on glass. This was MISSING: .v2-pill:hover referenced
--glass-fill-hover with a hardcoded white fallback that nothing ever
overrode, so pill hover โ and the section nav's hover โ was the same white
wash in both themes. On dark glass a white wash is the wrong direction
entirely; the fill should deepen, not lighten.
Same base colour as --glass-fill at a stronger alpha, repointed in the
theme blocks below. Alpha rather than a scale step because this is ยง8
glassmorphism, which is opacity by nature โ the same reason --glass-fill
itself is expressed this way. Eyeballed like --glass-blur, so treat it as
settled-by-review rather than read from the file. */
--glass-fill-hover: rgb(239 247 245 / 42%);
/* โโ The glass edge โโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโ
NOT a flat 1px border. Figma reports the stroke as a single
rgba(255,255,255,0.4), but that is the codegen flattening it โ in the
file it's a gradient stroke reading as a highlight catching the rim of
the glass: bright along the top, almost gone across the middle, picking
up again at the bottom edge. A uniform hairline reads as a plastic
outline instead, which is what mine looked like.
Applied to the dock panel, the status bar, the pills AND the app tiles.
Same treatment on all of them, because it's one material. */
--glass-stroke: linear-gradient(
170deg,
rgb(255 255 255 / 72%) 0%,
rgb(255 255 255 / 26%) 18%,
rgb(255 255 255 / 7%) 45%,
rgb(255 255 255 / 10%) 62%,
rgb(255 255 255 / 46%) 100%
);
--glass-stroke-width: 1px;
/* The five-stop shadow, verbatim from the Dock node. The first stop is
fully transparent โ it's in the design, and it's how Figma expresses a
shadow that only starts contributing further down the stack. Kept so
this matches the file exactly rather than looking "cleaned up". */
--glass-shadow:
0 119px 33px rgb(0 0 0 / 0%),
0 76px 30px rgb(0 0 0 / 2%),
0 43px 26px rgb(0 0 0 / 7%),
0 19px 19px rgb(0 0 0 / 12%),
0 5px 10px rgb(0 0 0 / 14%);
/* THE SAME SHADOW, AS A FILTER. Justin, via Daniel 8-Sep: "adding a shadow
to the logo. mirroring the shadow effect from the status bar."
It cannot be the box-shadow above. The logo is artwork on the wallpaper,
not a surface: box-shadow follows the ELEMENT BOX, so it would draw a
rectangle behind a round mark. drop-shadow follows the rendered alpha, so
it traces the disc and the wordmark.
FOUR PASSES, NOT FIVE. The box-shadow keeps a 0%-alpha first stop to match
the Figma node verbatim; each drop-shadow here is a real filter pass over
the element, and one that paints nothing is pure cost. The four that carry
the weight are kept at their own offsets and alphas.
Declared beside --glass-shadow rather than inside the brand rules so the
two stay recognisably the same shadow expressed two ways. */
--glass-shadow-filter:
drop-shadow(0 76px 30px rgb(0 0 0 / 2%))
drop-shadow(0 43px 26px rgb(0 0 0 / 7%))
drop-shadow(0 19px 19px rgb(0 0 0 / 12%))
drop-shadow(0 5px 10px rgb(0 0 0 / 14%));
/* Text over the wallpaper. NOT --text-body: this text sits on a
photograph, not on a surface, so it takes its own roles.
These do NOT change between themes, and that is per the design rather
than an oversight โ both Dock variants use Seafoam 60% for labels and
both SecondaryButtons variants use white 50%. Guidelines ยง2 says as much:
"Most colours stay the same across both modes." The wallpaper is the
constant here, so what sits on it is constant too. */
--on-wallpaper: rgb(255 255 255 / 100%);
--on-wallpaper-muted: rgb(255 255 255 / 78%);
--on-glass-label: rgb(239 247 245 / 85%);
}
/* โโ Theme: dark โโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโ
Three states, same pattern as semantic.css, because the portal's theme can be
'light', 'dark' or 'auto' โ and 'auto' stamps no attribute at all, so it has
to be caught by prefers-color-scheme. Defining the dark fill ONLY under
[data-theme="dark"] would leave every 'auto' user on the light glass
regardless of their OS. */
@media (prefers-color-scheme: dark) {
:root:not([data-theme="light"]) {
--glass-fill: rgb(58 74 80 / 35%); /* measured, not the codegen's 10% */
--glass-fill-hover: rgb(58 74 80 / 46%); /* deepens, not lightens */
}
}
:root[data-theme="dark"] {
--glass-fill: rgb(58 74 80 / 35%); /* measured, not the codegen's 10% */
--glass-fill-hover: rgb(58 74 80 / 46%);
}
.v2-glass {
background-color: var(--glass-fill);
-webkit-backdrop-filter: blur(var(--glass-blur));
backdrop-filter: blur(var(--glass-blur));
box-shadow: var(--glass-shadow);
}
/* The gradient rim. A gradient can't be a `border`, and border-image ignores
border-radius, so it's drawn as an inset pseudo-element masked to a ring:
two masks, one clipped to the content box, XOR'd so only the padding-width
band survives. border-radius: inherit keeps it following each shape โ 44px on
the dock, 999px on the pills, 24px on the tiles โ without restating any of
them. */
/* .v2-modal-panel joins them for the RIM ONLY โ see the note on its own rule
in overlays.css. It keeps an opaque background: a translucent modal sits over
a dimmed page rather than a photograph, and there is nothing behind it worth
seeing through at the cost of the text on it. */
.v2-glass,
.v2-pill,
.v2-dock-plate,
.v2-modal-panel { position: relative; }
.v2-glass::before,
.v2-pill::before,
.v2-dock-plate::before,
.v2-modal-panel::before {
content: '';
position: absolute;
inset: 0;
z-index: 2; /* above the tile artwork, below nothing */
border-radius: inherit;
padding: var(--glass-stroke-width);
background: var(--glass-stroke);
-webkit-mask: linear-gradient(#000 0 0) content-box, linear-gradient(#000 0 0);
mask: linear-gradient(#000 0 0) content-box, linear-gradient(#000 0 0);
-webkit-mask-composite: xor;
mask-composite: exclude;
pointer-events: none; /* never intercept a click on the tile */
}
/* Without backdrop-filter the panels are a flat tint over a photograph and the
labels inside them become unreadable. Firefox shipped it long ago and every
current target supports it, but the failure mode here is "text on a photo", not
"slightly flatter panel" โ so it gets a real fallback rather than being left to
chance.
These stay well above --glass-fill even now that dark is 35%: with no blur there
is no averaging to mute the photograph, so the tint has to do all the work. */
@supports not ((backdrop-filter: blur(1px)) or (-webkit-backdrop-filter: blur(1px))) {
.v2-glass { background-color: rgb(58 74 80 / 62%); }
.v2-pill { background-color: rgb(58 74 80 / 55%); }
}
/* โโ Shell & wallpaper โโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโ
The wallpaper is a real photograph, full-bleed, and every piece of text on
this screen sits over it. In Figma it's drawn 1766ร1145 inside a 1440ร1024
frame โ i.e. deliberately over-scaled and cropped โ so object-fit: cover
reproduces the intent at any viewport.
It's an ![]()
inside the shell rather than a CSS background-image so it can
carry srcset: a background-image can't, and this is the heaviest asset on
the entry page. */
/* A BUILD STAMP THE PAGE CAN REPORT ON ITSELF, printed by ?qdiag=1 alongside the
JS one. Not vanity: I have no server access, so "is the deployed file the file I
wrote" is not a question I can answer, and asking Daniel to search a .js file on
a phone was a daft thing to ask. Two numbers in a corner settle it instead.
BUMP BOTH WHEN EITHER CHANGES, or the pair stops meaning anything. */
/* โโ THE INCOMING BUBBLE'S FILL, PER THEME โโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโ
Light is the frame's #D8EDE9 = seafoam-300, one step darker than the
seafoam-200 page so the bubble is distinguishable from it. Dark keeps the
near-white it already had, which is what its own frame shows.
Both dark selectors, following the pattern this file uses at line 236: the
media query for anyone whose theme is auto, and the attribute for an explicit
choice. layout.php always writes data-theme now, so the media query is belt
and braces rather than load-bearing โ but it costs two lines and it means the
rule does not depend on that staying true. */
:root { --v2-q-theirs: var(--colour-seafoam-300); }
@media (prefers-color-scheme: dark) {
:root:not([data-theme="light"]) { --v2-q-theirs: var(--colour-seafoam); }
}
:root[data-theme="dark"] { --v2-q-theirs: var(--colour-seafoam); }
:root { --v2-q-build: 42; }
.v2-shell {
position: relative;
min-height: 100vh;
min-height: 100dvh; /* dvh so mobile browser chrome doesn't crop the dock */
overflow: hidden;
display: grid;
grid-template-rows: auto 1fr auto;
/* Everything in this shell sits on a photograph, not on a surface, so the
DEFAULT text colour here is the on-wallpaper one โ not body's --text-body,
which is near-black Flint in light mode and correct only for text on a
panel. Setting it once at the shell means anything added later is legible
by default instead of inheriting the wrong default and needing a patch.
Element-level rules still win over inheritance, so headings and links
inside the shell must state their colour explicitly regardless. */
color: var(--on-wallpaper);
}
/* โโ THE DOCUMENT IS EXACTLY ITS CONTENT โโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโ
queries.js sets data-v2-q-fit on while a thread fills the screen.
Daniel, 9-Sep: "keyboard collapsed is fine, but open it pushes the panel up
off screen... do we treat the top the screen as page edge and allow for scroll
so you can see the very first message by scrolling and it comes into view on
the screen?"
Yes โ and it is one declaration rather than a mechanism. min-height is what
made the page the wrong size in BOTH directions:
TOO TALL with no keyboard. body is min-height: 100vh, and 100vh on iOS is
the LARGE viewport โ the height the page would have with Safari's toolbars
retracted, not the height it has โ so there was ~75px of nothing below
everything to scroll into. That is what the lock was for.
TOO SHORT with one. The lock left NO range at all, so when the panel became
taller than the visible area its top went above the screen and stayed there:
"i have no way to scroll the content into view".
Taking the floor away answers both, because the document then measures itself.
Panel fits: content is the screen, range is zero, no dead space. Panel
overshoots: the range IS the overshoot, so scrolling to the top brings the
first message into view with nothing beyond it. The top of the screen becomes
the page edge, which is what was asked for.
AND IT NEEDS NO MEASUREMENT, which after a day of measuring is the part worth
recording. Every previous attempt computed a number โ a margin, a cap, a
scroll target โ and each was wrong in some state I could not see from here. A
document with no minimum height is right in every state by construction,
including the ones I have not thought of.
THE SHELL TOO, or it holds the floor up on the document's behalf: it carries
its own min-height: 100dvh. The wallpaper is position: fixed so it covers the
screen regardless, and the panel's height is explicit, so nothing here depends
on the shell being viewport-sized. */
html[data-v2-q-fit] body,
html[data-v2-q-fit] .v2-shell { min-height: 0; }
/* โโ AND A DEFINITE HEIGHT, SO THE BROWSER CAN DO THE SLIDE โโโโโโโโโโโโโโโโโโโ
Daniel: "it should be a clean singular movement as keyboard comes up from the
bottom the chat should move up as if sliding."
His readout is what makes this possible, and it contradicts an assumption a
day of work rests on: "inner 428 vv 428" โ the LAYOUT viewport shrinks for
the keyboard on this device. interactive-widget=resizes-content in the
viewport meta is being honoured, which iOS was not supposed to do.
Which means the browser will relayout the whole page itself, in ONE pass, as
the keyboard slides โ and queries.js setting a pixel height off viewport
events is a SECOND mechanism moving the same panel a frame later. Two things
animating one box is the shift he can see. The fix is not a better height; it
is one fewer thing computing it.
So the chain gets a definite height and the panel takes 100% of it. dvh
follows the layout viewport, so when the keyboard arrives every box from the
shell down resizes in the browser's own single reflow, with no JavaScript in
the path at all.
THIS IS THE DESKTOP CHAIN, NOT A NEW ONE: overlays.css:854 does exactly this
above 1025px โ height: 100dvh on the shell, min-height: 0 on .v2-dash-mid and
.v2-section so the 1fr row can shrink below its content. It was never applied
on a phone because iOS was assumed not to resize. It does. */
/* โโ NO DEFINITE-HEIGHT CHAIN HERE, AND IT WAS WORTH TRYING โโโโโโโโโโโโโโโโโโโ
The idea was sound and Daniel's own numbers supported it: "inner 428 vv 428"
means the LAYOUT viewport shrinks for the keyboard on his device, so the
browser relayouts the page itself and queries.js setting a pixel height is a
second mechanism moving the same box โ which is the shift he can see. Give the
chain a definite height, let the panel take 100% of it, and the browser does
the slide in one reflow.
It put the composer under Safari's bottom bar, twice: once with 100dvh (which
is not reliably the current viewport on iOS) and again with 100% from the
root. Something between the shell and the panel does not measure the way I
think it does, and after two attempts I am not going to find it by reasoning
from here.
So the pixel height is back. It was MEASURED and it was right โ his readout
said avail 604, got 604, bot 775 with the fold at 775 โ and a correct composer
position is worth more than a smoother transition. The single-slide is a real
improvement and it is still available: it needs someone who can watch the
layout while changing it, not another blind pass at the end of a long day. */
/* โโ AND THE PAGE DOES NOT BOUNCE โโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโ
Daniel, 9-Sep: "i am able to scroll and create a bigger gap between the
composer and the keyboard... composer box shouldnt move".
Nothing is scrollable here โ the document is exactly its content and the
conversation has its own box โ but iOS lets a drag RUBBER-BAND the document
anyway, and that carries everything with it, composer included. It springs
back, which is why it reads as a gap appearing rather than a scroll position
changing.
NOT SCROLL CHAINING, which was the obvious guess and was already handled:
.v2-q-messages carries .v2-scroll, and that has overscroll-behavior: contain,
so reaching the end of the conversation has never dragged the page. This is
the document's own bounce, which is a separate behaviour and needs the root to
refuse it.
WHAT THIS CANNOT DO, stated so the next person does not go looking: if the
whole view still shifts, that is iOS panning the VISUAL viewport inside a
layout viewport that stays full height behind the keyboard. No CSS reaches
that โ it is not document scroll โ and every attempt to answer it by moving
the panel instead made things worse. */
html[data-v2-q-fit],
html[data-v2-q-fit] body { overscroll-behavior: none; }
/* โโ AND NO PAGE SCROLL, FOR THE WHOLE TIME A THREAD IS UP โโโโโโโโโโโโโโโโโโโโ
Not merely while a keyboard is, which is where this was and why Daniel could
still beat it: "still seems to do it if im fast enough. i scroll down and i
can see the page trying to scroll rather than the chat window."
Of course he could. Between the tap and iOS reporting the smaller viewport the
document really is taller than the screen, and iOS decides who owns a gesture
at TOUCH-START โ so a rule that arrives with the keyboard arrives after the
race is already lost. I tried closing that window from the focus event, and it
was both still too late and the cause of a second fault (see the note in
queries.js about the blocky transition).
There is no window if the rule is never absent. A mobile thread never wants
the document to scroll โ with the keyboard down it is exactly the screen, and
with one up the conversation scrolls in its own box โ so it is simply off
throughout, and there is no longer anything to time correctly.
overflow rather than the height caps tried earlier today: capping the heights
of body and .v2-shell also removes page scroll, and takes the CONVERSATION'S
scroll with it, because that depends on an unbroken chain of definite heights
from the shell down. overflow leaves every height alone. */
html[data-v2-q-fit],
html[data-v2-q-fit] body { overflow: hidden; }
/* NO touch-action HERE, AND THE REASON MATTERS. I put it as none on the panel with
pan-y on the conversation, meaning "only the chat may scroll". It does the
opposite: the property INTERSECTS down the ancestor chain, so none on an ancestor
disables panning for the whole subtree and a descendant cannot win it back.
Daniel, 9-Sep: "there is no scroll for the chat window and only a scroll on the
panel itself" โ exactly backwards, and exactly what the spec says happens.
So it cannot be done from an ancestor. If gesture confinement is wanted it has to
go on the siblings that are NOT the conversation โ the head, the composer row โ
never on anything the scroller sits inside. Left out rather than half-done: the
readout says the page gains 347px of range during the keyboard transition (WORST
max 347, off 347) and that is still unexplained. Better an unexplained transient
than a chat that cannot scroll at all. */
/* โโ WITH A KEYBOARD UP, THE SCREEN TOP IS THE CHAT TOP โโโโโโโโโโโโโโโโโโโโโโโ
queries.js sets data-v2-q-keyboard on while a keyboard is up under a
mobile thread. It sets it nowhere else, so no media query is needed here โ the
attribute IS the condition.
Daniel, 9-Sep: "when keyboard opened, the top of screen becomes the top of
chat window. scroll bar within that and the bottom. scrolled all up is top of
chat, all down is bottom of chat, collapse keyboard brings full panel back
down."
THREE THINGS GIVE WAY, and they are the three things above the conversation:
the dots row, the band of wallpaper below it, and the thread's own head. A
keyboard leaves about 320px of screen; those three were spending roughly 175
of it on a back button, a photograph and a title that has just been read,
which left the conversation about a message and a half. That is the squashing.
IT IS A LAYOUT CHANGE AND NOT A SCROLL ONE, which is why a day of scroll work
never touched it. Nothing here moves the page: the boxes above the panel stop
taking room, the panel's measured height (vv.height - its own offset) then
resolves to the whole visible viewport, and .v2-q-messages scrolls between the
top of the screen and the composer โ scrolled up is the first message,
scrolled down is the last, and the composer never moves because it is not what
scrolls.
ALL OF IT COMES BACK when the keyboard goes, because the attribute goes: "the
full panel back down". */
html[data-v2-q-keyboard] .v2-dash-top { display: none; }
html[data-v2-q-keyboard] .v2-shell[data-v2-view="section"] .v2-dash-mid {
padding-top: 0;
}
/* THE WHOLE HEADER BLOCK, not just the title row. It was .v2-q-thread-head when
that was the only thing above the conversation; the disclosure and the order
reference joined it and are the same kind of thing โ context you want before
you start typing, not while you are. One element means one rule, and it also
means this cannot lose on specificity to the mobile show rules the way three
separate selectors would have. */
html[data-v2-q-keyboard] .v2-q-thread-top { display: none; }
/* Rows are assigned EXPLICITLY rather than left to source order.
The shell has five children, two of which are the wallpaper layers. Relying
on order put the in row 1 and the status bar in the 1fr row, which
stretched the bar into a 460px-tall lozenge. Naming the rows means adding or
moving a layer can't silently reshuffle the layout. */
.v2-dash-top { grid-row: 1; }
.v2-dash-mid { grid-row: 2; }
.v2-poweredby { grid-row: 3; }
/* The must be out of flow too, not just the ![]()
inside it. A fixed
child doesn't take its parent out of flow, so the picture itself was still a
grid item occupying a row. */
.v2-wallpaper-layer {
position: fixed;
inset: 0;
z-index: 0;
display: block;
}
.v2-wallpaper {
position: fixed;
inset: 0;
z-index: 0;
width: 100%;
height: 100%;
object-fit: cover;
/* Pale wallpapers would wash out the white greeting, and nurses choose
their own โ so the scrim is not decoration, it's what makes a
user-chosen background safe to put text on. Kept deliberately gentle;
it reads as depth rather than a filter. */
filter: brightness(0.92) saturate(1.02);
}
/* The scrim proper: strongest behind the greeting (top-left), clearing by the
middle so the photograph is still the photograph. */
.v2-wallpaper-scrim {
position: fixed;
inset: 0;
z-index: 1;
pointer-events: none;
background:
linear-gradient(160deg, rgb(23 30 32 / 38%) 0%, rgb(23 30 32 / 10%) 45%, transparent 70%),
linear-gradient(0deg, rgb(23 30 32 / 22%) 0%, transparent 35%);
}
/* THE DIMMED WALLPAPER BELONGS TO SECTION VIEW, NOT TO DARK MODE.
-----------------------------------------------------------------------------
Solved 14-Aug, and Daniel spotted it: "from the dashboard to the panels the
background has a deeper fade".
The Wallpapers canvas (803:2105) holds TEN symbols, not five โ every flower has a
"Dimmed" twin (1038:8188/8192/8195/8199/8202). I first assumed those were dark
mode's, measured the difference as Flint @ ~22%, and shipped it. That was wrong:
Dashboard_Dark (808:3988) and Dashboard_Light (808:5045) are pixel-for-pixel
IDENTICAL in their wallpaper, ratio 1.000, so it was reverted with the note that
the variants were unexplained.
They are explained now. Comparing the DASHBOARD frame against a SECTION frame
(LeadTimes/Desktop/Dark 1300:1644) at three separate wallpaper regions:
top-left implied Flint alpha 0.205
lower-left 0.208
far right edge 0.210
the Dimmed variants themselves 0.215 / 0.223
Same treatment, within measurement error. Opening a panel pushes the background
back โ which is why the glass and the panel read with more depth in the section
frames than the dashboard ones.
TRANSITIONED, per Daniel's own suggestion, because this is exactly the kind of
shift his "continuous but not abrupt" note is about: the wallpaper darkening as
you move into a section is one of the few moments where the whole surface changes
at once. 260ms โ the layout tier rather than the content tier.
AND THE LAST LINE OF THIS NOTE WAS WRONG. It said "no extra assets: one overlay
on the scrim reproduces the Dimmed variants, so the wallpaper selector will
never need to ship them either." The alpha it measured was right; the
conclusion was not. The Dimmed twins are BLURRED as well as dimmed, which an
alpha comparison cannot see and which Figma's codegen drops. Daniel, 8-Sep:
"when navigating away from the dashboard the background blurs which it doesnt
currently."
So the dim moved off this element and onto the image that carries the blur with
it โ see .v2-wallpaper--dimmed below. This scrim is back to the two gradients it
is declared with, and its background-color transition went with the rule that
used to animate: nothing changes that property any more. */
/* THE SECTION DIM IS NOT THE SCRIM'S JOB ANY MORE. It was
background-color: rgb(58 74 80 / 21%) here, reproducing the "Dimmed"
wallpaper twin with an overlay. That twin turns out to be blurred as well as
dimmed, so it now ships as its own image (see dashboard.php) โ and the image
already carries the dim. Leaving this would darken it twice. */
/* โโ Off the dashboard, the wallpaper blurs โโโโโโโโโโโโโโโโโโโโโโโโโ
Two stacked images, cross-faded on the view. The blurred one is Justin's
Dimmed twin (1038:8188), so this is an opacity change rather than a
full-screen filter โ cheap to animate, and his artwork rather than my
approximation of it.
260ms and the same easing the scrim used, because this is the same moment
Daniel's "continuous but not abrupt" note was about: the whole background
changing as you move into a section.
The sharp one fades OUT rather than the blurred one simply covering it: both
are opaque, so a straight swap would work visually, but fading the top layer
means only one property animates and there is no frame where both are at
full opacity fighting over the same pixels. */
.v2-wallpaper--dimmed {
opacity: 0;
transition: opacity 260ms ease;
}
/* data-v2-bg, NOT data-v2-view. The view attribute cannot flip until the
outgoing panel has finished fading โ it also hides .v2-section โ so keying
the wallpaper on it meant coming home waited 140ms before starting its own
260ms. overlays.js sets both together going in and clears this one first
coming out, so the two fades overlap. */
.v2-shell[data-v2-bg="dimmed"] .v2-wallpaper--dimmed {
opacity: 1;
}
/* Both layers take the dark-mode darkening, so the two agree mid-fade. */
[data-theme="dark"] .v2-wallpaper,
[data-theme="dark"] .v2-wallpaper--dimmed {
filter: brightness(0.9);
}
/* โโ Dark mode darkens the photograph โโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโ
Justin, via Daniel 8-Sep: "was noted to darken the background around 10/20% for
darkmode", then "the backdrop darken will be slight" โ so 10%, the lower end.
THIS REVERSES A 14-AUG FINDING, and the note above records why it was reverted
then: Dashboard_Dark (808:3988) and Dashboard_Light (808:5045) were measured
pixel-for-pixel identical in their wallpaper, ratio 1.000, so a dark-mode dim
was removed as unsupported. It is supported now โ Justin has asked for it โ and
the earlier measurement was right about the frames as they then stood.
A FILTER ON THE IMAGES, and on BOTH of them โ see the rule above, which is where
it now lives. Applying it to each layer rather than to a wrapper is what keeps
the two agreeing halfway through the cross-fade; a single filtered parent would
work too, but the wallpaper has no wrapper that is not also the scrim's.
Not transitioned: the theme switch is a page-level change and the wallpaper is
fixed-position behind everything, so there is no motion to smooth. The blur
cross-fade IS transitioned, because that one happens under a click. */
.v2-shell > *:not(.v2-wallpaper):not(.v2-wallpaper-scrim) {
position: relative;
z-index: 2;
}
/* โโ Entrance โโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโ
Daniel's idea (19-Aug): "the image renders first instantly. what if the
panels fade in 140ms and the Welcome message appears as typed?"
NOT IN THE FIGMA FILE. Motion isn't in those frames, so this is Daniel's
call rather than the spec's โ recorded here because a feel deviation should
be findable, and Justin should see it rather than discover it.
140ms because that is ALREADY the shell's fade duration (FADE_MS in
overlays.js), so the entrance and the panel swap share one motion
vocabulary instead of the page having two. The 60ms lead-in is what makes
the layering legible โ the wallpaper is unambiguously first โ and it is
short enough that nothing reads as withheld.
CSS-ONLY, deliberately, and that decision removes three whole problems
rather than solving them: no deferred script has to run before content is
visible (so it cannot stall or flash), there is no caret to stop blinking,
and prefers-reduced-motion is already handled globally in base.css.
ONE keyframe serves all three effects, and the fill mode is the load-bearing
detail. `backwards` holds the from-value during the DELAY and then stops
applying entirely once the animation is done, so opacity goes back to being
whatever the cascade says. `both`/`forwards` would keep asserting a value
from the animation origin, which outranks author declarations AND transitions
โ that is how an entrance animation quietly breaks a panel's own fade
afterwards. Declaring only `from` for the same reason: nothing here hardcodes
an end value. */
@keyframes v2-enter {
from { opacity: 0; }
}
/* The two wallpaper layers are excluded BY NAME. The rule above excludes
`.v2-wallpaper`, which is the ![]()
and not a shell child at all โ the
child is the , `.v2-wallpaper-layer`. Left as it is there because
it currently renders correctly and stacking order is not something to
change in passing, but this rule must get it right or the wallpaper fades
in with the content and the whole point is lost. */
.v2-shell > *:not(.v2-wallpaper-layer):not(.v2-wallpaper-scrim) {
animation: v2-enter 140ms ease-out 60ms backwards;
}
/* โโ Status bar (closed) โโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโ
812:146. Sits top-right. The open 404ร410 panel โ calendar, weather detail,
the five controls and search โ is a separate component and not in this file
yet. */
.v2-statusbar {
display: flex;
align-items: center;
/* flex-none matters: the bar sits in a flex row whose default align-items
is stretch. Without an explicit cross-axis size it grew to the height of
its row โ with a 999px radius that produced a tall lozenge rather than a
pill. Belt and braces alongside align-items on .v2-dash-top. */
flex: 0 0 auto;
align-self: flex-start;
gap: var(--space-3);
min-height: 45px;
/* Buttons are 33px tall inside a 45px bar, so 6px of vertical padding โ
10px would push the bar past its designed height once the icons grew. */
padding: 6px 6px 6px var(--space-5);
border-radius: var(--radius-pill);
font-size: var(--type-status-size);
font-weight: var(--type-status-weight);
/* Design says white 50%. Over a photograph that is well under AA even for
large text, and this row carries the date and time โ lifted to match the
pills. Same reasoning as --on-glass-label. */
color: rgb(255 255 255 / 82%);
white-space: nowrap;
}
.v2-statusbar-date,
.v2-statusbar-time { font-variant-numeric: tabular-nums; }
.v2-statusbar-temp {
display: flex;
align-items: center;
gap: 6px;
}
/* Controls in the bar are real buttons; the bar itself is not clickable. */
.v2-statusbar-btn {
display: grid;
place-items: center;
min-width: 33px;
min-height: 33px;
padding: 0;
border: 0;
border-radius: var(--radius-pill);
background: transparent;
color: inherit;
cursor: pointer;
}
.v2-statusbar-btn:hover { background: rgb(255 255 255 / 12%); }
/* Explicit sizes. `width: 100%` here was resolving against a shrink-to-fit
button whose own width came from min-width, so the rendered size was
ambiguous and came out smaller than intended.
Figma reports these glyph frames at 18โ19px, but its exported SVGs carry
transparent padding (the vector sits inside negative insets), so drawing them
at the node size renders smaller than the file looks. 22px is the settled
value: 19px read too small, 26px overshot, and this matches the mock. The
avatar is genuinely larger and keeps its own size. */
.v2-statusbar-btn img,
.v2-statusbar-icon {
width: var(--statusbar-icon-size, 22px);
height: var(--statusbar-icon-size, 22px);
display: block;
}
/* The avatar is genuinely bigger in the design โ 33px against the others'
18โ19px โ so it keeps its own size rather than following the icon token. */
.v2-statusbar-avatar { min-width: 33px; min-height: 33px; }
.v2-statusbar-avatar img {
width: 33px;
height: 33px;
}
/* The phone's stand-in for the whole status bar. Circular, 48px โ a real touch
target, and the size the mobile frames draw it at.
IT WAS TWO CONTROLS SHARING THIS GEOMETRY until 10-Sep: .v2-back, the section
view's up-arrow, was declared here so it could not drift from the โฏ it sat
beside โ Daniel asked for "a circle โ button matching the โฏ button", and one
rule for both was the only way to guarantee that. It has moved into the panel
head (.v2-panel-back in overlays.css), where it is a labelled text control
rather than a circle, so its rules left with it and this describes one
button again. */
.v2-mobile-menu {
display: none; /* enabled per state in the media queries */
place-items: center;
width: 48px;
height: 48px;
padding: 0;
border: 0;
border-radius: var(--radius-pill);
color: var(--on-wallpaper-muted);
cursor: pointer;
}
.v2-mobile-menu svg { display: block; }
/* FULLSCREEN (Jake, 15-Oct): its own glass pill left of the status bar (or
the phone's โฏ button), the bar's own height, type, colour and hover wash โ
an icon and "Fullscreen", or "Exit fullscreen" with the inward icon while
on. No frame draws it. On a phone the label goes and it is the โฏ button's
48px circle. Hidden where the browser cannot fullscreen a page. */
.v2-fullscreen {
display: inline-flex;
align-items: center;
gap: var(--space-2);
flex: 0 0 auto;
align-self: flex-start;
min-height: 45px;
margin-right: var(--space-3);
padding: 0 var(--space-4);
border: 0;
border-radius: var(--radius-pill);
font: inherit;
font-size: var(--type-status-size);
font-weight: var(--type-status-weight);
color: rgb(255 255 255 / 82%);
white-space: nowrap;
cursor: pointer;
transition: background-color 140ms ease, color 140ms ease;
}
.v2-fullscreen[hidden] { display: none; }
/* IN THE CORNER, NOT BY THE BAR (Jake, 15-Oct: "move to the top right corner
rather than in the status bar"). From 641px it is pinned to the screen's
own top-right corner, 16px in, above the status bar's row, and a little
more compact than the bar. Phones keep it beside the โฏ button below: their
top row has no spare corner. */
@media (min-width: 641px) {
.v2-fullscreen {
position: fixed;
top: calc(16px + env(safe-area-inset-top, 0px));
right: calc(16px + env(safe-area-inset-right, 0px));
z-index: 30;
min-height: 36px;
margin: 0;
padding: 0 var(--space-3);
}
}
.v2-fullscreen:hover { background-color: rgb(255 255 255 / 12%); color: var(--on-wallpaper); }
.v2-fullscreen svg { display: block; }
.v2-fullscreen .v2-fullscreen-exit,
.v2-fullscreen[aria-pressed="true"] .v2-fullscreen-enter { display: none; }
.v2-fullscreen[aria-pressed="true"] .v2-fullscreen-exit { display: block; }
@media (max-width: 640px) {
.v2-fullscreen {
justify-content: center;
width: 48px;
min-height: 48px;
padding: 0;
}
.v2-fullscreen .v2-fullscreen-label {
position: absolute;
width: 1px; height: 1px;
overflow: hidden;
clip: rect(0 0 0 0);
white-space: nowrap;
}
}
/* Hover, matching the status bar's buttons โ Daniel asked for the back icon to get
"a smooth minor hover effect to match that of the hover effect on the status
bars" (14-Aug). Same 12% white wash those use, and the transition is on the
status-bar buttons too rather than only on the newer control: they had the
wash but no transition, so they snapped. "Smooth" applies to the thing being
matched or they still don't match.
A white wash rather than --glass-fill-hover: these sit ON glass, where a light
lift is what reads as pressable. --glass-fill-hover is for the glass surface
itself, which deepens instead. */
.v2-statusbar-btn,
.v2-mobile-menu { transition: background-color 140ms ease, color 140ms ease; }
.v2-mobile-menu:hover {
background-color: rgb(255 255 255 / 12%);
color: var(--on-wallpaper);
}
/* โโ The top-left slot: brand, or arrow โโโโโโโโโโโโโโโโโโโโโโโโโโโโโโ
Daniel, 7-Sep: "on mobile the logo only shows on the dashboard and becomes a
< arrow as it is everywhere else, going up one level? ... the logo can be
constant on desktop as the back arrows arent present and we have the nav bar
on the side for it."
So the two share one slot and the rules below decide which is in it:
DESKTOP brand always, arrow never (the nav is the navigation)
TOUCH brand on the dashboard, arrow in a section
.v2-dash-top is justify-content: flex-end, so whichever one is present takes
margin-right: auto to sit left while the status bar stays right โ rather than
switching the row to space-between, which would move the bar whenever the
left-hand control changed. Both carry it, since exactly one is ever shown.
NO GLASS PILL ON THE BRAND. Every other floating control in this row is one,
and a wordmark in a bubble is not a control โ it is furniture, and it sits on
the wallpaper the way the greeting does. That is also the distinction the
breadcrumb failed: it was a NAVIGATION control dressed as bare text in a band
whose grammar is pills, which is why it read as orphaned.
THE BOX IS 48px โ THE STATUS BAR'S HEIGHT โ AND THE ARTWORK OVERHANGS IT.
---------------------------------------------------------------------------
It used to be the artwork's own height, which made row 1 of .v2-shell 72px
instead of 48 and pushed the greeting 24px down with it. Daniel, 8-Sep: "the
gap from welcome message to nav buttons is small" โ that gap is what the
greeting ate on its way down.
Holding the box at the bar's height puts row 1 back to the height the frame
measured the 64px bar-to-greeting gap against, so the greeting returns to its
designed position and the space below it comes back. The artwork simply
overflows the box; nothing clips it, and .v2-dash-top has 120px of padding
above.
--v2-brand-h IS THE ARTWORK'S height, separate from the box, so the two can
differ and the transforms below can be expressed against it. */
.v2-brand {
--v2-brand-h: 64px;
display: inline-flex;
align-items: flex-start;
height: 48px;
margin-right: auto;
padding: 0;
border: 0;
background: none;
/* Drives the WORDMARK, which is inlined as currentColor โ see the note below
for why it does not vary. Not the mark: that is a knockout, so its B is the
page behind it and no colour here can reach it. */
color: var(--colour-seafoam);
cursor: pointer;
}
/* THE MARK ON TOUCH, THE LOCKUP ON DESKTOP. Daniel, 7-Sep: "Full on Desktop
(BBrease). logo only on Mobile (B)". Both are in the markup and one is hidden,
which costs nothing now they are inlined rather than fetched.
block on the wrapper so it cannot add an inline box's descender space under
the artwork. */
.v2-brand-art {
display: block;
}
.v2-brand-art--lockup {
display: none;
}
/* HEIGHT DRIVES, WIDTH FOLLOWS, which is what lets one rule serve two very
different artworks: the mark is 993x1031 and the lockup 2800x1031, so at a
shared height the lockup simply takes more room across. width: auto beats the
root width attribute the export carries, and the viewBox supplies the ratio. */
.v2-brand-art svg {
display: block;
height: var(--v2-brand-h);
width: auto;
/* NO SHADOW ON THE LOGO, for now. It carried --glass-shadow-filter to mirror
the status bar; Daniel, 8-Sep: "remove the drop shadow on the icon logo. i
want to see hwo it looks."
The token stays declared beside --glass-shadow, because putting it back is
this one line and it documents how that shadow is expressed for artwork
rather than for a surface: on the SVG so the filter sees the artwork's own
alpha and traces the disc, not the button's rectangle. */
}
/* โโ What lines up with the status bar โโโโโโโโโโโโโโโโโโโโโโโโโโโโโโ
Daniel, 8-Sep: "the logo is currently sitting slightly lower than inline with
the status bar as it should be the Brease word that sits in line - currently
its using the B."
Right, and the two artworks need different answers, so each gets its own.
Both are DERIVED from Justin's frame rather than nudged:
THE LOCKUP centres its WORDMARK on the row. In Logos/Primary (2110:19166) the
frame is 1030.8 tall and the wordmark group sits at y=252.12 with height
474.29, so its centre is at 489.265 โ 47.465% of the height, not 50%. The mark
spans the full height, which is exactly why aligning the artwork's own box put
the B on the bar's line and the word below it.
THE MARK centres its own box, because on a phone there is no wordmark to align
and the โฏ button is what it sits beside.
transform, not margin: it must not change the 48px box that row 1 is sized
from, or the greeting moves again. */
.v2-brand-art--lockup svg {
transform: translateY(calc(24px - var(--v2-brand-h) * 489.265 / 1030.8));
}
.v2-brand-art--mark svg {
transform: translateY(calc((48px - var(--v2-brand-h)) / 2));
}
/* 72px ON DESKTOP, WHERE THE LOCKUP IS. Daniel, 7-Sep: "still i feel the welcome
message is bigger than the lgo not sure its right?" โ the greeting is 64px
(--type-greeting-size), so at 72 the brand is taller than the type beside it,
and at 3:1 it is 215px across where the mark was 64. The width is what actually
answers him; the extra 8px of height stops it reading as the smaller thing.
The greeting itself is left alone deliberately: 64px is the frame's own number
for it, and shrinking the page's headline to flatter the chrome is the wrong
way round.
Touch keeps 64: the mark is square, so 72 there would cost 8px of a phone's
header for no width gained. */
@media (min-width: 1025px) {
/* The ARTWORK grows; the box stays 48px so row 1 does not. */
.v2-brand {
--v2-brand-h: 72px;
}
.v2-brand-art--mark {
display: none;
}
.v2-brand-art--lockup {
display: block;
}
}
/* NO HOVER EFFECT. There was an opacity lift; Daniel, 7-Sep: "shouldnt be a hover
effect on the logo." A brand mark is not a button even when it is clickable, and
cursor: pointer above still says it can be. Nothing is lost on the keyboard
side: base.css carries a global :focus-visible ring, which is what that rule was
doubling up on. */
/* โโ The B and the wordmark follow the theme โโโโโโโโโโโโโโโโโโโโโโโโโ
Justin, via Daniel 8-Sep: light mode is "the seapink with the White
throughout"; dark mode is "the darker Brease word with B filling". Both values
are already tokens here โ Seafoam and Harbour 700 โ and both the B and the
letters are #EFF7F5 in his artwork, so ONE declaration drives both. The coral
disc and the dot are #D96865 and stay coral in both.
I flagged that this puts a dark wordmark on a wallpaper that is itself being
darkened for dark mode, and Daniel confirmed it is what Justin wants. Measured
rather than argued: the ground behind the brand is #647377 after the scrim,
and at the 10% dark-mode darkening below it becomes luminance 0.129, where
Harbour 700 holds 3.6:1. The wordmark is large text at every breakpoint, so
that clears AA's 3:1 โ see the greeting note for the one case that does not.
[data-theme] rather than prefers-color-scheme: the attribute is on and
is always exactly light or dark (layout.php resolves it), so there is no third
state to fall back for.
NOT the wallpaper, which is the axis Daniel and I landed on yesterday and is
still the right one for a SECOND wallpaper โ see ui_wallpapers(). This is the
theme because Justin has drawn two theme states for one wallpaper; the two
axes multiply rather than compete. */
[data-theme="dark"] .v2-brand {
color: var(--colour-harbour-700);
}
/* โโ Superseded: the wordmark used not to vary โโโโโโโโโโโโโโโโโโโโโโ
Seafoam throughout, set once on .v2-brand above. It went deep harbour on the
light theme for one revision; Daniel, 7-Sep: "I dont like the dark brease in
light mode", and then, having worked out the actual rule: "i think the logo
should match ther wallpaper in fact not the theme... for now lets just have
knockout logo with the white brease throughout for desktop (from Dashboard
onwards)."
SO NO CONDITIONAL AT ALL, AND THAT IS THE POINT. Following the theme was
wrong: the theme changes the panels, not the photograph this sits on, so a
dark wordmark landed over a dark photo the moment the two disagreed. Following
the WALLPAPER would be right โ it is what Justin's Dark/Light naming means,
since those name the ground a logo is placed on โ but there is one wallpaper
today, and building the switch before there is a second thing to switch to
would be machinery with nothing to do.
THE DURABLE FIX IS DANIEL'S, and it is bigger than a light/dark flip: a
mapping in the admin portal of which of Justin's seven accents may go with
which wallpaper, because the constraint is CLASHING and not luminance. He is
picking those pairs. Logged in the redesign log; nothing here should try to
anticipate it.
THE SEAM STAYS, though, at a cost of one declaration: the artwork is inlined
with its Seafoam fill rewritten to currentColor, so the colour lives in CSS
where it can be found rather than as a hex inside an SVG. The mark is
unaffected either way โ it is a knockout, so its B is the photograph showing
through and carries no Seafoam at all. See $brandSvg in dashboard.php. */
/* THE BRAND NO LONGER STEPS ASIDE. Retired 10-Sep with the arrow it made room
for.
-----------------------------------------------------------------------------
This used to swap the two below 1025px in section view โ "the logo only shows
on the dashboard and becomes a < arrow as it is everywhere else" โ which is
what left one control in one corner meaning two different things, and left
desktop with no up-control at all.
Daniel, 10-Sep: "if we are dropping the back circle on mobile we should put
the logo there for the consistency of it then and have an always available
back to dashboard button."
So the brand's own display now holds in every view at every width, and there
is no rule here to write: up-one-level lives in the panel head instead
(.v2-panel-back in overlays.css). The .v2-back rules further up went with the
markup; .v2-mobile-menu kept the shape they shared. */
/* โโ Greeting โโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโ
808:4119. Two blocks: the salutation, then a line of real data ("Since you
were last here 12 orders were delivered to your patients"). The number is
emphasised in the design, so it's marked up as and inherits that
weight rather than being styled positionally. */
.v2-greeting {
color: var(--on-wallpaper);
}
/* โโ Dark mode writes the greeting DARK โโโโโโโโโโโโโโโโโโโโโโโโโโโโโ
Justin, via Daniel 8-Sep: "change the welcome text from White to Black."
HARBOUR 700 โ THE WORDMARK'S EXACT COLOUR, AND DANIEL'S CALL AGAINST THE
MEASUREMENT. Do not "correct" this back without asking him.
---------------------------------------------------------------------------
8-Sep: "what about matching the welcome message colour to the dark brease
colour?", and when shown the contrast figures: "i have to disagree with the
math as look at the brease, i think that same colour as the welcome would look
great no? i just feel the black is too dark a contrast."
HE IS RIGHT ABOUT THE THING THE NUMBER CANNOT SEE. Flint 900 beside a teal
wordmark reads as a second, harsher colour; matching them reads as one design.
AND THE NUMBER IS WHAT IT IS. Sampled from bloom-1440.jpg over the region the
greeting actually occupies, after the 38% scrim and the 10% dark-mode dim, the
ground is luminance 0.125 and Harbour 700 holds 1.67:1 โ mean, falling to 1.47
over the lightest part of the flower. Flint 900 held 3.21. AA wants 3:1 for
large text, so this is under half the floor rather than a near miss. I checked
whether I had measured the wrong patch when he pushed back; behind the greeting
is if anything darker than behind the logo, so the figure stands.
WHY IT IS DEFENSIBLE ANYWAY, which is the part worth recording: this is a 64px
Bold salutation and a 28px stat line on a photograph โ chrome, not content. No
clinician acts on "Good morning, Dan"; everything they do act on lives in the
panels, on solid surfaces, at full contrast. The cost of a soft greeting is
aesthetic, and the person who owns the aesthetic has chosen.
THE ONE CASE I WOULD STILL PUT TO JUSTIN: below 640px the stat line drops to
15px, which is normal text wanting 4.5:1 and now sits near 1.6. A 64px
salutation at low contrast is a look; 15px at that contrast is hard to read.
Worth him deciding whether the phone keeps this colour, drops the dim, or holds
that line larger. */
[data-theme="dark"] .v2-greeting,
[data-theme="dark"] .v2-greeting-sub,
[data-theme="dark"] .v2-greeting-sub strong {
color: var(--colour-harbour-700);
}
.v2-greeting-title {
/* color: inherit is load-bearing. base.css colours headings with
`:where(h1โฆh6) { color: var(--heading-colour, var(--text-strong)) }`, and
although :where() contributes no specificity, a colour set ON the element
still beats one inherited from its parent. So this h1 was rendering in
--text-strong โ near-black Flint in light mode โ instead of the white it
inherits from .v2-greeting. Dark mode only looked right by coincidence,
because --text-strong happens to be Seafoam there.
Anything sitting on the wallpaper must state its colour explicitly and
must not rely on inheriting past an element-level rule. */
color: inherit;
margin: 0;
font-size: var(--type-greeting-size);
font-weight: var(--type-greeting-weight);
line-height: var(--type-greeting-leading);
letter-spacing: -0.015em; /* Roboto Bold needs a touch of negative tracking at 64px */
text-wrap: balance;
}
.v2-greeting-sub {
/* 36rem โ the design's 582px greeting block. NOT `ch`: that resolves
against this element's own font size, and on the parent it computed to
~315px and forced the 64px title to wrap onto three lines. */
max-width: 36rem;
margin: var(--space-5) 0 0;
font-size: var(--type-greeting-sub-size);
font-weight: 400;
line-height: 1.3;
color: var(--on-wallpaper-muted);
text-wrap: pretty;
}
.v2-greeting-sub strong { font-weight: 700; color: var(--on-wallpaper); }
/* โโ The typed salutation โโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโ
ONCE PER SESSION, and the server decides โ see $typeGreeting in
views/v2/dashboard.php. Typing it on every load would mean the first thing
a nurse looks at spends half a second looking unfinished, twenty times a
day; charming once, friction thereafter. The decision is server-side rather
than in sessionStorage precisely so this stylesheet can hold the sub-line
back with no risk of a flash: there is no moment where JS has yet to decide.
THE SALUTATION TYPES, THE NAME LANDS WHOLE. Their own name stuttering out a
character at a time is where this tips from warm to gimmicky, and it is the
half they are actually waiting to read. The name is on its own line and is
not split at all.
ZERO REFLOW, which is the reason it is done this way rather than by
appending text. Every character is present from the first paint and holds
its own width; only its opacity changes. Nothing grows, so nothing below it
moves โ the same rule the panels are held to.
The characters are aria-hidden and the real string is repeated once in a
visually-hidden span, so the accessible name of the is the sentence and
not thirteen separate letters. Without JS in the picture, a client with
scripting off gets the same markup and the animation simply resolves.
1ms duration, staggered delay: a character APPEARS rather than fades, which
is what reading a typed line looks like. --i is per character, from PHP. */
.v2-greeting-type > span {
animation: v2-enter 1ms linear
calc(var(--type-lead) + var(--i) * var(--type-step)) backwards;
}
.v2-greeting[data-v2-typed] {
/* THE WHOLE SEQUENCE IS THESE THREE NUMBERS. Everything below is derived, so
the pace is one value to change and nothing drifts out of step.
48ms per character: 38 read as too fast (Daniel, 19-Aug). At 13 characters
("Good Morning,") the line now completes at ~640ms rather than ~520ms,
which is still well short of where a page starts to feel slow.
--type-lead is the wallpaper's head start, shared with the shell entrance.
--type-done is the moment the salutation finishes, and it is what the name
and the stat line hang off โ neither carries a hardcoded delay, so a longer
salutation moves all three together. */
--type-step: 48ms;
--type-lead: 60ms;
--type-done: calc(var(--type-lead) + var(--type-chars) * var(--type-step));
}
/* THE NAME IS PART OF THE RUN, not its own beat.
-----------------------------------------------------------------------------
It first landed whole after the salutation, on my recommendation, and before
that it arrived with the shell fade โ sitting there fully formed while the
line above it was still typing, which is the bug Daniel caught ("the name
printed immediately?"). He then asked for the whole thing typed: "I thought it
would land as a typed entry with the message?"
So the name needs no rule of its own at all. dashboard.php numbers its
characters CONTINUING the salutation's count, so the rule above already types
it, in sequence, across the
. Fewer rules, and the two lines cannot fall
out of step because there is only one clock. */
/* THE MESSAGE FADES IN AFTER THE TYPING, AS ONE THING โ Daniel, 19-Aug: "i think
a fade in should apply AFTER the typing has finished on first load. then acts as
normal after which in session".
-----------------------------------------------------------------------------
It typed too, briefly, and that was wrong twice over. At 66 characters it pushed
the whole entry past two seconds at any readable pace; and a fade is the truer
treatment anyway โ the heading is a greeting being written to you, while this is
a fact arriving. Two different kinds of thing should not move the same way.
Its start is --type-done, the moment the heading's last character lands, plus a
beat to separate them. Nothing here is a hardcoded delay: change the pace or
lengthen the salutation and this follows on its own.
480ms and ease-out โ well slower than the 140ms shell fade, because this one is
meant to be noticed arriving where the shell is meant to be already there. It
was 320ms and Daniel wanted it gentler still (19-Aug: "so it feels more
seperated"), which is the right lever: a longer fade separates the beat by
making the message unmistakably a different gesture from the typing, whereas a
longer delay would only have added a gap of nothing happening.
Scoped to [data-v2-typed], which is what "acts as normal after" means โ on
every later load in the session there is no attribute, no rule, and the message
is simply present with everything else. */
.v2-greeting[data-v2-typed] .v2-greeting-sub {
animation: v2-enter 480ms ease-out calc(var(--type-done) + 160ms) backwards;
}
/* โโ Dock โโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโ
813:146. The primary navigation: five tiles, 205px wide, 34px apart, in a
20px-padded glass panel with a 44px radius. The tiles don't navigate to
pages โ they open overlay panels (see the "โน๏ธ Overlays" canvas), so they're
buttons with aria-expanded, not links. */
.v2-dock {
display: flex;
/* Designed at a 34px gap and 205px tiles, which needs ~1320px of viewport
to render at full size. Rather than overflowing below that, both scale
fluidly and reach the designed values at โฅ1440px. */
gap: clamp(16px, 2.4vw, 34px); /* 808:4813 โ 34px at design width */
align-items: flex-start;
justify-content: center;
/* FULL WIDTH OF THE SHELL COLUMN, and this is load-bearing for alignment.
-------------------------------------------------------------------------
The status bar right-aligns and the greeting left-aligns to the shell
column (--shell-max, capped by the gutter). The dock used to size itself
from its CONTENT instead โ five tiles at clamp(132px, 14.2vw, 205px) plus
four gaps at clamp(16px, 2.4vw, 34px) โ and those two only agree at the
1440 design width, where the tiles happen to land on 205 and fill 1201
exactly.
Below that they diverge, which is the drift Daniel reported. At a 1200
viewport the column is 1128 but the content-sized dock is ~1007, so it
centres with ~60px of slack either side and the status bar's right edge
sits 60px outside the dock's. Same 60px on the greeting's left edge.
Filling the column and letting the tiles flex fixes both edges at every
width โ and at 1440 it still resolves to exactly the designed numbers:
1201 โ 40 padding โ 136 gaps = 1025, over five tiles = 205. */
width: 100%;
padding: var(--space-5); /* 20px */
/* No `border` โ the rim is the gradient stroke on ::before. A border here
as well would double the edge. */
border-radius: 44px; /* 813:146 โ off the radius scale, and
intentionally: this is the one
"fully rounded panel" in the design */
}
.v2-dock-tile {
display: flex;
flex-direction: column;
gap: var(--space-5); /* 20px between plate and label */
align-items: center;
/* Share the dock's width evenly rather than each carrying its own vw clamp.
The clamp was what let the dock end up narrower than the shell column at
mid widths โ see the note on .v2-dock. `flex: 1` divides whatever the
column leaves after the padding and gaps, which IS 205px at 1440, and
min-width: 0 stops the label's text from setting a floor and pushing the
row wide again. */
flex: 1 1 0;
min-width: 0;
padding: 0;
border: 0;
background: transparent;
cursor: pointer;
/* The tile is the click target, so the transition belongs here, not on the
plate โ otherwise the label and plate animate out of step. */
transition: transform 160ms ease, filter 160ms ease;
}
.v2-dock-tile:hover { transform: translateY(-3px); filter: brightness(1.06); }
.v2-dock-tile:active { transform: translateY(0); }
/* The gradient plate. The icon is an exported SVG laid over it โ it carries
both the glyph and the glass highlight, and on two tiles the โ badge is
baked in, so it must be rendered from the asset rather than redrawn. */
.v2-dock-plate {
position: relative;
width: 100%;
aspect-ratio: 205 / 124; /* 808:4816 */
border-radius: var(--radius-panel); /* 24px */
overflow: hidden;
}
/* ONE KIND OF TILE ART, as of Justin's redraw (26-Aug).
-----------------------------------------------------------------------------
There used to be two, and mixing them up was what squashed the icons: two
tiles were full 205ร124 plates while Resources, My Patients and My Orders were
bare glyphs that had to be centred at a share of the plate width, each with a
measured vertical offset to counter the transparent drop-shadow padding in
its export.
All five are now full plates (Figma "Glass_Dark_Flat" / "Glass_Light_Flat",
1909:10199 / 1909:10265), so every one of those special cases has gone โ
along with --dock-glyph-scale, which existed only to size them.
THE ART IS NOW IDENTICAL IN BOTH THEMES, and nothing here should change that.
An earlier pass at this comment argued the CSS gradients below were holding up
a light-mode fade โ that the --dock-glyph-opacity wash revealed the matching
gradient underneath and so only the glyph appeared translucent. Wrong in
practice: it washed the tiles against the wallpaper, which is what Daniel saw.
The wash is gone (see the token's grave in the :root block above) and the
glyph translucency lives in the SVG at fill-opacity 0.9, where Justin drew it.
THE CSS GRADIENTS STAY ANYWAY, on a smaller argument than the one I withdrew.
They are covered by an opaque plate, so they paint nothing โ but they are
exactly the right colours (checked stop by stop: Sea Verge, Open Water, Last
Light, Dune Crest, and Resources' untokenised pair), so a missing or failed
asset degrades to a correctly coloured tile rather than a hole in the dock.
object-fit: contain still matters on mobile, where the plate turns square and
a stretched fill would distort the art. */
.v2-dock-plate img {
position: absolute;
inset: 0;
width: 100%;
height: 100%;
object-fit: contain;
}
.v2-dock-label {
font-size: var(--type-dock-label-size);
font-weight: var(--type-dock-label-weight);
line-height: 1.2;
color: var(--on-glass-label);
text-align: center;
/* The design has these at Seafoam 60%, which over a blurred photograph is
below AA. Raised to 85% via --on-glass-label: still visibly secondary,
but readable. Flagged for Justin. */
}
/* Per-tile gradients, off the Dock node. Four of the five are the palette's
named gradients with a per-tile angle and stop positions โ so they reference
the gradient tokens rather than repeating hexes.
Resources is the exception: its layer is *named* IconGradientShoreline but
its stops (#0A7DB5 โ #5BBF6A) are neither Shoreline's (#0C75A8 โ #72BA7C)
nor any other token's. Left faithful to the design and flagged โ it's
either eyedropper drift or a sixth gradient that never got tokenised. */
.v2-dock-plate--resources {
background-image: linear-gradient(59.66deg, #0A7DB5 0%, #5BBF6A 100%);
}
.v2-dock-plate--add-patient { /* Sea Verge, reversed */
background-image: linear-gradient(226.4deg,
var(--gradient-sea-verge-to) 9.81%, var(--gradient-sea-verge-from) 81.87%);
}
.v2-dock-plate--request-order { /* Open Water, reversed */
background-image: linear-gradient(222.46deg,
var(--gradient-open-water-to) 20.17%, var(--gradient-open-water-from) 76.9%);
}
.v2-dock-plate--my-patients { /* Last Light */
background-image: linear-gradient(58.29deg,
var(--gradient-last-light-from) 9.38%, var(--gradient-last-light-to) 91.43%);
}
.v2-dock-plate--my-orders { /* Dune Crest */
background-image: linear-gradient(58.06deg,
var(--gradient-dune-crest-from) 6.32%, var(--gradient-dune-crest-to) 80.71%);
}
/* โโ Secondary pills โโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโ
811:76. Lead Times and Latest Updates, below the dock. */
.v2-pill-row {
display: flex;
gap: var(--space-2); /* 8px */
align-items: center;
justify-content: center;
flex-wrap: wrap;
}
/* One label is always hidden. Long on wider screens, short on phones. */
.v2-pill-label-short { display: none; }
/* THE BADGE OR ICON SITS SNUG IN THE RIGHT-HAND CURVE; THE TEXT FILLS THE
REST (Daniel, 13-Oct, with the frame: "the numbers or icons on the right
side are snug with the curve of the pill. with the text filling the rest").
SecondaryButtons 808:4205: a 185ร45 pill, its 33px badge 6px in from the
top, bottom and right, so the circle is concentric with the pill's end,
and the text from 14px in.
This used to centre the label and badge together as one group. In a 185px
pill that happens to land on the frame, but wherever a pill is wider (the
tablet and phone rows share the dock's width) the badge drifted in off the
curve. Now the right padding is the badge's 6px at every width, and the
label takes the remaining width with its text centred in it. A pill with no
badge (a count of 0) centres its label across the whole pill. */
.v2-pill {
display: flex;
align-items: center;
justify-content: center;
gap: var(--space-2);
min-width: 185px;
min-height: 45px;
padding: 6px 6px 6px var(--v2-pill-pad-l, 14px);
border: 0;
border-radius: var(--radius-pill);
background-color: var(--glass-fill); /* same fill as the dock, per theme */
-webkit-backdrop-filter: blur(var(--glass-blur));
backdrop-filter: blur(var(--glass-blur));
box-shadow: var(--glass-shadow);
font-size: var(--type-nav2-size);
font-weight: var(--type-nav2-weight);
color: rgb(255 255 255 / 78%); /* design says 50%; lifted for AA */
cursor: pointer;
white-space: nowrap;
}
/* Hover lifts the same fill rather than introducing a colour, so it works in
both themes without a second rule. */
.v2-pill:hover { background-color: var(--glass-fill-hover); }
/* The label: every text span of a pill but the badge and the screen-reader
count (which is out of the flow anyway). */
.v2-pill > span:not(.v2-pill-badge):not(.v2-visually-hidden) {
flex: 1 1 auto;
min-width: 0;
text-align: center;
}
/* With nothing on the right, the 14px / 6px padding would sit the label off
centre: even it up. */
.v2-pill:not(:has(> .v2-pill-icon, > .v2-pill-badge:not(:empty):not([data-count="0"]))) {
padding-right: var(--v2-pill-pad-l, 14px);
}
.v2-pill-icon { flex: none; width: 33px; height: 33px; display: block; }
/* Notification badge โ a count in a filled circle.
-----------------------------------------------------------------------------
The fill comes from --badge-attention / --badge-info; see semantic.css for which
meaning gets which colour and why neither --intent- role could be used directly.
RED IS THE DEFAULT, deliberately. A badge with no modifier is the one that wants
attention, so a caller who forgets the class over-signals rather than under-signals.
The alternative โ no fill on the base โ makes a forgotten class render an invisible
badge, which is the worse failure for a notification.
(Supersedes an earlier note here that put the design's red at #E85E58, a gradient
stop. Pixel-sampling the frame gives #C04644 = sea-pink-600, and #E85E58 is only
3.4:1 under a white digit.) */
.v2-pill-badge {
display: grid;
place-items: center;
flex: none;
min-width: 33px;
min-height: 33px;
padding-inline: 6px;
border-radius: var(--radius-pill);
background-color: var(--badge-attention);
color: #fff;
font-size: 1.0625rem; /* 17px ยท 808:4189 */
font-weight: 600;
font-variant-numeric: tabular-nums;
line-height: 1;
}
/* "New to read" rather than "needs your action" โ Latest Updates, not Order
queries. One modifier, because red is the base. */
.v2-pill-badge--info { background-color: var(--badge-info); }
/* THE COUNT ROLLS (Daniel, 13-Oct: "make sure that the queries counter has a
ticker and a small animation when going up or down in count ... should be
rolling"). shell-figures.js lays the old and new figures out digit by
digit; a digit that changes is a two-row strip that slides one row, UP
when the count rises (the new figure comes from below) and DOWN when it
falls, while unchanged digits stay put, like an odometer. Then the plain
number is put back. Skipped under reduced motion. */
.v2-roll { display: inline-flex; height: 1em; line-height: 1; overflow: hidden; }
.v2-roll-col { display: inline-flex; flex-direction: column; height: 1em; overflow: hidden; }
.v2-roll-strip { display: flex; flex-direction: column; }
.v2-roll-strip > span { display: block; height: 1em; line-height: 1; text-align: center; }
.v2-roll-col--up .v2-roll-strip { animation: v2-roll-up .42s cubic-bezier(.2, .8, .2, 1) both; }
.v2-roll-col--down .v2-roll-strip { animation: v2-roll-down .42s cubic-bezier(.2, .8, .2, 1) both; }
@keyframes v2-roll-up { from { transform: translateY(0); } to { transform: translateY(-1em); } }
@keyframes v2-roll-down { from { transform: translateY(-1em); } to { transform: translateY(0); } }
/* THE DASHBOARD PILLS' TWO BADGES IN THE FRAME'S COLOURS, BUT NOT ITS ORDER
(Daniel, 13-Oct). SecondaryButtons 808:4205 has Order queries as a Seafoam
circle with a Harbour count and Latest Updates in Sea Pink (rendered
#DD645D, the base Sea Pink, not the 600). He: "Queries = red, Updates =
white. Spec is wrong in that aspect": red for what is waiting on you, the
light one for what is new to read. So Queries is --pink, Updates --light.
Pills only: the sidebar's nav badges keep the classes above.
Measured: Harbour on Seafoam 4.7:1; white on Sea Pink 3.4:1, under the 4.5
asked of 17px text (Sea Pink 600 was 5.0). The frame's colour, his call. */
.v2-pill-badge--light { background-color: var(--colour-seafoam); color: var(--colour-harbour); }
.v2-pill-badge--pink { background-color: var(--colour-sea-pink); }
/* A count of zero is not "nothing to see" rendered small โ it's nothing to
see. Hidden outright so the badge never draws attention to an empty state. */
.v2-pill-badge:empty,
.v2-pill-badge[data-count="0"],
.v2-pill-badge[hidden] { display: none; } /* display: grid above would beat [hidden] */
/* THE ICON AT ZERO, THE COUNT OTHERWISE (Daniel, 13-Oct). Queries and Latest
Updates carry their components-page circle (799:1582: speech bubbles,
megaphone) beside the badge; it shows while there is no count, the same
33px circle in the same place as the count, so nothing moves when one
becomes the other. Both are always in the markup, which is also what lets
a count arrive from zero without a reload (shell-figures.js). */
.v2-pill:has(> .v2-pill-badge:not([hidden]):not([data-count="0"])) > .v2-pill-icon--idle { display: none; }
/* โโ Powered by โโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโ
The wordmark in pc-logo-colour.svg is Seafoam, i.e. drawn for a dark ground.
That's correct over these photographs, but if a pale wallpaper is ever added
it will need a dark variant โ noting it here rather than discovering it
then. */
.v2-poweredby {
display: flex;
/* BASELINE, not centre. The wordmark read as sitting low beside "Powered by"
(Daniel, 2026-08-12), and the cause is measurable rather than a matter of
taste: the logo's x-height glyphs bottom out at y=23.27 in a 27.1975-tall
export while the `p` descender runs to 27.20, so its baseline is 3.93px
above its box bottom. Centring the BOX therefore parks the wordmark's
baseline about 5px below the text's.
Aligning on baselines is also the robust choice rather than a nudge: there
is a per-nurse --ui-font-scale preference, and with centring any change to
the text size would shift the relative alignment again. Baselines hold. */
align-items: baseline;
justify-content: center;
gap: var(--space-2);
/* Owns the whole pillsโfooter gap, and matches the dockโpills gap so the
bottom of the page reads as one even rhythm. The frame leaves a similar
margin below the wordmark, so the same value works underneath. */
padding-block: var(--nav-stack-gap);
font-size: var(--type-caption-size);
color: rgb(255 255 255 / 70%);
}
/* A TRANSFORM, NOT A MARGIN โ the margin was inert, which is why three attempts
at this changed nothing.
-----------------------------------------------------------------------------
Under align-items: baseline a flex item's baseline is SYNTHESISED FROM ITS
BORDER BOX when the item has no text of its own. An ![]()
has none, so
margin-bottom moved the box and the baseline alignment compensated straight
back: -3.9px, -1.6px and +2px all rendered identically. The only thing that
ever moved the logo was switching centre โ baseline in the first place, which
overshot upward.
transform: translateY() can't be compensated away โ it is applied after layout
and baseline alignment are settled โ so the nudge actually lands. It also costs
no reflow, which a margin on a footer item would.
THE VALUE IS SET BY EYE AND SHOULD STAY THAT WAY. Don't re-derive it from the
artwork: the mark above the `i` in "choice" is part of the logo and inflates the
export's box upward, so nothing measured from that box describes where the
wordmark's visual weight sits. Two correctly-measured attempts (baselines, then
x-height centres) both looked wrong for exactly that reason โ Daniel's "you have
to almost ignore it" is the accurate read.
3.5px is his 3โ4px, judged from the baseline-aligned position. Positive drops
the logo. TO NUDGE IT: --poweredby-nudge updates live in devtools. */
.v2-poweredby img {
height: 27px;
width: auto;
transform: translateY(var(--poweredby-nudge, 3.5px));
}
/* The .v2-dev-replay rules that were here are gone with the link they styled โ
Daniel, 19-Aug: "can now make it as it would be without the reply message
button". The ?greet=1 URL still replays the welcome; it just has no chrome. */
/* โโ Scroll regions โโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโ
Scrollbar_Vertical_Light 841:4418 / _Dark 841:4849, the masters in the
library's own "Scroll bars" section (841:4852). Instances of them appear
inside the Resources and Register-a-patient panels; the masters and the
instances agree exactly.
track 12px wide, radius 11px, Pebble 100 light / Flint 600 dark
thumb 6px wide, radius 1000px, Rockpool โ inset 3px on every side
TWO DELIBERATE DEVIATIONS FROM THAT, both recorded where they happen.
1. THE THUMB STEPS PER THEME. The file draws it as Rockpool 500 in BOTH
modes, which measured 3.9:1 against the light track and only 2.6:1 against
the dark one โ under WCAG 1.4.11's 3:1 for a control you have to see in
order to use it. --brand-secondary is Rockpool 500 light / Rockpool 300
dark, so the role that fits the design is also the one that fixes the dark
case. Same stepping mechanism as everywhere else, and no new token.
2. THERE IS NO TRACK ANY MORE (26-Aug). The 12px width and the thumb's 3px
inset are kept, but nothing is painted behind it โ the thumb floats on
whatever it is scrolling. It came out of the dropdown, where a
--surface-card channel down a pinned-white list read as a recess cut into
it, and Daniel took it as the global treatment: "definately the scroll bar
we want." The measurements that made it safe are on
::-webkit-scrollbar-track below. --surface-card is therefore no longer
part of this component at all.
THE LIBRARY HAS NO HORIZONTAL VARIANT. Where horizontal scrolling is
unavoidable (a wide table, a code block) use the same treatment and flag it โ
don't invent a second scrollbar.
.v2-gp-results IS IN THE LIST for the same reason, added the same day: the
lookup dropdown caps at a max-height and scrolls, so it too is ALWAYS a scroll
container. Daniel, seeing the OS bar in it: "also fix the styling to our styles
of scroll bar and drop down?" โ both lookups render into this one class, so
Add Patient's picker is fixed by the same line as the edit modal's.
.v2-modal-body IS IN THE LIST TOO, since 18-Sep. Daniel, on the edit modal:
"scroll bar isnt ours, we =keep making that mistake." Keep making it is the
operative part โ every modal that outgrows its dialog drew the OS bar, and
every time the fix was applied to that one modal. .v2-modal-body is
overflow-y: auto unconditionally, exactly like a panel body, so it is a scroll
container ALWAYS and belongs here rather than being opted in per modal. Fixed
for every dialog in the portal at once, which is the only way it stops
recurring.
.v2-panel-body is in the selector list rather than composing .v2-scroll in
markup: a panel body is ALWAYS the scroll container on desktop, so making it
opt-in would only be a thing to forget. Any other scroll region โ the
status-bar panel's results, a long list โ takes .v2-scroll explicitly.
Not inside a media query. On desktop the panel body is what scrolls; on mobile
the window does and this simply has no scrollbar to paint. Styling it either
way costs nothing and means any future scroll region matches wherever it
appears. */
/* THE STANDARD PROPERTIES AND THE WEBKIT PSEUDO-ELEMENTS ARE MUTUALLY EXCLUSIVE.
-----------------------------------------------------------------------------
This is why the arrows survived the first attempt at removing them. In Chromium,
specifying `scrollbar-width` or `scrollbar-color` on an element makes it IGNORE
every ::-webkit-scrollbar-* rule for that element โ so declaring both, as this
did, silently threw away the whole design: the 12px width, the 11px radius, the
inset 6px thumb AND the button-hiding, leaving Chrome's own generic bar with its
steppers.
So the standard properties are gated to engines that have no pseudo-element to
ignore them in favour of โ i.e. Firefox, where `thin` and a two-colour
scrollbar-color is the whole of what's available. `@supports not selector(โฆ)` is
exact about that and needs no browser sniff. */
@supports not selector(::-webkit-scrollbar) {
.v2-scroll,
.v2-panel-body,
.v2-modal-body,
.v2-gp-results,
:root:has(> body.ui-next) {
scrollbar-width: thin; /* no px control here; `thin` is nearest 12px */
/* transparent is how Firefox is told not to draw a track โ see the note
on ::-webkit-scrollbar-track below. */
scrollbar-color: var(--brand-secondary) transparent;
}
}
.v2-scroll,
.v2-panel-body {
/* Reaching the end of a panel shouldn't start dragging the page behind it.
Matters on touch, where the window IS scrollable. */
overscroll-behavior: contain;
}
/* โโ A BAR FILLS ITS SPACE, IT DOES NOT TAKE IT โโโโโโโโโโโโโโโโโโโโโโโโโโโโ
Daniel, 17-Sep: "all scroll bars should fill space, not push intot it".
Stated as a rule, so it belongs on the shared class rather than being fixed
per scroller โ it had already been written out three times in overlays.css by
the time he said it.
A scrollbar takes its width from the CONTENT box, which shifts everything
when it appears and, where the content re-flows, can oscillate: bar appears,
content narrows, a row re-flows, content shortens, bar goes, content widens,
round again. Reserving the width means the content never changes size, so
there is no shift and nothing to feed back.
NOT on .v2-panel-body, deliberately: the request-order panel sets
scrollbar-gutter: auto there on purpose, because its body does not scroll and
the reserved 12px put the head and the basket column on right edges 12px
apart. Adding it here would re-break an alignment that took three attempts.
Safari gained scrollbar-gutter in 18.2; older versions simply behave as they
do today rather than worse. */
.v2-scroll { scrollbar-gutter: stable; }
/* The WINDOW's scrollbar gets the same treatment.
On desktop section view there shouldn't be one at all โ the shell is pinned and
the panel body scrolls โ but the home view is still allowed to grow on a short
window, and mobile scrolls the page by design. When it does appear it should be
the design's bar, not the OS default.
Scoped through the v2 body class so this can't reach a classic page once
ui_next_stylesheets() is wired into header.php. */
.v2-scroll::-webkit-scrollbar,
.v2-panel-body::-webkit-scrollbar,
.v2-modal-body::-webkit-scrollbar,
.v2-gp-results::-webkit-scrollbar,
:root:has(> body.ui-next)::-webkit-scrollbar { width: 12px; }
/* No stepper arrows. The component is a track and a thumb, full stop โ there are
no buttons at either end of 841:4418. WebKit draws them by default and they also
eat 12px off each end of the track, so the thumb's travel stops matching the
design's.
The `:single-button` / `:start:decrement` / `:end:increment` variants are listed
as well as the bare selector: platforms differ in which of them they actually
render, and a bare ::-webkit-scrollbar-button doesn't always win against a
platform default that targets one of the specific states. */
.v2-scroll::-webkit-scrollbar-button,
.v2-panel-body::-webkit-scrollbar-button,
.v2-modal-body::-webkit-scrollbar-button,
.v2-gp-results::-webkit-scrollbar-button,
:root:has(> body.ui-next)::-webkit-scrollbar-button,
.v2-scroll::-webkit-scrollbar-button:single-button,
.v2-panel-body::-webkit-scrollbar-button:single-button,
.v2-modal-body::-webkit-scrollbar-button:single-button,
.v2-gp-results::-webkit-scrollbar-button:single-button,
:root:has(> body.ui-next)::-webkit-scrollbar-button:single-button,
.v2-scroll::-webkit-scrollbar-button:start:decrement,
.v2-panel-body::-webkit-scrollbar-button:start:decrement,
.v2-modal-body::-webkit-scrollbar-button:start:decrement,
.v2-gp-results::-webkit-scrollbar-button:start:decrement,
:root:has(> body.ui-next)::-webkit-scrollbar-button:start:decrement,
.v2-scroll::-webkit-scrollbar-button:end:increment,
.v2-panel-body::-webkit-scrollbar-button:end:increment,
.v2-modal-body::-webkit-scrollbar-button:end:increment,
.v2-gp-results::-webkit-scrollbar-button:end:increment,
:root:has(> body.ui-next)::-webkit-scrollbar-button:end:increment {
display: none;
width: 0;
height: 0;
}
/* Where a vertical and a horizontal bar would meet. Nothing is drawn for it in
the design, and the default is a grey square that doesn't match either track. */
.v2-scroll::-webkit-scrollbar-corner,
.v2-panel-body::-webkit-scrollbar-corner,
.v2-modal-body::-webkit-scrollbar-corner,
.v2-gp-results::-webkit-scrollbar-corner,
:root:has(> body.ui-next)::-webkit-scrollbar-corner { background: transparent; }
/* NO TRACK, ANYWHERE. The thumb floats on whatever it is scrolling.
-----------------------------------------------------------------------------
This started as a fix for the dropdown, whose list is pinned white and where
a --surface-card channel looked like a recess cut into it. Daniel, 26-Aug:
"thats fantastic and definately the global scroll bar we want."
MEASURED ON EVERY SURFACE IT CAN LAND ON before removing it, because the
track was what the thumb used to read against โ 1.4.11 wants 3:1 for a UI
component:
panel body light Rockpool 500 on --surface-page Seafoam 200 4.14:1
panel body dark Rockpool 300 on --surface-page Flint 500 3.63:1
on a card light Rockpool 500 on --surface-card Pebble 100 3.88:1
on a card dark Rockpool 300 on --surface-card Flint 600 4.55:1
The worst case is 3.63:1, which is the dark panel body โ better than the
3.88:1 the light track used to give, so nothing is lost by this.
THE WINDOW BAR IS SAFE TOO, which was the one worth checking: it sits over
the BODY, and the body is a solid --surface-page. The wallpaper is inside
.v2-shell, which the window scrollbar is outside of โ so the thumb never ends
up floating on a photograph, where contrast would be anyone's guess.
Kept as an explicit `transparent` rather than deleted: WebKit draws its own
track otherwise, and a deleted rule reads as an oversight where this reads as
a decision. */
.v2-scroll::-webkit-scrollbar-track,
.v2-panel-body::-webkit-scrollbar-track,
.v2-modal-body::-webkit-scrollbar-track,
.v2-gp-results::-webkit-scrollbar-track,
:root:has(> body.ui-next)::-webkit-scrollbar-track {
background-color: transparent;
}
/* 3px of transparent border with background-clip: content-box turns the 12px
track into the file's 6px thumb AND reproduces its 3px inset on every side โ
one declaration instead of a separate track-piece rule. */
.v2-scroll::-webkit-scrollbar-thumb,
.v2-panel-body::-webkit-scrollbar-thumb,
.v2-modal-body::-webkit-scrollbar-thumb,
.v2-gp-results::-webkit-scrollbar-thumb,
:root:has(> body.ui-next)::-webkit-scrollbar-thumb {
background-color: var(--brand-secondary);
border: 3px solid transparent;
background-clip: content-box;
border-radius: 1000px;
}
/* โโ Cards inside a panel โโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโ
The screens' "ProductTypeCard" / "Section/FormField" container. One shape used
for both: a neutral card on the panel's own surface.
background --surface-card Pebble 100 light / Flint 600 dark
radius 20px --radius-card
padding 20px
Measured on LeadTimes/Desktop/Light 1300:3362 and /Dark 1300:3310; the
Resources and Register-a-patient frames use the same values. */
.v2-card {
display: grid;
/* 30px, which is what every Section/FormField in the file uses between its
heading and its content โ Register's three sections (1300:4887, 1300:4915,
1300:4923) and Lead Times' lookup card all agree. Off ยง6's stated ramp, like
the 10px in a choice card; the frames win. */
gap: 30px;
padding: var(--space-5); /* 20px */
border-radius: var(--radius-card); /* 20px */
background-color: var(--surface-card);
}
/* โโ Forms โโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโ
The