/* The whole app's stylesheet. `templates/base.html` is the only thing that loads it and every page extends that template, so every rule here is on every page. A rule needed by one page goes in its own file loaded through `base.html`'s `{% block extra_css %}` instead (issue #137) -- `account_list.css` first among them; `static/css/` is the current list. A page whose only unique styling is a rule or two keeps it here as a named component class instead; a stylesheet request per page is not worth three lines. It lived inline in base.html until issue #134. Out here WhiteNoise serves it precompressed and under a content-hashed filename, so it is fetched once and read from cache after that; inline, the identical bytes were re-sent with every single page load. They were uncompressed too until issue #141 added `GZipMiddleware`, which is no longer a difference between the two -- the caching is. Which is why the comments below are ordinary CSS comments again. While this was inline, Django's template engine had no idea what one was and shipped it straight through into the HTML -- so the house rule was `{% comment %}`, enforced by a test, and writing down *why* a rule exists cost bytes on every request. Out here it costs nothing on any request. Comment freely. One hazard the old inline form did not have, found by reading computed styles in the browser rather than by any test: a comment that quotes CSS's own closing delimiter ends there, and every rule after it is parsed as garbage until the next brace. This header did exactly that on its first draft, which silently emptied `:root` below and left the app bar transparent while the file still returned 200 and the whole suite still passed. Do not write the delimiter inside a comment -- say "a CSS comment" instead. */ /* The "Refined Clinical" palette at Balanced intensity -- issue #257 is the spec these values come from, decided against three rounds of mockups. Naming, because the restyle added three kinds of token: * plain colour (--accent, --mine, --excluded): the thing's own hue -- fills, borders, rings. * `-ink` (--accent-ink, --mine-ink, --excluded-ink): the text variant, wherever hue-coloured text sits -- tint, surface, or page bg. The plain hue is never a text colour: a hue tuned to carry --on-accent on its fills cannot also clear text contrast, most sharply on the dark palettes (issue #281). Non-text marks keep the plain hue -- the subtab underline, the app bar's aria-hidden alert glyph -- since a mark needs only 3:1 and its meaning lives in adjacent text. A dark theme's -ink is *lighter* than its plain hue. * --on-accent: text sitting on a solid accent/mine/excluded fill. One token rather than #fff at each site so the dark palette can retune it in one place. The pairing is a two-sided constraint (issues #281/#285): a fill must be dark enough that --on-accent clears 4.5:1 on it -- enforced for every theme block by ComposedTextPairsStayReadable (shifts/tests/test_static_assets.py), with the app's other composed text pairs -- while staying light enough to mark at 3:1 against its own tint. Only Light's and Dark's mine/excluded are measured to that second half; Ember's fills and the dark accents sit below it, which is why the guard has no mark side -- one to widen when they retune. On the dark side the window is narrow: retune by measuring, not by eye. --radius / --radius-sm / --radius-ctl is the 12/10/8 scale: cards / grid cells and small panels / controls (buttons, inputs, selects). --shadow is the resting elevation every raised surface wears; --shadow-hi is the raised state a *clickable* element lifts to on hover, plus the one at-rest exception: a panel that genuinely floats over the page body (account_list's row-menu dropdown). Labels (status pills) stay flat -- elevation marks controls, not labels. --bar-*: the app bar's own colours. In this palette the bar is the accent, but the dark palette will split them (its bar is deeper than its accent), so nothing but these tokens may colour the bar. Two literals outside CSS restate them and cannot read tokens -- base.html's theme-color meta and static/manifest.json's theme_color/background_color -- so a palette change edits those two files as well. */ :root { --bg: #f2f5f6; --surface: #ffffff; --surface-2: #fbfcfc; --text: #16262b; --muted: #617277; --accent: #14505f; --accent-ink: #0f4250; --accent-light: #e6f0f2; --on-accent: #ffffff; --mine: #1e8650; --mine-light: #e8f6ee; --mine-ink: #12703f; --excluded: #bd5346; --excluded-bg: #fbebe8; --excluded-ink: #a8422f; --warning: #d9a02c; --warning-bg: #fdf4e5; --border: #e3e9ea; --shift-a: #3f86cf; --shift-b: #bd7f2f; /* The category left bar, spelled once: every surface that draws it in a box-shadow list says var(--cat-bar-a), never the inset literal, so a bar retune is one edit (per category) instead of ten. */ --cat-bar-a: inset 4px 0 0 0 var(--shift-a); --cat-bar-b: inset 4px 0 0 0 var(--shift-b); --radius: 12px; --radius-sm: 10px; --radius-ctl: 8px; --shadow: 0 1px 2px rgba(16,40,48,.05), 0 1px 1px rgba(16,40,48,.04); --shadow-hi: 0 4px 10px rgba(16,40,48,.09), 0 1px 2px rgba(16,40,48,.06); /* The confirm dialog's ::backdrop wash: the theme's text tone at .45, deepened to black in the dark palettes the way the shadows are. A token because ::backdrop is still a page colour a theme must retune, even though only the ever wears it. */ --backdrop: rgba(22,38,43,.45); /* Hover feedback strength, tokens so each theme sets how strong and in which direction: brightness() is multiplicative, so the darken that reads on these light fills barely moves an already-dark one, and a dark-side theme restates both tokens above 1. -lift is every brightness hover's tier (the link chips gave up their own deeper dial in #293's retune -- mint a -deep token at the first chip-only retune, not before). -solid is the exception tier: a fill that wears --on-accent ink is dark in every palette (the contrast suite guarantees the white ink reads on it at rest), so no theme's darken has headroom there -- those controls lighten in every theme. The lighten spends label contrast while the pointer rests: measured at ~3.6:1 on the light side and ~3.4:1 on the dark side against the 4.5:1 rest floor, accepted in PR #294 -- motion and shadow carry the state alongside, and a lighten small enough to hold the floor would be invisible. Wearers are .btn-primary:hover, the assigned/excluded badge hovers and the pressed .toggle-chip's hover -- that is the full roster; a new solid-fill control joins by adding a rule, nothing inherits in. */ --hover-lift: brightness(0.93); --hover-solid: brightness(1.15); --bar-bg: var(--accent); --bar-line: rgba(255,255,255,0.14); --bar-shadow: 0 1px 0 rgba(0,0,0,0.06); /* The white-alpha family the bar's nav controls are drawn with -- part of the same "nothing but these tokens may colour the bar" boundary, since the dark palette's deeper bar will want them retuned together. */ --bar-outline: rgba(255,255,255,0.32); --bar-wash: rgba(255,255,255,0.12); --bar-wash-press: rgba(255,255,255,0.18); } /* --warning has no -ink variant, deliberately, in any palette: its one text use is the flash-warning glyph, which sits on --warning-bg with enough contrast as-is in every palette block -- sandstone's pair measures no worse than light's own. Mint the token when a warning text-on-tint use first appears, not before. */ /* Theme plumbing (issue #257). The :root block above is the standard light palette -- the default, the forced Light theme, and the light side of System. base.html stamps User.theme's name on as data-theme. Themes are a flat list: a future palette is one more :root[data-theme="..."] block of these same custom properties (with its color-scheme line), plus a choice in users/models.py -- the picker derives from the choices, and CONVENTIONS.md ("Themes are a flat list") carries the full recipe, including the theme-color meta branch a forced theme adds in base.html. No crossing with dark. color-scheme is which side the browser draws its own widgets on (scrollbars, form controls, date pickers): System declares both and the device picks; the forced themes pin one side. Every future light-side theme declares `light`. The dark token block appears twice below -- once as the forced Dark theme, once as System on a device set to dark -- because a selector and a media query cannot share one rule, and generating one from the other needs a build step this app does not have. The one-block alternative, light-dark() at every token, was rejected: an engine that predates that function drops every colour in the app at computed-value time -- the same silent failure class as the color-mix note further down, at total instead of local scale. DarkTokenTwinsStayIdentical (shifts/tests/test_static_assets.py) pins the twins identical, so an edit to one fails the suite rather than quietly forking the palette. The twin is Dark's alone: System resolves only to :root's light values or Dark's block, so a second dark-side theme (Ember) has no twin and needs none. */ :root { color-scheme: light dark; } :root[data-theme="light"] { color-scheme: light; } /* The forced-dark rules are @media screen so printing falls back to the light palette. Print drops backgrounds by default but honours text colour, so an unscoped dark block would put near-white ink on white paper. System needs no such scoping: print evaluates prefers-color-scheme as light, which skips the twin below the same way. */ @media screen { :root[data-theme="dark"] { color-scheme: dark; } } /* The dark palette (issue #257, tuned at Balanced). Colours, shadows and the hover filters: the radius scale is theme-neutral, and --cat-bar-* needs no restatement because the bars reference var(--shift-a/b) at their point of use and pick the dark hues up from here. Dark shadows are tuned, not scaled -- dark needs disproportionate opacity for a shadow to register at all. Three families the issue-257 spec left open are derived here: the warning pair, --on-accent (white clears 4.5:1 on the dark accent; the dark text tone does not), and the bar's white-alpha family, dialled down a step because white reads louder on the deeper bar. */ @media screen { :root[data-theme="dark"] { --bg: #0e1416; --surface: #161f22; --surface-2: #1a2427; --text: #e8eff0; --muted: #93a6ab; --accent: #2b7d8f; --accent-ink: #8ed3e2; --accent-light: #1b353d; --on-accent: #ffffff; --mine: #298553; --mine-light: #14301f; --mine-ink: #79dfa4; --excluded: #b35c50; --excluded-bg: #361d19; --excluded-ink: #f0a294; --warning: #e2ae4e; --warning-bg: #322511; --border: #222f33; --shift-a: #5b9ede; --shift-b: #cf9a4e; --shadow: 0 1px 2px rgba(0,0,0,.4); --shadow-hi: 0 6px 18px rgba(0,0,0,.55); --backdrop: rgba(0,0,0,.55); --hover-lift: brightness(1.25); --hover-solid: brightness(1.15); --bar-bg: #112a31; --bar-line: rgba(255,255,255,0.10); --bar-shadow: 0 1px 0 rgba(0,0,0,0.35); --bar-outline: rgba(255,255,255,0.30); --bar-wash: rgba(255,255,255,0.10); --bar-wash-press: rgba(255,255,255,0.16); } } @media (prefers-color-scheme: dark) { :root[data-theme="system"] { --bg: #0e1416; --surface: #161f22; --surface-2: #1a2427; --text: #e8eff0; --muted: #93a6ab; --accent: #2b7d8f; --accent-ink: #8ed3e2; --accent-light: #1b353d; --on-accent: #ffffff; --mine: #298553; --mine-light: #14301f; --mine-ink: #79dfa4; --excluded: #b35c50; --excluded-bg: #361d19; --excluded-ink: #f0a294; --warning: #e2ae4e; --warning-bg: #322511; --border: #222f33; --shift-a: #5b9ede; --shift-b: #cf9a4e; --shadow: 0 1px 2px rgba(0,0,0,.4); --shadow-hi: 0 6px 18px rgba(0,0,0,.55); --backdrop: rgba(0,0,0,.55); --hover-lift: brightness(1.25); --hover-solid: brightness(1.15); --bar-bg: #112a31; --bar-line: rgba(255,255,255,0.10); --bar-shadow: 0 1px 0 rgba(0,0,0,0.35); --bar-outline: rgba(255,255,255,0.30); --bar-wash: rgba(255,255,255,0.10); --bar-wash-press: rgba(255,255,255,0.16); } } /* Sandstone (issue #273): the warm light theme, tuned in the round-two mockups. Light-side, so it retunes rather than restates. The bar's white-alpha family inherits :root's values because this bar (#5d3f26) sits at the same depth as the teal bar they were tuned on -- checked, not assumed; a paler bar would need them retuned, not inherited. --bar-bg is a literal, not the :root alias, because the bar sits a step darker than the accent here; base.html's sandstone theme-color meta restates it, pinned by PaletteMirrorsStayInSync. */ :root[data-theme="sandstone"] { color-scheme: light; --bg: #efe7da; --surface: #faf5ec; --surface-2: #f4eddf; --text: #2b2318; --muted: #726658; --accent: #6f4d31; --accent-ink: #573b24; --accent-light: #eeddc6; --mine: #55803a; --mine-light: #ebf1de; --mine-ink: #3f6127; --excluded: #bf4b26; --excluded-bg: #f9e3d8; --excluded-ink: #96351a; --warning: #c79433; --warning-bg: #f7edd6; --border: #e0d4bf; --shift-a: #4a6f8e; --shift-b: #9a5b68; --shadow: 0 1px 2px rgba(70,50,20,.07), 0 1px 1px rgba(70,50,20,.05); --shadow-hi: 0 4px 10px rgba(70,50,20,.12), 0 1px 2px rgba(70,50,20,.08); --backdrop: rgba(43,35,24,.45); --bar-bg: #5d3f26; } /* Ember (issue #273): the warm dark theme -- charcoal-brown where Dark is cool blue-grey. Dark-side, so it restates the whole palette, inside @media screen like the forced-dark block above. The bar's white-alpha family repeats Dark's dialled-down values: this bar (#2e1f14) sits at the same depth as Dark's -- checked, not assumed. --accent runs a step deeper than the mockup's amber on purpose -- --on-accent has to read on both the accent fills and the bar, and warm white clears 4.5:1 on this accent where it could not on the brighter one. */ @media screen { :root[data-theme="ember"] { color-scheme: dark; --bg: #171210; --surface: #221a15; --surface-2: #2a201a; --text: #f0e6da; --muted: #a8988a; --accent: #8a5f2a; --accent-ink: #e8bd81; --accent-light: #3a2c1c; --on-accent: #f5ead9; --mine: #3c7546; --mine-light: #22321f; --mine-ink: #a4d8a4; --excluded: #b4482c; --excluded-bg: #3a1e14; --excluded-ink: #f0a488; --warning: #d9a850; --warning-bg: #33260f; --border: #35291f; --shift-a: #6f93b8; --shift-b: #b06d89; --shadow: 0 1px 2px rgba(0,0,0,.5); --shadow-hi: 0 6px 18px rgba(0,0,0,.65); --backdrop: rgba(0,0,0,.55); --hover-lift: brightness(1.25); --hover-solid: brightness(1.15); --bar-bg: #2e1f14; --bar-line: rgba(255,255,255,0.10); --bar-shadow: 0 1px 0 rgba(0,0,0,0.35); --bar-outline: rgba(255,255,255,0.30); --bar-wash: rgba(255,255,255,0.10); --bar-wash-press: rgba(255,255,255,0.16); } } /* Harbor (issue #273): the reassigned light theme -- the sanctioned families exception (CONVENTIONS.md, "Themes are a flat list"), keyed by .legend-state in the signup legend. Light-side, so it retunes rather than restates; --surface stays :root's white on purpose. --excluded runs a step deeper than the mockup's amber -- --on-accent's white clears 4.5:1 on it where the amber held it to 3.5:1 -- and because that lands needs-coverage in the warning family, the warning pair is retuned yellower here rather than inherited, or error and warning flashes would share one cream. The bar-alpha family is retuned too, not inherited: this bar sits half a stop paler than the teal bar :root's values were tuned on, so the white alphas step up to keep the nav outline and hairline reading. --bar-bg restates the accent's value as a literal so the chrome pin has a value to hold. */ :root[data-theme="harbor"] { color-scheme: light; --bg: #f3f5f8; --surface-2: #fafbfd; --text: #1b2430; --muted: #657080; --accent: #7c4a70; --accent-ink: #63385a; --accent-light: #f0e2ee; --mine: #2e66b8; --mine-light: #e8f0fb; --mine-ink: #224f92; --excluded: #a85a0a; --excluded-bg: #fbf1de; --excluded-ink: #8f5a06; --warning: #b99a1d; --warning-bg: #faf5cf; --border: #dee4ec; --shift-a: #2a8f8a; --shift-b: #a85275; --shadow: 0 1px 2px rgba(20,30,48,.06), 0 1px 1px rgba(20,30,48,.05); --shadow-hi: 0 4px 10px rgba(20,30,48,.10), 0 1px 2px rgba(20,30,48,.07); --backdrop: rgba(27,36,48,.45); --bar-bg: #7c4a70; --bar-line: rgba(255,255,255,0.18); --bar-outline: rgba(255,255,255,0.42); --bar-wash: rgba(255,255,255,0.16); --bar-wash-press: rgba(255,255,255,0.22); } * { box-sizing: border-box; } html { scrollbar-gutter: stable; } body { margin: 0; font-family: -apple-system, BlinkMacSystemFont, "Segoe UI", Roboto, sans-serif; background: var(--bg); color: var(--text); padding-bottom: env(safe-area-inset-bottom); } header.app-bar { background: var(--bar-bg); color: var(--on-accent); padding: 14px 16px; padding-top: max(14px, env(safe-area-inset-top)); position: sticky; top: 0; z-index: 10; display: flex; align-items: center; justify-content: space-between; /* The hairline is drawn inside the bar's own dark field, so it reads as a bevel rather than a border; the 1px drop below is what separates the bar from the page once both are this close in value. */ border-bottom: 1px solid var(--bar-line); box-shadow: var(--bar-shadow); } header.app-bar h1 { font-size: 1.1rem; margin: 0; font-weight: 650; letter-spacing: -0.01em; } header.app-bar a { color: var(--on-accent); text-decoration: none; font-size: 0.85rem; opacity: 0.88; } /* The outlined pill every nav destination wears (issue #136). Eight anchors in `base.html` carried this as a `style=` attribute -- seven of them 164 bytes and the twice-nested My Signups one 166 -- re-sent with every render. Same cost issue #134 moved this whole file out of `base.html` to avoid, still being paid in the file #134 had just emptied. The byte figures below predate issue #141, which now compresses every template response: on the wire the duplication cost roughly a twenty-seventh of what is quoted here. The de-duplication is still worth having for the reason it always was -- one rule to change instead of eight. **Eight in the template, but at most six on any page**, so don't recompute the saving as 8 x 164. Two separate pairs are mutually exclusive, and only the first is visible from this template: * the two Dashboard links, an `{% if is_admin_user %}` / `{% elif is_readonly_viewer %}` pair, and * My Signups and Schedule -- `shifts/context_processors.py:36,49` gives the first to a physician and the second to a non-physician, so no account can hold both. Brute-forcing every role x flag combination puts the ceiling at six. What that saves depends on who is looking, which is worth stating because the obvious measurement is the unrepresentative one: a *superuser* sees six and saves 925 bytes per render, but the Overtime Admins on production are group members rather than superusers, get five, and save ~778. A plain physician sees three. Only three declarations, because the four in the rule above are not repeated: it already gives every app-bar anchor its colour, font-size, opacity and `text-decoration: none`, and half of each inline copy was restating them. Neither rule sets `font-weight` -- these render at the UA default, and there is nothing in the app bar to inherit one from. Scoped to `header.app-bar a` rather than being a free-floating `.nav-link` because the class is not self-sufficient and should not look as though it is. */ header.app-bar a.nav-link { border: 1px solid var(--bar-outline); border-radius: var(--radius-ctl); padding: 5px 11px; transition: opacity 0.1s ease, background 0.1s ease, transform 0.1s ease; } /* The nav half of issue #188: every button had feedback, no nav element did. The nav pills are transparent fills on the dark bar -- a brightness filter would move only text and border, which is why this family can never join the hover tokens' tiers (--on-accent ink notwithstanding); the lift is a white wash plus full opacity instead, the failed-email-alert's press scale for touch. Hover gated like every hover in this file -- see the lift group's comment; :active stays ungated and later, so press wins. */ @media (hover: hover) { header.app-bar a.nav-link:hover { opacity: 1; background: var(--bar-wash); } } header.app-bar a.nav-link:active { transform: scale(0.96); background: var(--bar-wash-press); } /* The undelivered-email indicator (issue #185). A solid light pill among the outlined transparent ones, which is what makes it read as an alert rather than a sixth destination -- and it is the reason the fill is `--surface` and the text `--text` rather than a red fill with white on it: dark text on white is about 15:1, and the red is spent on the glyph, where it reinforces a signal the glyph and the number already carry. That ordering is the flash rules' convention applied here: colour may support the meaning, never be it, because red and green are the pair colourblind viewers cannot separate. `margin-left: auto` rather than a `gap` on `header.app-bar`. The bar is `justify-content: space-between` with the title at one end, so a third in-flow child would otherwise be spread into the middle at every width. An auto margin consumes the free space before `justify-content` sees it, pinning this to the right beside whatever follows -- the nav row on desktop, the hamburger below 768px, where `#nav-links` leaves the flow entirely. Adding `gap` to the bar would have restyled the existing title/nav spacing on the way past, which is the issue #136 mistake. */ header.app-bar a.failed-email-alert { display: inline-flex; align-items: baseline; gap: 5px; margin-left: auto; margin-right: 14px; padding: 4px 10px; /* Control radius, and bordered, because in this bar that pair *is* the "I am a link" marker -- every nav destination wears it. The border is `--excluded` rather than the nav's `rgba(255,255,255,0.32)` for the plain reason that a white outline on a white fill cannot be seen; spending the red here also keeps it off the text, which stays dark-on-white at roughly 15:1. Not to be confused with the status pills in `_status_pills.html` ("Signups open", "Not published"), which are genuinely non-clickable and are `border-radius: 999px`. Fully round reads as a label in this app; the 8px rounded rectangle reads as a control. Keep that distinction if either changes. */ border: 1px solid var(--excluded); border-radius: var(--radius-ctl); background: var(--surface); color: var(--text); opacity: 1; font-weight: 600; white-space: nowrap; transition: transform 0.1s ease, background 0.1s ease; } /* Plain hue, sanctioned: the glyph is a mark, not text (token charter) -- aria-hidden, with the count and label beside it carrying the meaning. */ header.app-bar a.failed-email-alert span[aria-hidden] { color: var(--excluded); } @media (hover: hover) { header.app-bar a.failed-email-alert:hover { background: var(--excluded-bg); } } /* Press feedback, matching `.btn-secondary-sm`. Hover does not exist on a phone, and the mobile bar is exactly where this renders as a bare glyph and number -- so the tap response is the only confirmation a touch user gets that they hit a control rather than a label. */ header.app-bar a.failed-email-alert:active { transform: scale(0.96); background: var(--excluded-bg); } @media (max-width: 767px) { /* The count and glyph alone on a phone. The label is what makes this self-explanatory on a desktop bar that has room for it; below 768px the bar holds a wrapping page title and the hamburger, and a five-word label there pushes the title into a third line. `title` on the anchor keeps the full wording reachable either way. Only the label changes here. A first draft also dropped the right margin to 12px, which `/simplify` asked the awkward question about: 14px is principled above, matching `#nav-links`' own `gap` so the pill sits on the same rhythm as the links beside it, and the 12px was a value nobody had evaluated. That is the shape of the issue #136 mistake -- a number that had never rendered quietly restyling a surface -- so the no-change option wins until someone deliberately decides otherwise. */ header.app-bar a.failed-email-alert .failed-email-alert-label { display: none; } } main { max-width: 480px; margin: 0 auto; padding: 12px; } .month-heading { font-size: 1.6rem; font-weight: 700; letter-spacing: -0.015em; margin: 4px 0 12px; color: var(--text); } .btn-primary, .btn-secondary, .btn-outline, .btn-danger { padding: 10px 18px; border-radius: var(--radius-ctl); font-weight: 600; cursor: pointer; box-shadow: var(--shadow); /* No background channel: since the hover amendment nothing swaps these buttons' background in place -- publish-ready/-not-ready arrive by node replacement, which never transitions. */ transition: transform 0.1s ease, filter 0.1s ease, box-shadow 0.1s ease; } .btn-primary { border: none; background: var(--accent); color: var(--on-accent); } .btn-secondary { border: 1px solid var(--border); background: var(--surface); color: var(--text); } .btn-outline { border: 1px solid var(--accent); background: var(--surface); color: var(--accent-ink); } .btn-danger { border: 1px solid var(--excluded); background: var(--surface); color: var(--excluded-ink); } /* THE lift -- issue #257's hover amendment, one rule for every surface that carries the identical body: rise 1px, deepen the shadow, shift the element's brightness in its own colour -- var(--hover-lift), so the theme sets the strength and direction. brightness() replaces the old per-variant background swaps -- white darkens to warm grey, a red-tinted button to deeper red -- so the feedback is uniform without a hover colour per variant. One grouped rule rather than a copy per component, so the next tune is one edit; each selector keeps its own specificity, and every member's :active sits later in source, so holding a control still wins the transform tie. Gated on (hover: hover) -- every :hover in this file is -- because touch browsers emulate hover on tap and make it *stick*: a badge tap whose confirm is cancelled sends no request, swaps nothing, and would otherwise sit lifted until the next touch. Press feedback (:active) is the touch channel and is deliberately outside the gate. Two selectors are here despite living "elsewhere": the grid one is safe outside the width media block (below 768px the grid is display:none, so it is inert exactly where the block would exclude it), and the accounts row-menu summary is safe outside its page file (the element exists on one page; the selector is inert everywhere else, and joining the group is what keeps the lift one edit). The shift compounds restate the category bar into the raised shadow -- see the bar comment at "Shift-type accent". */ @media (hover: hover) { .btn-primary:hover, .btn-secondary:hover, .btn-outline:hover, .btn-danger:hover, .btn-secondary-sm:hover, .day-row.tappable:hover, .calendar-grid .grid-cell.tappable:hover, .month-card:hover, /* Only the live arrows: the disabled one is a , so it cannot match this and needs no :not() to keep it out. */ a.month-nav-arrow:hover, .row-menu summary:hover { transform: translateY(-1px); box-shadow: var(--shadow-hi); filter: var(--hover-lift); } .day-card.tappable.shift-tue-thu:hover { box-shadow: var(--cat-bar-a), var(--shadow-hi); } .day-card.tappable.shift-fri-mon:hover { box-shadow: var(--cat-bar-b), var(--shadow-hi); } .calendar-grid .grid-cell.tappable.shift-tue-thu:hover { box-shadow: var(--cat-bar-a), var(--shadow-hi); } .calendar-grid .grid-cell.tappable.shift-fri-mon:hover { box-shadow: var(--cat-bar-b), var(--shadow-hi); } /* Solid tier (the -solid token's comment in :root carries the why and the roster). Same lift motion and shadow -- only the filter tier differs. This rule beats the group's identical selector by SOURCE ORDER alone: keep it after the group inside this media block, and never merge it into the group -- merged, the primary silently drops to the lift tier and no test notices. */ .btn-primary:hover { filter: var(--hover-solid); } } .btn-primary:active, .btn-secondary:active, .btn-outline:active, .btn-danger:active { transform: scale(0.97); filter: brightness(0.91); } /* Keyboard focus in the theme's own accent, for the whole button family -- the browser default ring ignores the palette. Grouped like the hover rule above and for the same reason: one edit tunes every wearer. Born scoped to the confirm dialog's buttons; widened app-wide because the justification never was dialog-shaped (/code-review on PR #307). :focus-visible, not :focus, so a mouse click does not paint a ring. The two day-cell tap surfaces join the family (issue #258): they carry role="button" and tabindex, so keyboard focus lands on them and has to show. The 2px *outward* offset is load-bearing there, not inherited styling: the state ring (further down) is an outline at -2px, and outline is one property -- an inset focus ring would be invisible exactly on the mine/needs-coverage days. While a state day holds focus the accent ring outside replaces its state ring; the state's fill and border stay, so the day still reads. The grid selector is safe outside the width media block: below 768px the grid subtree is display:none. `.tappable` scopes it and outranks the state rules; only tappable cells are focusable at all. */ .btn-primary:focus-visible, .btn-secondary:focus-visible, .btn-outline:focus-visible, .btn-danger:focus-visible, .btn-secondary-sm:focus-visible, .btn-ghost-sm:focus-visible, .day-row.tappable:focus-visible, .calendar-grid .grid-cell.tappable:focus-visible { outline: 2px solid var(--accent); outline-offset: 2px; } .btn-secondary-sm, .btn-ghost-sm { /* background stays a live channel here, unlike the full-size buttons: ghost hover and both :active states still swap it. */ transition: transform 0.1s ease, filter 0.1s ease, background 0.1s ease, box-shadow 0.1s ease; font-size: 0.8rem; padding: 4px 10px; border-radius: 6px; cursor: pointer; } /* Elevation on the solid small button but not the ghost one -- the ghost variant is the deliberately quiet member of the pair. */ .btn-secondary-sm { border: 1px solid var(--border); background: var(--surface); color: var(--text); box-shadow: var(--shadow); } /* Hover: the shared lift group above. */ .btn-secondary-sm:active { transform: scale(0.96); background: var(--accent-light); } .btn-ghost-sm { border: 1px solid var(--border); background: none; color: var(--muted); } /* The ghost stays shadowless on hover too -- it rises and shifts brightness like every control, but never gains the elevation it deliberately lacks at rest. Its own rule, not a lift-group member: different body. Known exception on the dark themes (#293, accepted): the fill feedback here is the background swap, brightness on a background of none moves only text and border, and --bg sits darker than the surface-2 panel this button lives on -- so this one fill dims where its siblings lighten. A redesign needs a "lighter-than-panel" token that does not exist; file it if the dim bothers anyone in use. */ @media (hover: hover) { .btn-ghost-sm:hover { transform: translateY(-1px); filter: var(--hover-lift); background: var(--bg); } } .btn-ghost-sm:active { transform: scale(0.96); background: var(--accent-light); } .day-row.tappable { cursor: pointer; transition: transform 0.1s ease, filter 0.1s ease, box-shadow 0.1s ease; } /* Hover: the shared lift group above (with the bar-restating compounds). Press tiers, since the values look scattered: full-size cards press at 0.98, buttons at 0.97, small controls (badges, small buttons, nav, grid cells, row menu) at 0.96 -- the bigger the surface, the shallower the press. Brightness rides alongside at 0.91 for solid fills, 0.93 for tinted cards and the link chips: the tinted press matches the hover darken and the solid press digs past it, the same relation the pre-#293 values held, moved with the hover retune -- a press may never sit BRIGHTER than the hover it interrupts, or the click reads as a release. Literals, not the hover tokens, on purpose (#293): a press darken barely shows on a charter-dark fill in any theme (the solid tier's wearers included), so scale motion is what carries press there, judged sufficient. Two exceptions to the isolation: .btn-secondary-sm:active and .btn-ghost-sm:active swap background and set no filter, so their held fill keeps whatever the hover token painted. Revisit if presses feel dead in real use. */ .day-row.tappable:active, .month-card:active { transform: scale(0.98); filter: brightness(0.93); } .form-field { display: block; width: 100%; margin-top: 4px; padding: 8px 10px; border-radius: var(--radius-ctl); border: 1px solid var(--border); } /* Flash messages, colour-coded by level. The same banner carries both "Schedule published" and "Not cleared: ... reload and try again", so a single success-green style made every refusal read as a confirmation. Colour alone is not enough to carry that: success/error is exactly the green/red pair red-green colourblind viewers cannot separate, and the tinted backgrounds are pale enough to be near-identical to them. Each level therefore also gets a distinct leading glyph and a thicker left border. An unrecognised level keeps .flash's neutral surface styling rather than silently inheriting some other level's colour. */ .flash-list { margin-bottom: 14px; } .flash { display: flex; gap: 8px; align-items: baseline; background: var(--surface); border: 1px solid var(--border); border-left-width: 4px; border-radius: var(--radius); color: var(--text); padding: 10px 14px; margin-bottom: 8px; font-size: 0.9rem; box-shadow: var(--shadow); } .flash::before { font-weight: 700; } /* Each glyph is text on its level's tint, so it wears the -ink form (issue #281). Warning is the sanctioned exception: it has no -ink, and the token block's --warning note carries why. */ .flash-success { background: var(--mine-light); border-color: var(--mine); } .flash-success::before { content: "\2713"; color: var(--mine-ink); } .flash-error { background: var(--excluded-bg); border-color: var(--excluded); } .flash-error::before { content: "\2715"; color: var(--excluded-ink); } .flash-warning { background: var(--warning-bg); border-color: var(--warning); } .flash-warning::before { content: "!"; color: var(--warning); } .flash-info { background: var(--accent-light); border-color: var(--accent); } .flash-info::before { content: "i"; color: var(--accent-ink); } /* The shared confirm dialog (issue #306) -- base.html's one , filled per call site by app.js. The buttons wear the app's own .btn-* classes, so they get the grouped hover lift, the grouped focus ring below, and the theme retunes for free; nothing here restyles them. max-width is min()'d against the viewport because a bare 420px would *replace* the UA stylesheet's own viewport clamp on rather than add to it -- on a 375px phone a long confirm rendered exactly edge to edge (/code-review on PR #307, reproduced at 375px). The dim behind the dialog is the second box-shadow, not ::backdrop: ::backdrop only learned to read custom properties from the originating element in 2023-24 engines, and on the older ones inside this app's own baseline (Safari 15.4-17.3 has showModal but not the inheritance) a var() there computes to *transparent* while still suppressing the UA's default dim. The dialog element inherits tokens everywhere it exists at all, so a viewport-sized shadow spread carries the same token to every engine; the UA's faint backdrop dim underneath it is unstyled and adds imperceptibly. white-space: pre-line because two confirm messages carry a real blank line (the at-risk warnings on Run Master and Clear) that a normal

would collapse -- the native confirm() honoured those newlines and the message text is unchanged in this move. */ dialog.confirm-dialog { max-width: min(420px, calc(100vw - 32px)); background: var(--surface); color: var(--text); border: 1px solid var(--border); border-radius: var(--radius); box-shadow: var(--shadow-hi), 0 0 0 100vmax var(--backdrop); padding: 20px; } .confirm-dialog-message { margin: 0 0 18px; font-size: 0.95rem; line-height: 1.5; white-space: pre-line; } .confirm-dialog-buttons { display: flex; justify-content: flex-end; gap: 10px; } /* Equal-width tabs (issue #257): grid columns rather than content-hugging inline-flex, so every tab in a bar is the same size -- and so the columns can compress equally on a phone via minmax(0, 1fr) plus max-width instead of overflowing the viewport (the four-tab config nav was ~11px wider than a 375px screen with content-width tabs). The narrow-viewport padding rule below keeps the longest label inside its compressed column down to ~350px viewports; narrower than that, the ellipsis on the link is the bound, not the padding. The rule's 480px trigger is main's own mobile max-width cap -- the point below which the container starts tracking the viewport -- so if that cap moves, this breakpoint moves with it. A sliding active pill was tried here and deliberately dropped -- the rule is CONVENTIONS.md "The tab pill does not slide"; the decision and the sanctioned same-document route are #264. */ /* The pill the row sits in, shared with the picker that replaces the config nav below 768px (.admin-picker, further down). One rule naming both rather than a second copy of six declarations: they are peers wearing one chrome, the arrangement .month-nav-arrow already uses for its live and inert spellings. Only the grid below is the bar's own. */ .admin-tabs, .admin-picker { max-width: 100%; border: 1px solid var(--accent); border-radius: 999px; padding: 3px; margin-bottom: 20px; background: var(--surface); box-shadow: var(--shadow); } .admin-tabs { display: inline-grid; grid-auto-flow: column; grid-auto-columns: minmax(0, 1fr); } /* The type and pill shape a tab wears, shared with the picker's control so the collapsed form cannot drift from the row it stands in for -- they are required to look like the same object, and below 768px the picker is the only one of the two anybody sees, so a drift would show on a phone and never on a desktop. `padding` is deliberately NOT in this group. The 480px override below narrows it to compress a four-column grid, which is a bar problem; the picker is one inline-block control and wants its own asymmetric padding for the divider and arrow. */ .admin-tabs a, .admin-tabs .tab-dead, .admin-picker-control select { font-size: 0.85rem; font-weight: 600; border-radius: 999px; } .admin-tabs a, .admin-tabs .tab-dead { text-align: center; white-space: nowrap; overflow: hidden; text-overflow: ellipsis; text-decoration: none; padding: 6px 15px; background: transparent; color: var(--accent-ink); transition: background 0.1s ease; } /* The active tab's fill, worn by the collapsed picker for the same reason as the group above: it *is* the active tab, drawn on its own. */ .admin-tabs a.active, .admin-picker-control { background: var(--accent); color: var(--on-accent); } /* A tab for a view this month does not have yet -- signup.html's "Assigned" before publish (#267). Same idea as .month-nav-arrow-dead: it keeps its grid slot so the bar does not change width when the state changes, and it is a , so none of the interactive rules above or below can reach it without a selector naming it. Deliberately NOT the arrows' 0.38. That value dims a chevron, which only has to read as "absent"; this is a word somebody has to read. Effective contrast against the bar, measured in both palettes: 0.38 gives 2.08:1 light / 2.60:1 dark, and 0.55 gives 3.10:1 / 3.98:1 -- light is the weaker side, which is the opposite of the guess. Disabled controls are exempt from the WCAG minimum, so this is a legibility choice, not a compliance one; if the two dim treatments are ever unified, unify upward. */ .admin-tabs .tab-dead { opacity: 0.55; } @media (max-width: 480px) { .admin-tabs a, .admin-tabs .tab-dead { padding: 6px 4px; } } /* ---- The config nav's picker (issue #361) ---- Below 768px the config nav's four equal-width tabs no longer fit the column, and a fifth cannot fit at all: `main` caps at 480px until that same breakpoint, so the bar gets 456px and five tabs need 551. The row is therefore replaced by a select naming the current section -- not truncated, not wrapped, not scrolled. `_admin_tabs.html` renders both and owns why. **Keyed on `admin-tabs-nav`, never on `.admin-tabs`.** That base class is a generic pill-tab row worn by five other bars -- the shift-category rows on the dashboard and the signup page, the Signups/Assigned toggle, and the two month lists. All five are needed on a phone, and a rule written against `.admin-tabs` here would collapse every one of them. 768px rather than the 465px where the four tabs still technically fit: it is the breakpoint that already exists, and it keeps this independent of #362. */ .admin-picker { display: none; } @media (max-width: 767px) { .admin-tabs.admin-tabs-nav { display: none; } /* inline-block, so the pill is as wide as the section name rather than the column -- the bar it replaces is `inline-grid` for the same reason. */ .admin-picker { display: inline-block; } } /* The select wears the active tab's fill, so the collapsed control reads as the bar showing only where you are. `appearance: none` is what lets it: without it the platform draws its own chrome over the pill. */ .admin-picker-control { position: relative; display: block; border-radius: 999px; } .admin-picker-control select { appearance: none; /* The one vendor prefix in this file, and it is for Safari before 15.4 -- without it the platform draws its own chrome over the pill, which is the whole illusion. Delete it when those devices are gone. */ -webkit-appearance: none; width: 100%; border: 0; background: transparent; color: inherit; /* `font-family`/`line-height` rather than `font: inherit`, which is what this was: the shorthand also resets size and weight, and it sits after the shared type group above, so it would have quietly undone the two declarations that keep the picker matching the active tab. A form control's own default font is the only thing that needs overriding here. */ font-family: inherit; line-height: inherit; /* Right padding clears the divider and the triangle below; the left matches `.admin-tabs a` so the label sits where the active tab's did. Type and radius come from the shared group up beside `.admin-tabs a`. */ padding: 6px 44px 6px 15px; cursor: pointer; } .admin-picker-control select:focus-visible { outline: 2px solid var(--accent); outline-offset: 3px; } /* **The options do not inherit the closed control's ink**, and both declarations are load-bearing rather than tidy. The select above is white-on-accent so the collapsed pill reads as the active tab. The dropdown the browser opens from it inherits that `color` and none of that `background`, so without this the list is white text on the popup's own pale surface -- every row invisible but the highlighted one, which is legible only because the selection band supplies the contrast behind it. It shipped that way and was caught by eye, not here: the popup is drawn by the platform, so it is outside the page, outside a screenshot, and outside every computed-style read of the control itself. `background` alone is not the fix and neither is `color`. In dark mode the popup also stayed the browser's near-white while the page around it was dark, so the list was wrong in both palettes for two different reasons and one declaration would have fixed one theme's symptom. `--text` on `--surface` is a registered pair in `ComposedTextPairsStayReadable`, so naming tokens here is also what makes the list's contrast measured in every theme rather than assumed. **If Firefox turns out to be in use, check the closed control here first.** It is reported to paint a closed `