/* ================= THE ALTERNATE UX — COMPONENTS ================= Buttons, chips, inputs, menus, progress, avatars, and the three states every surface needs (loading, empty, error). Scoped to `.alt-app`; nothing here escapes to a production page. Five button roles, and the rule is emphasis rather than colour: exactly one primary per surface — learned on the OKR row, where five peer actions once painted five blue blocks. */ .alt-app{ font-family:var(--a-body); color:var(--a-text); background:var(--a-bg); } .alt-app *,.alt-app *::before,.alt-app *::after{ box-sizing:border-box; } .alt-app h1,.alt-app h2,.alt-app h3,.alt-app h4{ font-family:var(--a-display); margin:0; } /* ---------- buttons ---------- */ .a-btn{ display:inline-flex; align-items:center; justify-content:center; gap:6px; height:var(--a-ctl); padding:0 12px; border-radius:var(--a-r-sm); font-family:var(--a-body); font-size:13px; font-weight:600; line-height:1; background:var(--a-raised); color:var(--a-text); border:1px solid var(--a-line); cursor:pointer; white-space:nowrap; text-decoration:none; } .a-btn:hover{ border-color:var(--a-line-strong); } .a-btn:focus-visible{ outline:2px solid var(--a-ring); outline-offset:2px; } .a-btn[disabled]{ opacity:.5; cursor:not-allowed; } /* An icon beside a word needs a size of its own — an icon-ONLY button worked by accident (the and both load alt-tokens.css, so `.a-btn` and every --a-* token resolve there exactly as they do on the other four: one class set serves both vocabularies and the `.btn.small` pairs those two pages used to draw are a legacy choice rather than a constraint. A page-local dressing would be six answers to one question, which is the drift `.a-focus-btn` below exists to prevent. NO NEW GEOMETRY, DELIBERATELY. `.a-btn.sm` sizes it, `.a-btn:not(.icon) > svg` sizes the glyph beside the word, and `.a-btn.icon.sm > svg` sizes it when `compact` drops the word — all three already in this file. A host that must match a particular neighbour passes `cls` and dresses that class in its own sheet; notes.html does exactly that to keep the 18px box it was measured against (CSS/alt/alt-notes.css). THE PRESSED PAINT IS THE SUITE'S ESTABLISHED SELECTED TRIPLE AND NOT A FOURTH BLUE — the same three values `.a-btn.tog.on` directly above, `.a-chip.on`, `.a-stat.on`, `.alt-app .at-tab.on` and notes' own earlier version of this control already carry. The owner's spec asks for "blue border, tint, icon and glow": the border is `--a-blue`, the tint `--a-blue-soft`, the icon `--a-blue-text`, and the word "glow" is answered by those three moving together as a whole lightness step. That is not an improvisation — it is the decision this file already recorded for the watch pair a few blocks down, where an outer shadow was refused because these buttons sit one control-gap apart and an outer ring would touch its neighbour. Measured on the tightest instance (notes' strip, 6px from `.a-list-h-more`) before reusing it here. KEYED ON THE ATTRIBUTE, NEVER A CLASS, and that is the whole reason this is not simply `.a-btn.tog.on`. `aria-pressed` is what a screen reader is told; keying the paint off anything else lets the visual state and the announced state drift apart, which is the same rule stated above `.a-focus-btn` below and the reason the component emits an identical class list in both states. */ .a-btn.a-fold-all[aria-pressed="true"]{ background:var(--a-blue-soft); border-color:var(--a-blue); color:var(--a-blue-text); } /* Hovering something already lit acknowledges the pointer without reading as an unselect. */ .a-btn.a-fold-all[aria-pressed="true"]:hover{ background:var(--a-blue-soft); border-color:var(--a-blue); } /* ================= THE FOCUSED-MODE CONTROL — ONE TREATMENT, THREE PAGES ================= WHY IT IS HERE AND NOT IN A PAGE STYLESHEET, WHICH IS THE WHOLE POINT OF THE CLASS. Focused mode has a button on tasks.html, on team_board.html and on notes.html, and each of those pages owns a stylesheet that could dress it. Three dressings is three answers to one question, and the first time the accent moves two of them follow and one does not. So the look lives with the other shared primitives and the three pages consume it. The page sheets keep only what is genuinely theirs — where the control SITS in its row (`.a-focused-btn` in alt-tasks.css, `.at-focused-btn` in alt-team.css are `margin`/`flex` and nothing else). DESIGN SOURCE: `_docs/wire_frames/Focused/` — the owner-approved board plus three reference crops, one per state. Measured off those crops rather than eyeballed; the numbers that mattered are recorded against the declarations below. NOT TO BE CONFUSED WITH `.a-focus`, one file over in alt-shell.css. That is the SHELL's control — the header menu that narrows every page to one tag — and it shares nothing with this but six letters. Two near-identical class names is not ideal and it is deliberate: the name is the contract three pages already call this control by. If you are here to change the tag filter, you are in the wrong rule. THE ACTIVE STATE IS CARRIED BY `aria-pressed`, NOT BY `.on`, AND THAT IS THE CONTRACT. `.a-btn.on` above paints the same blue off a CLASS, which means the visible state and the state a screen reader is told can drift apart — and they have, elsewhere in this suite: see the "`.on` WAS MISSING HERE" note at alt-tasks.js:989, where a chip set `aria-pressed` correctly and nothing painted it. Keying the paint off the attribute makes that failure impossible to express. It is the pattern CSS/okr.css already uses for the OKR pin, so this is the established answer rather than a new one. A host that also leaves `.on` on the element is harmless — every rule below carries `.a-btn.a-focus-btn`, which outranks `.a-btn.on` — but it is redundant and should come off. THE HIERARCHY IS NEUTRAL -> INTERACTIVE -> SELECTED, and only the middle two are declared: the DEFAULT state is `.a-btn`'s own base, unchanged, because the reference's "neutral surface, restrained border, light text" IS `--a-raised` on `--a-line`. An inactive Focused button should look like every other button in its toolbar; that it needed no rule is the evidence that the shared primitive was already right. NOT ONE SIZE IS RESTATED, AND THAT IS THE OWNER'S INSTRUCTION RATHER THAN A SHORTCUT: keep the control the size it is now, a little bigger at most. So height, radius, padding, gap and the 15px glyph all stay on the tokens the row already agrees on. There is no geometry below at all: every rule in this block sets colour, and the control's box is `.a-btn`'s box. THE REFERENCE CROPS ARE DELIBERATELY NOT FOLLOWED ON PROPORTION, which is worth writing down because the numbers are seductive. Measured off them the icon-to-label gap is 0.22-0.25 of button height and the glyph box 0.57 — which lands on 6px/15px for the 26px `.sm` control two of the three hosts use (so `.a-btn`'s existing values are already right there), but asks for ~7.5px and ~18px on the 32px host (team_board.html uses `.a-btn` without `.sm`). It keeps 6px/15px there too. A design board shows a button ALONE; this one lives in a dense toolbar, where matching the controls beside it is what "native to the top navigation" means — and `.a-btn:not(.icon) > svg` is a shared rule this must not move in any case. THEMES COME FREE, WHICH IS WHY EVERY VALUE BELOW IS A ROLE. `--a-blue-soft`, `--a-blue` and `--a-blue-fill` point at `--accent-soft`/`--accent`/`--accent-fill` in CSS/alt/alt-tokens.css, so light mode and a team's custom palette both arrive with nothing here to change. `#fff` is the one literal and it is the same literal `.a-btn.on` and `.a-btn.primary` use: `--accent-fill` is the token that exists specifically to hold white text (4.52:1 dark, 5.86:1 light, measured in CSS/tokens.css), so white on it is the measurement rather than a guess. ONE THING LIGHT MODE DOES NOT GET: the reference's "brighter blue edge" on the active state. In dark, `--accent` #3b82f6 sits a step brighter than `--accent-fill` #1e6ff5 and draws it; in light the two tokens are the same #2560c8, so the edge goes flat. That is correct rather than broken — on a light ground the fill is already the contrast — and inventing a lighter blue here would be the second colour system this file exists to avoid. FOCUS-VISIBLE IS UNTOUCHED, DELIBERATELY. `.a-btn:focus-visible` above draws the 2px `--a-ring` outline and nothing below sets `outline`, so a keyboard reader sees the ring in all three states — hover styling changes `background` and `border-color` only and cannot stand in for it. (CSS/alt/alt-focus.css, which loads last on every page, is the backstop.) WHAT CARRIES THE STATE WHEN THE LABEL DOES NOT. This control reads "Focused" in both states — see the next block for why — so unlike most toggles it has no word that changes, and the two states are told apart visually by the surface alone. That is not hue-only, which is the part that matters: `--a-raised` against `--a-blue-fill` is a large LIGHTNESS step (a relative luminance of 0.020 against 0.180 in dark) and the label flips to `#fff` with it, so the difference survives any colour-vision deficiency and greyscale. `aria-pressed` carries it for anything that cannot see the button at all. Nothing here asks a reader to distinguish two blues, which is the failure this note exists to rule out. */ /* ---------- THE LABEL IS A CONSTANT, SO THERE IS NOTHING HERE TO SIZE ---------- THE CONTROL READS "Focused" IN BOTH STATES, and that is a naming decision rather than an oversight: the suite header already carries a control labelled **Focus** (`.a-focus-l` in alt-shell.css, rendered by alt-shell.js), which narrows every page to one tag and shares nothing with this. A second control resting on that same word puts two different "Focus" controls in one viewport, which is the discoverability defect core rule 5 exists to prevent. SO THE BUTTON HAS NO SIZING RULE OF ITS OWN, and that is the whole entry. A label that never changes never changes width, so the control is exactly `.a-btn` plus `.sm` where its host uses it: height, radius, padding, font and the 6px icon-to-label gap all come from the primitive every neighbour in the same toolbar already wears. Measured headless at 1440 on both hosts — 26px beside a 26px `.a-btn.sm`, 32px beside a 32px `.a-btn`, glyph and label each 0.00px from the button's vertical centre. `.a-focus-btn-t` IS A HOOK, NOT A BOX. The three page files wrap the label in that span and this stylesheet deliberately gives it no rule: as a flex item of `.a-btn` it is already blockified, content-width and centred, so any declaration here would be restating the primitive. If you are about to add one, check first that `.a-btn` has not already answered it. --------------------------------------------------------------------------------------------- IF A TOGGLING LABEL EVER COMES BACK, THE RESERVATION TRICK HAS TWO TRAPS. Both cost a debugging cycle here and neither is discoverable from reading CSS. A label that changes between two words changes width, which moves every neighbour along the toolbar on each toggle. The fix is to render the longer word a second time at zero height and let the box size to the wider of the two — and: 1. **`attr()` reads only the attribute of the element its own pseudo belongs to.** Put the reservation on the BUTTON while the word lives in an attribute on the LABEL SPAN and it resolves to nothing at all — no error, no warning, just a reservation that silently reserves zero. The pseudo has to sit on the element that carries the attribute. 2. **A zero-height ITEM is not a zero-height TRACK.** `align-content` defaults to `normal`, which on a grid behaves as stretch, so free space is distributed across the auto tracks including the one holding the invisible item. Measured when this was built on the button: `grid-template-rows` computed to `22.5px 7.5px` on the 32px host, so the visible row centred its contents inside 22.5px instead of 30px and lifted the glyph and label 3.75px and 4.25px above the button's true middle — 13% of the control, in a row where every flex neighbour sat within 0.50px of centre. `align-content:center` is what stops it. Neither shows up in a stylesheet review; both were found by measuring a real browser, which is why that step is not optional for this control. */ /* HOVER — the interactive middle tier: a muted steel-blue surface on a brighter blue edge. Text stays `--a-text` from the base rule: the crop shows a light label, and the token is light in dark mode and dark in light mode, which is the same intent expressed once. `:not([aria-pressed="true"])` RATHER THAN PLAIN `:hover` so this rule and the active rule below are mutually exclusive and neither depends on the order they appear in. --------------------------------------------------------------------------------------------- IT MIXES ITS OWN SURFACE RATHER THAN WASHING OVER THE ROW, AND THAT IS A MEASURED FIX. `--a-blue-soft` is `rgba(59,130,246,.20)` — translucent. Setting it as a `background` REPLACES the button's opaque `--a-raised`, so the wash then composites over whatever the page happens to put behind the control. That makes the hover colour a property of the TOOLBAR rather than of the button, and the three hosts do not agree on their toolbar ground. Measured, hover against default: notes / tasks #16283f -> #18325c 1.170 TEAM BOARD #16283f -> #142c51 1.071 <- the surface doing no work at all light #dee4ee -> #cfdaed 1.103 reference crops #1e262f -> #263a5a 1.336 One shared class producing a visibly different hover on one of its three hosts is the exact drift this class exists to prevent, and 1.071 is not a design decision anybody made — it is where the maths landed. THE RATIO IS UNCHANGED AT 20%. Only what it composites over changed: `--a-raised` is the button's own surface, so the result no longer depends on the page behind it. Computed, and then the same in all three dark hosts: dark #16283f -> #1d3a64 1.307 (crops 1.336) light #dee4ee -> #b9cae6 1.299 HOVER STILL DOES NOT APPROACH ACTIVE, which was the constraint: active leads it 2.52:1 in dark and 3.53:1 in light, and carries white text where hover keeps `--a-text`, so the two differ by more than a fill. The design board's own 1.628 was deliberately NOT matched — that board shows the control alone, and the crops are the closer reference; 20% is the canonical number and raising it to chase the board would push hover toward active for no reader's benefit. AND THE PLAIN DECLARATION AHEAD IS NOT DECORATION — the same rule CSS/alt/alt-tokens.css states for `--a-float`. An engine that does not know `color-mix()` discards the whole declaration at parse time, so without the line above it there would be no background at all. It falls back to exactly the wash this used to be, which is the correct thing to degrade to. THE WASH IS STILL THE SUITE'S ANSWER ELSEWHERE. `.a-btn.tog.on` and `.a-chip.on` keep `--a-blue-soft` and are untouched; this is not a second muted blue, it is the same one made independent of its host. Those two have the same latent composition behaviour, on surfaces where nobody has measured a problem — worth knowing, not worth changing here. */ .a-btn.a-focus-btn:not([aria-pressed="true"]):hover{ background:var(--a-blue-soft); background:color-mix(in srgb, var(--a-blue) 20%, var(--a-raised)); border-color:var(--a-blue); } /* ACTIVE — selected, and stronger than hover by a whole step: a filled surface rather than a wash. `.a-btn.on` paints the same fill with a transparent edge; the approved design keeps a blue edge on it, which is the only reason this is not simply that rule. */ .a-btn.a-focus-btn[aria-pressed="true"]{ background:var(--a-blue-fill); border-color:var(--a-blue); color:#fff; } /* Hovering something already selected should acknowledge the pointer without unselecting it, so the fill brightens rather than stepping back down to the hover wash — `.a-btn.primary:hover` above is the same gesture, and `filter` is already in this file's micro-transition list. */ .a-btn.a-focus-btn[aria-pressed="true"]:hover{ filter:brightness(1.08); } /* ================= WATCHING A TASK SAYS SO — THE LIT EYE AND ENVELOPE ================= THE CONTROL. JS/components/task-watch-mail.js builds one eye-plus-envelope pair and three surfaces host it: team_board.html's task modal, the framed editor on tasks.html?task=…&embed=task, and the Suite's task drawer on tasks.html. Assigning a task now subscribes the actor automatically (the auto-watch section of JS/services/task-assign.js), and until this block the pair said nothing about whether that had happened — the eye's only difference between watching and not was a 2.7px pupil filling in. WHY IT IS IN THIS FILE AND NOT IN A HOST'S. These are the only two rules in the repository that reach all three hosts from one place: alt-components.css is an unconditional on BOTH tasks.html (line 274) and team_board.html (line 225), while the sheets that dress the buttons' own classes are split — `.icon-btn`'s only base rule lives in CSS/task-editor-panel.css, which tasks.html loads only inside `