/* JetBrains Mono 500, latin subset, self-hosted (task #523). ONE FILE, ONE WEIGHT, ONE SUBSET. It is loaded for a single control - the two hex value fields on the Card Design page - so anything more would be bytes nobody reads. `font-display: swap` paints the platform monospace immediately and swaps when the file lands, and `unicode-range` means the browser never fetches it at all for a page whose text is outside the subset. It is served from /static, from public/jetbrains-mono-latin-500.woff2, which is copied verbatim out of @fontsource/jetbrains-mono (exact-pinned in package.json) by `npm run font:mono`. That is the same provenance shape the Phosphor icon catalogue uses. The font is under the SIL Open Font License 1.1; the licence and the attribution are reproduced in THIRD-PARTY-NOTICES.md. NOT a Google Fonts request. src/views/fonts.tsx makes exactly one of those, carrying Manrope and Caveat, and the two Content-Security-Policies that cover HTML pages allow that origin and 'self' for fonts. Adding a third family to that request would have made every page in the product wait on a face that one page uses. */ @font-face { font-family: 'JetBrains Mono'; font-style: normal; font-weight: 500; font-display: swap; src: url('/static/jetbrains-mono-latin-500.woff2') format('woff2'); unicode-range: U+0000-00FF, U+0131, U+0152-0153, U+02BB-02BC, U+02C6, U+02DA, U+02DC, U+0304, U+0308, U+0329, U+2000-206F, U+20AC, U+2122, U+2191, U+2193, U+2212, U+2215, U+FEFF, U+FFFD; } :root { /* LoyalPack brand (task #435): purple highlight, dark, white. Greys are neutral surface/line/text tokens, not additional brand colours. Status colours (error/success and the amber badges below) stay semantic. */ --brand: #5238bf; /* The LoyalPack purple, fixed. --brand above is deliberately overridable per page by a merchant's own brand colour (see Layout's brandColor), which is right for their card and their Program page but wrong for LoyalPack's own chrome. The app header's hover and current-section colours use this token so they stay LoyalPack purple whatever the signed-in business has chosen. */ --brand-fixed: #5238bf; /* The same LoyalPack purple, made readable on the dark band (task #583). The purple itself measures only 2.37:1 against --ink, so a line drawn in it there is barely visible; this is that purple mixed 40% toward white, in the same 5% steps the old per-Program lift used, which is the first step to clear 6:1 (6.06:1). Twice the 3:1 a non-text graphic is asked for, because the dashboard's chart is the thing on that band people actually read. Still plainly the brand hue, and quieter than the band's #c8c2d4 furniture. */ --brand-on-ink: #9788d9; /* The two non-purple series colours of the three-line chart (task #787), as tokens since task #807. The validated set and the reasoning for it live with the chart rules further down; they are tokens because Reports > Overview draws a sample of each line beside the tick box that switches it on, and #583's rule is that a chart's colours are stated in ONE place. The first slot has no token of its own: it is --brand-fixed above. */ --chart-s2: #0e8f7e; --chart-s3: #c2410c; --ink: #15111b; /* THE DARK BRAND TONE (task #832, Sam: "a new dark type colour that sits between the brand colour and the ink colour but closer to the ink"). It is --ink carried about a fifth of the way to --brand-fixed, so it is plainly the brand hue rather than a neutral, and still reads as a dark: 16.80:1 against white, against --ink's own 18.62:1. --brand-on-ink measures 5.47:1 on it and rgba(255, 255, 255, 0.82) 11.55:1, so everything the ink bands already draw on themselves carries across with room to spare. WHERE IT IS USED, and nowhere else: the front page's grid of blocks and the public footer under it. It is deliberately NOT a replacement for --ink. The hero, the wallet band and the app's own chrome stay ink, and this reads as one deliberate step off it rather than as a second dark everything has to choose between. */ --ink-brand: #22163d; --muted: #615c6b; --bg: #f7f6fa; --card: #ffffff; /* Neutral rule/border token. Darkened from #e6e3ec to #d1cbdc (Sam, task #445): the six code boxes read as barely-there at the old value. Same hue family (a light lavender-grey, ~260deg), one step darker: 1.58:1 against white instead of 1.27:1, so a 1px border is clearly visible while dividers and card edges stay quiet rather than structural. */ --line: #d1cbdc; /* The authenticated page header strip (task #456). A restrained lilac from the same family as --line, three steps darker, so it reads clearly as a band against the pale grey page rather than as a slightly-off white: 1.3:1 against --bg over a large area, which is a plain visible step. Everything that sits on it clears WCAG AA at normal size: --ink 13.4:1, --strip-muted 6.6:1, and --brand-fixed (the hover colour) 5.6:1. The active tab takes --bg instead, where --brand-fixed clears AA too (task #456 refinement). */ --strip: #ddd6f0; --strip-muted: #4a4457; --error: #b3261e; --success: #146c43; /* The one red that is read ON THE INK, which is the menu bar and the phone menu (Sam, task #831 review: "make the logout link red"). --error above is the product's red on a white page and measures 6.54:1 there; on --ink (#15111b) it is 2.85:1, well under the 4.5:1 AA floor, so a logout item painted with it would be a colour a merchant has to hunt for. This is the same hue lifted until it reads on the dark: 6.71:1 against --ink, and 9.36:1 for the hover step, so the resting state and the hover state both clear AA comfortably. Deliberately never used on a white surface, where it is 2.78:1 and --error is the correct red. */ --ink-danger: #ff6b6b; --ink-danger-hover: #ff9d9d; /* THE app message bar (task #543, Sam). Sam's addition to the brief was that the current messaging gets lost, so these are deliberately saturated FILLS rather than the coloured text --error and --success above give a paragraph. Each pairs a bright fill with a very dark ink of its own hue, which is what lets a bar be vivid and still sit comfortably above WCAG AA at normal size. Measured with the product's own src/contrast.ts, ink on fill: success 6.74:1 error 5.41:1 warning 7.33:1 The fill against the page is the number that answers Sam's complaint directly, and it is why a tint would not have done. Against --bg: success 2.00:1 error 2.97:1 warning 1.93:1 For scale, the header strip --strip is 1.31:1 against --bg and the stylesheet already calls that "a plain visible step" over a large area. The fills these replace were 1.00:1 and 1.01:1: .prog-saved's #f1f8f4 and .prog-error's #fdf3f2 were, as blocks, indistinguishable from the page, so the only thing carrying the message was 600-weight coloured text. That is exactly the "gets lost" Sam described. --msg-*-edge is the "slightly darker bottom edge" the brief asks for, the same hue a couple of steps down (1.5:1 to 1.75:1 against its own fill). It is drawn as a 3px bottom border, so the bar reads as resting on the page rather than floating on it. These are LoyalPack's message colours, not a second brand: the purple --brand-fixed stays the app's own colour and nothing here borrows it, which is deliberate. A message is about what just happened, so it has to be legible at a glance from across a counter rather than on-palette. */ --msg-success: #12c98b; --msg-success-ink: #04301f; --msg-success-edge: #0a9668; --msg-error: #ff5347; --msg-error-ink: #3d0400; --msg-error-edge: #d02718; --msg-warning: #ff9d1c; --msg-warning-ink: #3a1f00; --msg-warning-edge: #d97a00; /* The post-it support note in an editable settings section (task #462): a pale amber note and a slightly darker amber for its border and folded corner. --ink on --note is well above AA (a near-black on pale yellow), and so is the purple link colour --brand-fixed. */ --note: #fdf6d3; --note-edge: #e3d488; /* Manrope (task #453), then a local fallback for a slow or blocked Google Fonts fetch, which is what display=swap paints in the meantime. */ --font-brand: 'Manrope', -apple-system, BlinkMacSystemFont, 'Segoe UI', Roboto, Helvetica, Arial, sans-serif; /* Caveat (task #487), the handwritten face for a support note's short title and nothing else. It rides the same Google Fonts request as Manrope; the cursive keyword is the honest fallback while display=swap waits. */ --font-note-title: 'Caveat', cursive; /* JetBrains Mono (task #523), for a code VALUE the merchant types character by character: the Card Design hex fields, and nothing else yet. It is SELF-HOSTED from /static rather than fetched from Google Fonts, which is why it is a separate token from the two above: a webfont for one field on one page is not worth a third family on the shared stylesheet request every page makes, and the @font-face below serves one 21 KB latin file only when a page actually renders the class. The fallback stack is the platform monospace the rest of this file already uses, so the field is a real monospace before, during and after the fetch, and remains one if it never arrives. Licence and provenance: THIRD-PARTY-NOTICES.md. */ --font-mono: 'JetBrains Mono', ui-monospace, SFMono-Regular, Menlo, Consolas, monospace; /* The content column width every centred interior reads: `.container` and, on a signed-in page, the full-width strips' inner elements too, so they all stay on one grid. This declaration is the DEFAULT, which is the measure the public and customer pages keep: the landing page, enrolment, the browser card and the not-found page. Task #497 left it exactly where it was, on purpose - those are reading and form surfaces and widening them would lengthen their lines for nothing. */ --content-max: 960px; /* The signed-in app's own grid (task #497), opened out from 960px so the dashboard, Programs, Reports, Account and the scanner get more room for their cards, tables and two-column layouts. This is the single authoritative number for the authenticated width: it is written once, here, and reaches every shared authenticated interior through the one rule below that hands it to --content-max on the app shell's body. Nothing else declares 1120. */ --app-content-max: 1120px; /* THE ONE HORIZONTAL GUTTER (task #833, Sam): the distance from the edge of the surface a page is drawn on to the content on it. Every centred interior carries exactly this much and nothing else does, so `.container`, the page header strip's inner element, the tab row, the footer's inner element and the dashboard band's interior all start their content on the same vertical line at every width. This declaration is the DEFAULT and is unchanged at 16px: it is what the public and customer pages keep (the landing page, enrolment, the browser card, the card designer and the not-found page). The signed-in app takes a wider one on the shell's body, in the one rule below that also hands it its wider column, and since task #843 the support section takes it too, because it is on that shell. */ --content-gutter: 16px; /* The content column's own top padding, named so a full-bleed section that must sit flush under the page header (the dashboard's focused band) can cancel exactly this much and never a guessed number. */ --main-pad-top: 30px; /* The padding a full-width editable/content section carries inside its border (task #490 settled 30px for .settings-section; task #496 gave the report cards the same treatment). Named so a second surface can take the settled value rather than a copied number. `.settings-section` keeps the literal 30px it was pinned with, and a test asserts this token still equals it, so the two cannot drift apart. */ --section-pad: 30px; /* One editable control, one height (task #501). Every field a signed-in person types into is exactly this tall, and so is the Filter button that ends the Reports filter row, so a row of controls has one top edge and one bottom edge instead of a 40px field beside a 48.8px button. 48px also keeps every control clear of the 44px touch-target floor on a phone. The horizontal padding below is the Account fields' own settled value, named here so a second surface takes the settled number rather than a copy of it. The Reports bar keeps its own tighter 10px inline padding from task #496 and overrides only that. THE RADIUS IS ZERO, AND THAT IS THE PRODUCT'S ANSWER (task #839, Sam). No control in the app has rounded corners: not a button, not a field. The number stays a token rather than becoming a literal 0 in the field rule because it is still the one place that decides, and because the base .btn is held equal to it by a test, so a button and the field beside it can never disagree about their corners. Square edges belong to controls only: cards, tiles, previews, wallet faces, avatars, status badges and topic tags keep the shapes their own rules give them. The two pills that WERE controls (the customer range links and the icon-set filters) are square now with everything else. */ --control-height: 48px; --control-radius: 0; --control-pad-x: 12px; /* The signed-in app's left menu bar (task #831, Sam). ONE number for how much of the window the ink column takes, read by the body grid that places it and by --bleed-w below, so the menu's width and everything measured against the content beside it can never disagree. It steps down once on a small laptop (see the app-shell block further down), and there is no third value. Declared here rather than in that block because --bleed-w's DEFAULT has to be expressible without it, and because a reader looking for "how wide is the menu" looks in the token list. */ --sidebar-w: 268px; /* WHAT "YOU ARE HERE" LOOKS LIKE IN THE MENU COLUMN (task #852, Sam). ONE fill, read by the app's own sidebar and by the support section's, so the two columns cannot answer the same question differently. It is --brand-fixed at half strength, which on the ink (#15111b) composites to #34246d: a deep indigo that reads as the brand rather than as a grey lift, and that is plainly a filled row without being a bright block in a dark column. Measured, WCAG 2.2 relative luminance: white label on the fill 12.99:1 (AA and AAA, comfortably) the fill against the bare ink 1.45:1 (the band you see at a glance) THE FILL DOES NOT REPLACE THE PURPLE BAR, IT JOINS IT. The 3px leading mark is still there and still --brand-fixed, and aria-current="page" still says it in the markup, so the state has three signals and never depended on this one. Half strength rather than more is what keeps the mark visible against its own row: the purple is only 2.37:1 above the ink to begin with, so every point of fill is a point off the bar, and this is the split that leaves both readable. IT IS THE CURRENT ITEM'S ALONE. Hover stays exactly what Sam settled in task #449: the label and its icon turn purple, with no background, box or underline, so nothing a pointer passes over can be mistaken for the row a merchant is standing on. */ --nav-current-fill: rgba(82, 56, 191, 0.5); /* How wide a full-bleed band inside the content column should draw itself, and the whole of what task #831 had to teach the four bands that do it. A band is an ordinary block inside the centred column that stretches itself back out to the edges of the surface it sits on, by negative inline margins of exactly the distance from column edge to surface edge. Until this task that surface was always the window, so the distance was always half the viewport and every band wrote `50vw` directly. IT IS NOT THE WINDOW ANY MORE on a signed-in page: the menu bar takes the left of it, and a band that still bled to 100vw would start underneath the menu and hang off the right of the screen by the menu's width. So the bands read this token instead of naming a viewport, and the app shell hands it the content area's own width. Everywhere else - the public landing page, the card designer, and every one of these bands on a phone, where the menu is a top bar again - it is the window, exactly as before. */ --bleed-w: 100vw; } /* The focused-Program band below stretches itself to 100vw from inside the centred column, and vw units include a classic (non-overlay) scrollbar, so its far edge can poke past the layout viewport by the scrollbar's width. `clip` cuts that sliver off at the viewport without creating a scroll container - unlike `hidden`, nothing becomes programmatically scrollable and vertical scrolling is untouched - so the page can never grow a horizontal scrollbar from the full-bleed treatment. */ html { overflow-x: clip; } * { box-sizing: border-box; } body { margin: 0; font-family: var(--font-brand); color: var(--ink); background: var(--bg); line-height: 1.55; } /* The signed-in app shell (task #497). Layout puts this class on for every authenticated page and on no public or customer one, so this is the single switch between the two grids. It works by REDEFINING the shared token rather than by adding a second max-width anywhere: every centred authenticated interior already reads --content-max (`.container`, `.pagehead-inner`, `.pagehead-tablist`, `.app-footer-inner` and the focused band's `.dash-focus-inner`), and all of them inherit from , so one declaration moves the header strip, the content, the footer and the full-bleed band's interior together and they cannot drift apart. The gutter is the same story one token along (see --content-gutter, and the app's own value just below), so the four still share exact left and right edges at every width. Below 1120px + gutters the max-width simply stops applying and the column is fluid, which is why there is no media query here and nothing to overflow. */ /* AND THE PUBLIC CARD DESIGNER (task #572, Sam: "make --content-max wider, same as the web app uses"). It is the one public surface built like an app screen: a stage bar, a working column and a live preview beside it, and at 960px the two columns were cramped enough that the icon picker's fifty marks would not sit in five rows. It joins the SWITCH rather than declaring a width of its own, so there is still exactly one rule reading --app-content-max and still exactly one number to change. The landing page, enrolment, the browser card and the not-found page are untouched: none of them carries .cc-page. */ /* AND THE SUPPORT SECTION (task #574 review, Sam: a persistent navigation column down the left). A sidebar has to come out of the content column, and at 960px it would have taken a third of it: the article measure survives that (the prose is capped at 66ch either way) but the screenshots do not, and they were widened for exactly that reason two changes ago. So support joins the same switch, on the same one rule, and the band, the trail and the content all widen together because every one of them reads --content-max. */ body.app-shell, body:has(.cc-page), body:has(.support-page), body:has(.lp-page) { --content-max: var(--app-content-max); } /* AND THE SIGNED-IN APP HOLDS ITS CONTENT 30px IN FROM THE GLASS (task #833, Sam), against the 16px it shared with every other surface until now. 16px is a reading page's gutter; a working screen wants the wider one, and on a shrinking window it is the whole of what stops a card, a table or a header title sitting almost against the edge of the screen. ONE DECLARATION, because every interior reads the token rather than naming a number, so the strip, the tabs, the column, the footer and the dashboard band's interior move together and cannot land on different lines. The max-widths above are untouched: on a wide screen the column is still exactly 1120px and still centred, and the wider gutter is simply taken out of it, so nothing overflows and no breakpoint is involved. `body.app-shell` ALONE, and deliberately not the four-selector list above: the card designer and the public front page take the app's WIDTH because they are built like app screens, but they are public reading surfaces and Sam's request is about the signed-in app. THE SUPPORT SECTION TAKES THE WIDER GUTTER SINCE TASK #843, and it takes it from this rule rather than by joining the list: the section is on the app's shell now, class and all, so it is on the app's measure for the same reason every other surface with that class is. Its `body:has(.support-page)` entry in the width switch above is what it was, and is simply no longer the thing deciding. */ body.app-shell { --content-gutter: 30px; } /* Native controls take the user agent's font rather than their ancestors'. Element selectors, so the deliberate monospace fields further down (the hex colour value, the enrolment URL) still win on specificity. */ button, input, select, textarea { font-family: inherit; } /* The file picker's button is in the input's shadow tree and inherits from nothing, not even the input. Two rules, because a browser that knows only one of these names would drop a combined selector list. */ input[type='file']::file-selector-button { font-family: inherit; } input[type='file']::-webkit-file-upload-button { font-family: inherit; } .container { max-width: var(--content-max); margin: 0 auto; padding: var(--main-pad-top) var(--content-gutter) 64px; } /* The container's own padding is the ONE thing that sets the distance from the page header strip (or, on a page without one, from the top of the content) to the first thing on the page. A page-level block that ALSO carried a top margin used to add to it, which is why the two report cards, every 403 refusal, the shared Message page and the counter poster all sat 46px down while Programs, Account and Billing sat at the token's 30px, and why a page that happened to open with a flash paragraph took the browser's own 1em on top of that (task #501). Dropping the leading margin here, at the boundary, is what makes the token the answer on every route; the alternative was a compensating rule per page, which is how the 46px got there in the first place. Only the FIRST block's own top margin goes. Its interior spacing, and every later block's rhythm, are untouched: `.card` still separates two stacked cards by 16px, `.settings-section` still leaves 24px under itself. The dashboard's full-bleed focused band is the one deliberate exception. It cancels the padding entirely so it can sit flush under the header, and it still does: its rule further down is more specific than this one. */ main.container > :first-child { margin-top: 0; } a { color: var(--brand); } h1 { font-size: 1.9rem; line-height: 1.2; margin: 0 0 12px; } h2 { margin: 0 0 8px; } h3 { margin: 0 0 8px; } code { background: #f0eef5; padding: 2px 6px; border-radius: 6px; font-size: 0.92em; word-break: break-all; } /* --- nav --- */ .topnav { display: flex; align-items: center; justify-content: space-between; padding: 14px 20px; background: var(--card); border-bottom: 1px solid var(--line); } .brand { display: inline-flex; align-items: center; font-weight: 800; font-size: 1.15rem; text-decoration: none; color: var(--brand); } /* The brand wordmark (task #1024): the approved wide artwork's white variant, drawn by the one component in src/views/brand-logo.tsx as an and sized by HEIGHT. width:auto keeps the artwork's proportions, and the width/height attributes the component writes hold the slot while the file loads. The sizing class on each bar (.appnav .brand-logo, .auth-logo) owns the height; this rule owns only the shape, and a bar that set no height would draw the attributes' 46px. */ .brand-logo { display: block; width: auto; } .nav-links { display: flex; align-items: center; gap: 18px; } .nav-links a { text-decoration: none; color: var(--ink); } /* THE PUBLIC BAR'S ONE FILLED ITEM (task #955 pass 2, Sam: its label was rendering black; pass 3: the bar is ink). The public bar wears the app bar's `appnav` treatment, whose `.appnav .nav-links > a` paints every item as white text on nothing at (0,2,1), outranking `.btn` at (0,1,0): the one item that is a filled button (Get Started for a stranger, Account for a merchant) would lose its fill and its label colour to that rule. This rule is scoped to that one item on the public bar (`.topnav-action` is set by PublicNav and nothing else) at (0,3,1), and restates the button for every state a link has, visited and active included, so no user-agent or shared rule can take it back. The fill is WHITE with ink text, the same decision the hero's button on the ink band takes: the brand purple is a 2.4:1 block against ink, while ink on white measures 18.6:1. Hover keeps the hero button's brightness dip; focus gets a white ring offset onto the ink bar so it reads on either side of the button's edge. The authenticated bar's own items are never `.topnav-action` and are not reached. */ .topnav .nav-links > .topnav-action, .topnav .nav-links > .topnav-action:link, .topnav .nav-links > .topnav-action:visited, .topnav .nav-links > .topnav-action:hover, .topnav .nav-links > .topnav-action:active, .topnav .nav-links > .topnav-action:focus, .topnav .nav-links > .topnav-action:focus-visible { color: var(--ink); background: #fff; border: 2px solid #fff; padding: 8px 16px; } .topnav .nav-links > .topnav-action:hover { opacity: 0.92; } .topnav .nav-links > .topnav-action:focus-visible { outline: 3px solid #fff; outline-offset: 3px; } /* The app bar pulls its row 12px past the column so its LAST item's own padding ends on the wordmark's edge; a filled button's padding is its box, so the public bar with one keeps the row on the column instead. */ .appnav .nav-links:has(> .topnav-action) { margin-right: 0; } /* An inline glyph beside a nav label (task #572). Only the support section's menu uses one now (the public bar's Login lost its glyph in task #955 pass 3): the app's own icons come from the merchant's Font Awesome kit, which sizes them itself. 1.125em keeps the sheet's hand-drawn bar marks one size, and em keeps it tracking the label. */ .topnav-glyph { width: 1.125em; height: 1.125em; } /* --- authenticated app header (task #449) --- Scoped to `.appnav`, which only MerchantNav sets, so the public landing nav (plain `.topnav`, white bar, dark wordmark) keeps its existing look. The bar is LoyalPack ink edge to edge with the approved white wordmark at 46px tall, and every nav item, the Log out button included, shares one typography and hit-area rule below. Square corners throughout. Interaction (Sam's refinement): no boxes at all. Items are white at rest, the label and its icon turn LoyalPack purple on hover, and the current section is marked by a 2px square-ended purple bar under the item. Measured contrast against the ink bar (#15111b), WCAG 2.2 relative luminance: white #ffffff 18.62:1 purple #5238bf 2.37:1 Purple therefore fails AA for text (4.5:1) and 1.4.11 for non-text (3:1). Sam asked for purple hover explicitly, so hover is purple: it is transient, pointer-only, and carries no information the label does not already state. Everything a keyboard or screen-reader user depends on stays high contrast: - the current section keeps WHITE text (18.62:1) and uses purple only for the bar, which is Sam's own stated fallback for insufficient contrast; - the section is also announced by aria-current="page", so the bar is never the only signal; - :focus-visible keeps white text and swaps the bar to white, so the keyboard indicator never depends on the low-contrast purple. */ .appnav { background: var(--ink); border-bottom: none; flex-wrap: wrap; gap: 8px 16px; } .appnav .brand { color: #fff; } .appnav .brand-logo { height: 46px; } .appnav .nav-links { flex-wrap: wrap; /* Tighter than the public nav's 18px because each item now carries its own 12px of horizontal padding: the padded hit areas supply the rhythm. */ gap: 2px 6px; /* Cancel the last item's padding at the bar's right edge, so "Log out" ends the same 20px in from the edge as the wordmark starts on the left. */ margin-right: -12px; } /* One rule for anchors and the Log out button. The button is reset to nothing (no border, no background, no appearance, no underline) and given the exact font, colour, line-height, padding and alignment of its sibling anchors, so it sits on the same baseline in the same flex row rather than riding high. 10px + 24px + 10px = a 44px touch target. */ .appnav .nav-links > a, .appnav-logout { position: relative; display: inline-flex; align-items: center; margin: 0; padding: 10px 12px; border: none; border-radius: 0; background: none; -webkit-appearance: none; appearance: none; gap: 5px; font-family: inherit; /* Sam, task #529: 16px semibold. The labels lost a pixel of size and gained the weight back, which reads as firmer against the ink bar and matches the Scan action beside them (already 1rem/600), so the whole bar is one typographic voice. Nothing else about the item moved: the 10px + 24px + 10px box, and so the 44px touch target, is unchanged. */ font-size: 1rem; font-weight: 600; line-height: 24px; color: #fff; text-align: left; text-decoration: none; cursor: pointer; transition: color 120ms ease-in-out; } /* Font Awesome icons (Sam's Pro kit, loaded by MerchantNav). The kit swaps each for an inline . Until it does, the placeholder is display:none, which means: - nothing reserves space, so there is no blank icon column and no reflow flash while the deferred kit is still loading; - if the kit is blocked, fails or is simply switched off, the nav is exactly the row of labels it was before, with no phantom gap (a display:none child is not a flex item, so the 5px gap above is not generated for it either). The svg is a real flex item, so it picks up that 5px gap and the centre alignment. Width comes from Font Awesome's own fa-fw class, so every label starts at the same offset. Colour is currentColor throughout, which is what makes the icon follow the label to purple on hover and stay white on focus and on the current item. */ .appnav .nav-links > a > i, .appnav-logout > i { display: none; } .appnav .nav-links > a > svg, .appnav-logout > svg { flex: none; color: inherit; } /* The Log out form is a flex item like any anchor: no browser default margin, no extra box, nothing to knock the button out of line. */ .appnav-form { display: flex; margin: 0; } /* The indicator bar. Every item carries it, transparent by default and positioned out of flow, so switching page or tabbing through the nav can never change an item's width, height or baseline. Square ends: no radius. */ .appnav .nav-links > a::after, .appnav-logout::after { content: ''; position: absolute; left: 12px; right: 12px; bottom: 4px; height: 2px; border-radius: 0; background: transparent; } /* Hover: the label alone turns LoyalPack purple. No background, border, pill, shadow or underline (see the contrast note above). */ .appnav .nav-links > a:hover, .appnav-logout:hover { color: var(--brand-fixed); } /* LOGOUT IS THE ONE RED THING IN THE MENU (Sam, task #831 review: "make the logout link red with a logout icon"). Two declarations and nothing else: it keeps the shared rule's typography, padding, icon gap, reserved indicator slot and focus behaviour, so it is the same menu item as its neighbours and only its colour says that it is the one that ends something. --ink-danger is the product's red lifted until it reads on the ink (6.71:1; --error itself is 2.85:1 there). The hover step is a lighter red rather than the purple its neighbours take: an item Sam asked to be red should not stop being red under the pointer, and the purple is 2.37:1 anyway. Focus is left to the shared rule, which is deliberately the highest-contrast state in the bar: white label, white indicator bar. Colour is currentColor throughout, so the sign-out icon follows the label through all three states. */ .appnav-logout { color: var(--ink-danger); } .appnav-logout:hover { color: var(--ink-danger-hover); } /* Current section: white label, purple bar, plus aria-current="page" in the markup. Log out is an action rather than a place, so it never gets this. */ .appnav .nav-links > a[aria-current='page']::after { background: var(--brand-fixed); } /* Keyboard focus, independent of both of the above and deliberately the highest-contrast state in the bar: white label, white bar, still no box. Placed after the aria-current rule so a focused current item shows the white indicator rather than the purple one. */ .appnav .nav-links > a:focus-visible, .appnav-logout:focus-visible { outline: none; color: #fff; } .appnav .nav-links > a:focus-visible::after, .appnav-logout:focus-visible::after { background: #fff; } /* The wordmark link is an image, so it has no label to underline: it keeps a plain white ring, inset so it never clips against the bar edge. */ .appnav .brand:focus-visible { outline: 2px solid #fff; outline-offset: -2px; } /* Forced-colours mode paints its own palette and drops background images, so the bar above would vanish. Hand focus back to a system outline there. */ @media (forced-colors: active) { .appnav .nav-links > a:focus-visible, .appnav-logout:focus-visible { outline: 2px solid; outline-offset: -2px; } } /* --- mobile header controls (task #458) --- The burger is mobile-only: hidden here at desktop widths so the desktop bar is byte-for-byte unchanged, and revealed in the phone breakpoint below. It used to share this rule with a standing Scan action pinned to the bar's right; task #784 took the web scanner out of the app, so the burger is the only mobile-only control left. Square corners throughout, matching the app chrome (this whole block is asserted to carry no rounded corners). */ .appnav-burger { display: none; } /* A real button reset to nothing, then given a 44px square touch target. */ .appnav-burger { align-items: center; justify-content: center; width: 44px; height: 44px; margin: 0; padding: 0; border: none; border-radius: 0; background: none; -webkit-appearance: none; appearance: none; color: #fff; cursor: pointer; } .appnav-burger:focus-visible { outline: 2px solid #fff; outline-offset: -2px; } /* Two inline-SVG glyphs, no icon font: three bars when the menu is closed and an x-mark when it is open. The swap is driven purely by the button's aria-expanded, which the script keeps in step, so the icon can never disagree with the menu state. */ .appnav-burger-bars, .appnav-burger-x { display: block; width: 24px; height: 24px; } .appnav-burger-x { display: none; } .appnav-burger[aria-expanded='true'] .appnav-burger-bars { display: none; } .appnav-burger[aria-expanded='true'] .appnav-burger-x { display: block; } /* The dedicated mobile navigation is a separate element from the desktop link row (task #458, Sam's restructure); its own styles live in the "mobile overlay nav" section further down. Hidden at every width by default. */ .appnav-mobile { display: none; } /* Phones: the wordmark steps down to 34px (still well above the old 26px). The bar keeps burger and wordmark on one stable row; the desktop link row is hidden (never repurposed) and the overlay nav takes over the menu. */ @media (max-width: 720px) { .appnav { padding: 10px 14px; /* The intentional gap between the burger and the wordmark (task #811, Sam). 12px, which is a clear, deliberate space next to the burger's own 44px square: the glyph inside that square is 24px, so it leaves 10px of its own on the right, and the wordmark starts about 22px clear of the drawn bars without either control looking adrift from the other. */ gap: 0 12px; } .appnav-burger { display: inline-flex; } /* THE WORDMARK SITS AT THE LEFT, BESIDE THE BURGER (task #811, Sam: align the logo left with a suitable gap after the burger). The bar inherits `justify-content: space-between` from `.topnav`, and on a phone the desktop link row is display:none, so it is not a flex item at all: that left the bar with exactly two items and pushed the wordmark hard against the RIGHT edge, with the 8px gap above never able to apply. An auto margin absorbs free space BEFORE justify-content distributes any, so one declaration here puts the whole of that slack on the wordmark's right and the two controls read as the pair they are. Deliberately an auto margin rather than a `justify-content` override: it is also exactly what space-between was doing on a bar that has no burger (the public card designer and the support section wear this bar's look without its machinery, and keep their link row visible on a phone - see the `:not(:has(.appnav-burger))` rule below), so that bar keeps exactly the layout it already had. */ .appnav .brand { margin-right: auto; } .appnav .brand-logo { height: 34px; } /* The desktop link row is not used on a phone: the overlay nav carries the same destinations. Kept in the DOM so desktop is byte-for-byte untouched. */ .appnav .nav-links { display: none; } /* UNLESS THERE IS NO BURGER TO REACH THEM BY (task #572). The rule above is safe in the app because .appnav-mobile carries the same destinations behind the burger. A PUBLIC bar wearing this treatment has neither: the card designer and the support section render the bar's look without any of its machinery, so on a phone the rule above was leaving a signed-out visitor a wordmark and nothing else, with no way to reach Log in. Keyed off the burger's own absence rather than a class on the bar, because that is the one fact the question turns on: the row IS the menu whenever nothing else is. A signed-out app page gets the same answer for the same reason. Browsers without :has() are exactly where they were. */ .appnav:not(:has(.appnav-burger)) .nav-links { display: flex; } } .inline-form { display: inline; } /* --- mobile overlay nav (task #458, Sam's restructure) --- The phone menu is a dedicated placeholder shows nothing until the kit replaces it with an . */ .appnav-mobile a > i { display: none; } .appnav-mobile a > svg, .appnav-mobile .appnav-logout > svg { flex: none; width: 1.1em; color: inherit; } .appnav-mobile a:hover { color: var(--brand-fixed); } /* Restated after the row rule above, which paints every item in the menu white, because this is the one item that is not: Sam's red, in the shade that reads on the ink (6.71:1), with the same lighter-red hover the bar's own logout takes. */ .appnav-mobile .appnav-logout { /* The form around it is a block and the button inside it is not, so this is what makes the whole row touchable rather than only the label. */ width: 100%; color: var(--ink-danger); } .appnav-mobile .appnav-logout:hover { color: var(--ink-danger-hover); } /* The indicator bar every item in the horizontal bar reserves is not part of this menu's vocabulary: here the current item is marked by the left edge, and the logout item is never current anyway. Dropped rather than left to paint a stray white line across the bottom of a focused row. */ .appnav-mobile .appnav-logout::after { display: none; } .appnav-mobile a[aria-current='page'] { border-left-color: var(--brand-fixed); } .appnav-mobile a:focus-visible, .appnav-mobile .appnav-logout:focus-visible { outline: 2px solid #fff; outline-offset: -2px; } /* THE SAME BOTTOM GROUP THE COLUMN HAS (Sam, task #831 review). The open overlay is a full-height flex column, so one auto margin puts Account and the way out at the foot of it, with the places above. If the list is long enough to fill the screen the auto margin resolves to nothing and the menu simply scrolls, so a small phone never loses the two items to the fold. */ .appnav-mobile-foot { margin-top: auto; } /* Open: lock the page behind, pin the header to the top so its controls stay visible and reachable, and drop the overlay from just under the header to the bottom of the viewport, full width and opaque, covering page header, body and footer. */ html.appnav-open, html.appnav-open body { overflow: hidden; } html.appnav-open .appnav { position: fixed; top: 0; left: 0; right: 0; z-index: 30; } html.appnav-open .appnav-mobile { display: flex; flex-direction: column; position: fixed; top: var(--appnav-h, 64px); left: 0; right: 0; bottom: 0; z-index: 20; padding: 8px 0 24px; background: var(--ink); overflow-y: auto; } } /* --- the signed-in app's left menu bar (task #831, Sam) --------------------- Sam's brief, in his words: a vertical menu bar down the left of the page in the ink, the page's content on the right, the brand purple header strips at the top of that right-hand area rather than spanning the whole window, a footer in a different colour so it is not read as more of the left bar, and in the bar itself the logo, a space, a border, a space, and then the menu items, comfortably spaced with a bit more room between each icon and its label. This is the first pass of that. IT IS THE SAME BAR. MerchantNav still renders one `.topnav.appnav` carrying a wordmark and a `.nav-links` row of items built from NAV_ITEMS, and this section turns that row on its side above the phone breakpoint. That is deliberate and is what keeps the change small: - Sam's review of this pass added ONE thing to the markup: a second `.nav-links` list, `.nav-foot`, holding Account and a logout control, so the two items about the person at the keyboard sit at the bottom of the column rather than at the end of the list of places. It is the same list element with the same items in it, so every rule below dresses it without being told, and the phone menu carries the same group for the same reason. See AppNavFoot in views/layout.tsx; - the destinations, their order, their icons and their active state are still NAV_ITEMS resolved server-side, so nothing here can disagree with the footer's Navigate column or with the phone menu; - the phone keeps EXACTLY the header it has had since task #458 - ink bar, burger, full-page overlay - because every rule here is behind `min-width: 721px`, which is the same edge the burger appears at. There is one breakpoint in this shell, not two, so there is no width at which both treatments or neither applies; - the public pages that wear the app bar's LOOK without its machinery are untouched. There are two ways a page can be one, and the selector below answers both: the card designer renders `.appnav` on a body that is NOT `app-shell`, so the first half of the selector excludes it; the two legal pages render `.appnav appnav-plain` on a body that IS `app-shell` when somebody is signed in (legal.tsx passes `app={Boolean(session)}`, and public-chrome.tsx draws that bar for task #759). `appnav-plain` is the class those pages already carry to NAME "the ink bar with no machinery behind it", so excluding it is exactly the question being asked: this rule is about the app's real menu, and a public page's bar stays a bar across the top. - so is the counter poster, which is an app-shell page with a header strip and no nav at all. `:has()` is what tells that apart, and it is the honest test: this is a rule about pages that HAVE a menu bar. - AND THE SUPPORT SECTION IS IN, DELIBERATELY, SINCE TASK #843. It is public, and it is on this shell on purpose: Sam asked for it to be laid out like the app, so it renders `.topnav.appnav` on an `app-shell` body and every rule in this block applies to it unchanged. It carries one extra class, `support-shell`, which nothing here reads; that is for the one thing this shell cannot answer for it, an extra band under the strip (see the support shell block at the end of this file). THE SHELL IS A GRID ON , which is where the four surfaces already are: Layout renders the nav, the header strip,
and the footer as four body-level siblings (see its `header` prop, and task #456's note on why the strip is not inside the column). So placing them is two columns and three rows and no new element: column 1, all rows the menu bar column 2, row 1 the purple page header strip column 2, row 2 (1fr)
column 2, row 3 the footer The 1fr on the middle row is what the flex column on `body.has-app-footer` was doing before it: a short page still puts the footer at the bottom of the window rather than half way up it. This rule outranks that one on specificity, and pages with no footer are covered by the same three rows, with the third simply empty. */ @media (min-width: 721px) { body.app-shell:has(.appnav:not(.appnav-plain)) { /* The bands inside the content column bleed to the content AREA now, not to the window. See --bleed-w's note in the token list: this is the one place that hands it the narrower surface, and the four bands that read it did not have to learn anything about a menu bar. */ --bleed-w: calc(100vw - var(--sidebar-w)); display: grid; grid-template-columns: var(--sidebar-w) minmax(0, 1fr); grid-template-rows: auto 1fr auto; min-height: 100vh; } /* THE MENU BAR SPANS EVERY ROW, so the ink is one column of colour from the top of the window to the bottom of the page whatever is beside it, and the footer's own colour cannot appear to run underneath it. Then it is pinned: `align-self: start` stops the grid stretching it to the height of the whole page, `height: 100vh` gives it the window instead, and `position: sticky` holds that against its full-height grid area as the page scrolls. So the menu is always where it was left, on a long report as much as on the dashboard, and it never scrolls out of reach. `overflow-y: auto` is for the short window (a laptop at 200% zoom) where the items themselves do not fit: the bar scrolls inside itself rather than being cut off. */ body.app-shell:has(.appnav:not(.appnav-plain)) > .appnav { grid-column: 1; grid-row: 1 / -1; position: sticky; top: 0; align-self: start; height: 100vh; overflow-y: auto; /* ABOVE THE CONTENT COLUMN, BY ONE. Nothing in the column should reach the menu, and one thing very nearly does: --bleed-w is the window less the menu, and `100vw` includes a classic (non-overlay) scrollbar, so on a desktop with one a full-bleed band is about 15px wider than the content area really is. It is centred, so half of that lands under the menu's right edge; the other half runs off the window and is clipped at the root exactly as it always was (see the html rule up top). The dashboard's focused band is `position: relative`, so without this it would paint over the menu for those few pixels, being later in the document. One is enough, and one is deliberate: it clears the content column, and it stays well under the phone drawer's 20 and its pinned header's 30, which must go on covering everything. */ z-index: 1; /* The bar is `.topnav`, which is a horizontal flex row with its items pushed apart. On its side it is a plain column that starts at the top: every one of these cancels something that only made sense lying down. */ flex-direction: column; flex-wrap: nowrap; align-items: stretch; justify-content: flex-start; gap: 0; padding: 0; } body.app-shell:has(.appnav:not(.appnav-plain)) > .pagehead { grid-column: 2; grid-row: 1; } body.app-shell:has(.appnav:not(.appnav-plain)) > main.container { grid-column: 2; grid-row: 2; } body.app-shell:has(.appnav:not(.appnav-plain)) > .app-footer { grid-column: 2; grid-row: 3; } /* THE LOGO, A SPACE, A BORDER, A SPACE, THEN THE ITEMS (Sam). The four are drawn by two rules and no extra element: the wordmark's own generous padding is the space above and below it, and the item list's top border and top padding are the border and the space under it. The border runs the full width of the bar because the list is stretched to it, which is what makes it read as the bar's own division rather than as a rule over the links. The wordmark keeps the 46px it has on the desktop bar (task #449): at 268px wide the column has room for it at its natural proportions, which is what "comfortably sized" means for a piece of artwork. */ body.app-shell:has(.appnav:not(.appnav-plain)) > .appnav .brand { flex: none; justify-content: flex-start; padding: 30px 24px; } body.app-shell:has(.appnav:not(.appnav-plain)) > .appnav .nav-links { flex: none; flex-direction: column; align-items: stretch; flex-wrap: nowrap; gap: 0; /* The row's -12px right margin cancelled the last item's padding against the window's right edge. There is no such edge here. */ margin: 0; /* NOTHING ABOVE THE FIRST ITEM (task #833, Sam): the list starts directly under the wordmark's own block, so the border below is the division and the space above it is the wordmark's padding, once, rather than that padding plus a second gap nobody asked for. The 24px under the last item stays: that is the end of the menu, not a join. */ padding: 0 0 24px; border-top: 1px solid rgba(255, 255, 255, 0.16); } /* TWO GROUPS, AND THE SECOND ONE IS HELD AT THE BOTTOM (Sam, task #831 review: "move both account and logout to fixed position on the bottom of the vertical menu"). The bar is a flex column of the height of the window, so the whole of that is one declaration: the list of places takes every spare pixel, which leaves the group of two sitting on the foot of the column whether the page above it is the dashboard or a fifty-row report. `1 0 auto` rather than `1`: grow into the slack, but never shrink below the items' own height. On a short window (a laptop at 200% zoom) there is no slack to take, the two groups meet in the middle, and the bar scrolls inside itself as it already did rather than compressing the items into each other. The group is a `.nav-links` list of its own, so it has taken the rule above as it stands: the same 16% division over it that the wordmark has under it, and the same 24px under its last item, which is now the bottom of the menu. */ body.app-shell:has(.appnav:not(.appnav-plain)) > .appnav .nav-links:not(.nav-foot) { flex: 1 0 auto; } /* ONE ITEM: full width, comfortably tall, and with real room between the icon and the word. 14px + 24px + 14px is a 52px row, up from the bar's 44px, because a column has the height to spend and a menu of eight items reads better spaced than packed. The 16px gap is Sam's "a bit more space between icon and text", against the 5px the horizontal bar uses, where the items sit side by side and every extra pixel is width off the next label. */ body.app-shell:has(.appnav:not(.appnav-plain)) > .appnav .nav-links > a, body.app-shell:has(.appnav:not(.appnav-plain)) > .appnav .appnav-logout { gap: 16px; padding: 14px 24px; } /* THE BOTTOM GROUP IS A STEP SMALLER (Sam: "perhaps smaller"), and it is the items that shrink rather than the column: 15px type in a 44px row, against the 16px and 52px above. That is a plain step down in the same voice, and 44px is exactly the touch floor, so the two rows a merchant reaches for least are still rows a thumb can land on. 10px + 24px + 10px, the same arithmetic the horizontal bar's items use. `padding-block` rather than the shorthand, deliberately: the left edge the labels start on is the column's, not this group's, and it steps to 18px on a small laptop with everything else in the bar. Setting the shorthand here would have been more specific than that step and quietly held these two items 24px in while the seven above them moved. */ body.app-shell:has(.appnav:not(.appnav-plain)) > .appnav .nav-foot > a, body.app-shell:has(.appnav:not(.appnav-plain)) > .appnav .nav-foot .appnav-logout { padding-block: 10px; font-size: 0.9375rem; } /* The subtle horizontal border between items Sam asked about. White at 7% on the ink, which is a division you notice only once you look for it: enough to give the column a rhythm, not enough to draw eight boxes. It is between the items and never above the first or below the last, so it can never be confused with the bar's own border above. The second selector is that same division inside the bottom group, where the row under Account is a form rather than an anchor and `a + a` cannot see it. Same rule and same 7%: that group is two items, and two items are divided like any other two. The mark below starts at `-1px`, so a current or focused item still draws one unbroken bar over the division. */ body.app-shell:has(.appnav:not(.appnav-plain)) > .appnav .nav-links > a + a, body.app-shell:has(.appnav:not(.appnav-plain)) > .appnav .nav-foot > .appnav-form { border-top: 1px solid rgba(255, 255, 255, 0.07); } /* THE CURRENT SECTION'S MARK TURNS THROUGH NINETY DEGREES WITH THE BAR, and it is the same mark: every item already carries an empty, out-of-flow ::after that the aria-current and :focus-visible rules up in the header block colour purple and white. Here it is re-laid as a bar down the item's leading edge instead of under its label, so switching page still cannot move an item by a pixel, and both of those rules keep working untouched. Square-ended and 3px, and the item's label stays white: purple on ink is 2.37:1, so the colour is the mark and never the text, exactly as the horizontal bar and the phone overlay (which has drawn a purple left edge on its current item since task #458) already have it. `top: -1px` covers the divider above, so a current item's mark is one unbroken bar. Hover is inherited and unchanged: the label and its icon turn LoyalPack purple, with no background, box or underline anywhere. */ body.app-shell:has(.appnav:not(.appnav-plain)) > .appnav .nav-links > a::after, body.app-shell:has(.appnav:not(.appnav-plain)) > .appnav .appnav-logout::after { inset: -1px auto 0 0; width: 3px; height: auto; } /* AND THE CURRENT ROW IS FILLED (task #852, Sam: make where you are obvious at a glance). The 3px mark above was the whole of it, and down a 268px column of eight evenly spaced rows a 3px edge is not enough to find without looking for it: it reads at the moment you go hunting, which is exactly the moment you should not have to. So the row itself takes the brand fill (--nav-current-fill in the token list, where the contrast measurements are), and its label goes from 600 to 700. Three signals now, none of them the only one: a filled band, a purple leading bar, and a bolder white word. Nothing else about the row moves - the fill paints the border box the row already occupied, so the column's rhythm and every item's baseline are untouched. ONE RULE FOR BOTH COLUMNS, AND IT HAS TO BE (Sam: the same treatment in the app and in Support). The app's items are anchors in a `.nav-links` list and Support's are two levels of list, so they cannot share a selector, but they can and do share a declaration block: adding a state to one here is adding it to the other, which is the drift this task was fixing. WHY IT IS INSIDE THIS BREAKPOINT. This is the treatment for the VERTICAL menu. Below 721px both sections put their items in a full-screen drawer where the current row is already marked by its own left edge and nothing is hard to find on a list you opened on purpose, so the phone keeps exactly what it has. Hover is untouched and stays a colour: an inactive row a pointer is over has no background of any kind, so it can never be read as the selected one. */ body.app-shell:has(.appnav:not(.appnav-plain)) > .appnav .nav-links > a[aria-current='page'], body.app-shell:has(.appnav:not(.appnav-plain)) .support-side [aria-current='page'] { background: var(--nav-current-fill); font-weight: 700; } /* AND THE FILLED ROW HOVERS TO LILAC, NOT TO PURPLE (Sam, task #852 review: "the brand purple is too close to the bg purple on the active state"). He is right, and it is measurable: the nav's hover colour is --brand-fixed, which is 18.62:1 on the bare ink and only 1.71:1 on the fill this task put behind the current row. So the one row a merchant is standing on was the one row whose label faded when they pointed at it. --strip is the product's lilac and reads 9.24:1 there, so hover stays a real response and the label gets clearer rather than dimmer. THIS IS THE SAME EXCEPTION TASK #760 ALREADY MADE, in the same words: the page header tabs hover from white to this lilac because the nav's purple was settled for labels on a LIGHT surface and says nothing useful on a purple one. Reusing --strip rather than minting a colour is what keeps the two purple surfaces in the app answering this the same way. Only the current row, and only in this column: an inactive row is on the bare ink where the purple is 18.62:1 and Sam's standing hover rule is exactly right, so it is untouched, and so are both phone drawers, which have no fill for the purple to disappear into. Focus is left alone deliberately. `:focus-visible` on its own still gives the white label and the white mark that the keyboard indicator depends on; only pointing at an already-focused current row lands here, and 9.24:1 is nowhere near a contrast question. */ body.app-shell:has(.appnav:not(.appnav-plain)) > .appnav .nav-links > a[aria-current='page']:hover, body.app-shell:has(.appnav:not(.appnav-plain)) .support-side [aria-current='page']:hover { color: var(--strip); } /* A guide inside an open topic rests at 78% white, a step quieter than the topic above it. On the fill it is the current row, so it takes the full white the app's items already have: the hierarchy that 78% draws is between the RESTING rows, and the one you are reading is not one of them. 12.99:1, against 8.49:1 had it stayed quiet. */ body.app-shell:has(.appnav:not(.appnav-plain)) .support-side-guides > li > a[aria-current='page'] { color: #fff; } /* The one thing on a signed-in page that is pinned to the WINDOW rather than laid out in the grid: the Card Design page's pull-up preview (task #612), which is a fixed drawer along the bottom edge below 980px. Between this breakpoint and that one the two overlap, and a drawer starting at the window's left edge would run under the menu bar and centre its phone on the window instead of on the page. Starting it at the menu's inside edge puts it back over the content it previews. Nothing else about the drawer moves: its own width ceiling (--pullup-w) is the frame's 374px at every width this rule applies to. */ body.app-shell:has(.appnav:not(.appnav-plain)) .preview-pullup { left: var(--sidebar-w); } } /* A small laptop pays for the column out of the menu rather than out of the page. One step, at the width where a 1120px content column stops fitting beside a 268px bar anyway, and nothing else moves: --bleed-w is expressed in this token, so the bands beside it follow on their own. */ @media (min-width: 721px) and (max-width: 1023px) { body.app-shell:has(.appnav:not(.appnav-plain)) { --sidebar-w: 228px; } body.app-shell:has(.appnav:not(.appnav-plain)) > .appnav .brand, body.app-shell:has(.appnav:not(.appnav-plain)) > .appnav .nav-links > a, body.app-shell:has(.appnav:not(.appnav-plain)) > .appnav .appnav-logout { padding-inline: 18px; } /* The wordmark is 196px wide at its 46px, and this column's 192px of content width is four short of it: two pixels down keeps the artwork at its proportions (187px wide) and inside the padding. */ body.app-shell:has(.appnav:not(.appnav-plain)) > .appnav .brand-logo { height: 44px; } } .btn-link { background: none; border: none; padding: 0; color: var(--ink); font: inherit; cursor: pointer; text-decoration: underline; } /* --- buttons --- Square, and square HERE (task #839, Sam). Every button in the product wears this class, so the shape is settled once at the base and nothing downstream needs to restate it: the Program page's copy, download and settings buttons all used to carry their own `border-radius: 0` and no longer do. A component rule below may say how a button sits in its row (flex, width, height) but not how round it is. The number matches --control-radius, asserted as an equality in test/form-controls.test.ts, so a button and the field beside it cannot drift apart. */ .btn { display: inline-block; background: var(--brand); color: #fff; border: 2px solid var(--brand); border-radius: 0; padding: 10px 18px; font: inherit; font-weight: 600; text-decoration: none; cursor: pointer; text-align: center; } .btn:hover { filter: brightness(1.08); } .btn-big { padding: 14px 26px; font-size: 1.05rem; } .btn-small { padding: 6px 14px; } .btn-ghost { background: transparent; color: var(--brand); } .btn-dark { background: var(--ink); border-color: var(--ink); } .btn-brand { background: var(--brand); border-color: var(--brand); } /* Non-interactive placeholder (e.g. wallet "coming soon" buttons). */ .btn-disabled { opacity: 0.45; cursor: default; pointer-events: none; } button:disabled { opacity: 0.55; cursor: wait; } /* --- cards & layout --- */ .card { background: var(--card); border: 1px solid var(--line); border-radius: 14px; padding: 24px; margin: 16px 0; } .narrow { max-width: 460px; margin-left: auto; margin-right: auto; } /* .branded-top is GONE (task #567, Sam). It was `border-top: 6px solid var(--brand)` on a `.card`, so the enrolment panel was a 14px-rounded white box with a fat brand-coloured bar mitred across its top: the treatment Sam named, and the enrolment page was its only user in the product. The page's own section near the bottom of this sheet replaces it, and deleting the class rather than unhooking it is what stops it being reached for again. */ .two-col { display: grid; grid-template-columns: 1fr 1fr; gap: 16px; } @media (max-width: 720px) { .two-col { grid-template-columns: 1fr; } } .muted { color: var(--muted); } .small { font-size: 0.85rem; } .center { text-align: center; } .error { color: var(--error); font-weight: 600; } .success { color: var(--success); font-weight: 600; } .success.big { font-size: 1.1rem; } /* --- the app message bar (task #543) --------------------------------------- One appearance for every "did that work?" answer in the signed-in app. The stack is rendered by src/views/app-message.tsx as the FIRST child of
, which is the placement the brief asks for: on the grey page background at the top of the content column, never inside the white box the form happens to live in. The boundary rule further up (main.container > :first-child { margin-top: 0 }) means the column's own 30px token is still the whole distance from the header strip, exactly as it is on a page with no message. */ .app-messages { display: flex; flex-direction: column; gap: 10px; margin: 0 0 20px; /* STICKY, 30px FROM THE TOP OF THE SCREEN (task #602, Sam). The bar was correct and unseen. A refusal from a field near the BOTTOM of a long form (Sam's case: leaving just `#` in Card Design's stamp area colour) re-renders the page with the reason at the top of the column, and the browser restores the scroll position you submitted from, which is nowhere near it. Nothing was broken: the message was announced, addressed and escaped. It was simply above the window. The STACK sticks, not each message, and that is what makes one declaration enough. Its containing block is
, which spans the whole scrollable page, so the messages are pinned for the entire scroll and settle back into their own place at the top when you return to it. Nothing below moves: a sticky box keeps its space in flow, so the page is laid out exactly as it was before this rule. THE OFFSET IS THE COLUMN'S OWN 30px TOKEN, not a second number that happens to match. At rest the bar sits --main-pad-top below the header strip; stuck, it sits --main-pad-top below the top of the window. One value, one place to change it, and the gap above the bar reads the same either way. IT CANNOT COVER THE HEADER. Nothing above the bar in its own column is fixed or sticky: the page header strip scrolls away like everything else. So the bar only reaches its 30px once the header has already passed it, and while the header is on screen the bar is still 30px UNDER it, exactly where it has always been. There are two pinned things in the shell and neither is above it: the phone's nav drawer, only while it is open, which the z-index below handles; and, since task #831, the desktop menu bar, which is a sticky item in the OTHER column of the body grid and so has nothing of this column to cover. z-index 5 is the smallest value that works from both sides: it clears every layer inside the content column (the highest is the half-phone preview's 3) so a message is never scrolled behind a card or a sticky preview rail, and it stays well below the mobile nav's drawer at 20 and its pinned header at 30, both of which must cover the page. */ position: sticky; top: var(--main-pad-top); z-index: 5; /* NOT clipped here, deliberately. Clipping the stack was the obvious way to keep the entrance tidy, and it is wrong twice: it cuts the contact shadow off the bottom of the last message, and it cuts the focus ring off a message that has taken focus, which is the one ring in this block that must never be lost. Nothing needs clipping anyway: `html { overflow-x: clip }` already stops a horizontal scrollbar, so a bar travelling in from off-screen costs the page nothing. */ } .app-message { position: relative; display: flex; align-items: flex-start; gap: 12px; /* Square edged, on Sam's follow-up: no radius here and none on anything inside, so the bar is a plain block of colour at the top of the column. The extra 3px underneath is the countdown runner's own room, because the runner is drawn INSIDE the box now rather than as a border outside the padding: the text stops above it instead of the box growing an edge. */ padding: 14px 16px 17px; font-weight: 600; line-height: 1.45; /* A low shadow of the page's own ink, which is the other half of what "a slightly darker bottom edge" bought: the bar rests on the page. */ box-shadow: 0 1px 0 rgba(21, 17, 27, 0.05), 0 6px 18px rgba(21, 17, 27, 0.09); /* Slides in across to the left (Sam). `backwards`, deliberately NOT `both`: the fill mode has to stop applying when the animation ends, or the final keyframe's transform: translateX(0) would out-rank the exit's declared transform in the cascade and the message could never slide away. */ animation: app-message-in 340ms cubic-bezier(0.16, 0.84, 0.44, 1) backwards; } /* The countdown (Sam's follow-up). The darker bottom edge is now the clock: it spans the bar when the message arrives and shortens away to nothing over the ten seconds it has left, so "this is about to go" is visible rather than a surprise. Three things about the shape are load-bearing: - it is a pseudo-element INSIDE the box, not a border. A border sits outside the padding and adds to the height, which is what Sam asked us to undo; this one takes no space at all and cannot move the page as it goes. - the width is a scaleX rather than a `width`, so a frame of the countdown is a composited transform and never a layout. - the fraction is a custom property written by /static/app-message.js. With no script (or before it starts) it resolves to the fallback 1 and the runner is simply the darker bottom edge it always was. Freezing it is therefore nothing more than the script stopping writing, which is exactly what "the border becomes stationary" has to mean. */ .app-message::after { content: ''; position: absolute; left: 0; right: 0; bottom: 0; height: 3px; background: var(--app-message-edge); transform: scaleX(var(--app-message-left, 1)); transform-origin: left center; } /* A simple stack, gently staggered, so two messages arrive as a sequence rather than as one lurch. Four is more than any route can currently produce (the Account security tab's connect/disconnect/confirm notices are the widest case); a fifth simply arrives with the fourth. */ .app-message:nth-child(2) { animation-delay: 70ms; } .app-message:nth-child(3) { animation-delay: 140ms; } .app-message:nth-child(4) { animation-delay: 210ms; } /* Measured from the bar's OWN width, never the viewport: the stylesheet keeps exactly one 100vw element (the dashboard's full-bleed band, guarded by test/content-grid.test.ts) and a transform is not worth being the second. On a wide screen that means the sweep begins in the gutter beside the content column rather than beyond the window, which reads the same and travels less. */ @keyframes app-message-in { from { transform: translateX(100%); opacity: 0; } to { transform: translateX(0); opacity: 1; } } /* Then leaves UPWARDS (Sam), rising out of its own space as it fades rather than sweeping sideways again: the message came in from the side to be noticed, and it goes the way everything above the fold goes when it is finished with. Measured against its OWN height, so a one-line confirmation and a three-line refusal both clear themselves. Added by /static/app-message.js, either on the ten-second countdown or on the dismiss button; the script removes the node when this finishes. */ .app-message-out { transform: translateY(-100%); opacity: 0; transition: transform 260ms ease-in, opacity 260ms ease-in; } .app-message-text { margin: 0; flex: 1 1 auto; /* A long unbroken reason (a filename, a pasted URL) must not push the dismiss button out of the bar. */ min-width: 0; overflow-wrap: anywhere; } .app-message-mark { flex: 0 0 auto; /* Optically centred on the first line of text rather than on its box. */ margin-top: 1px; } .app-message-close { flex: 0 0 auto; display: inline-flex; align-items: center; justify-content: center; width: 28px; height: 28px; padding: 0; margin: -3px -4px 0 0; border: 0; background: transparent; color: inherit; cursor: pointer; opacity: 0.7; } .app-message-close:hover { opacity: 1; background: rgba(21, 17, 27, 0.09); } /* The bar's ink is a near-black, so the app's purple focus ring would be the lower-contrast of the two options here. Its own ink is the visible one. */ .app-message-close:focus-visible { outline: 2px solid currentColor; outline-offset: 2px; } /* A fieldless error takes focus (see AppMessageBar's `focus`), so the whole bar can be the focused element. Its ring is drawn just INSIDE its own edge: an outward ring on a box that already has a 3px bottom border and a contact shadow reads as a smudge, and an inset one cannot be clipped by anything. */ .app-message:focus-visible { outline: 2px solid currentColor; outline-offset: -4px; } /* Each tone names its own edge colour and the shared rule above draws it, so a variant can no more forget the countdown than it could forget the fill. */ .app-message-success { background: var(--msg-success); color: var(--msg-success-ink); --app-message-edge: var(--msg-success-edge); } .app-message-error { background: var(--msg-error); color: var(--msg-error-ink); --app-message-edge: var(--msg-error-edge); } .app-message-warning { background: var(--msg-warning); color: var(--msg-warning-ink); --app-message-edge: var(--msg-warning-edge); } /* A link inside a message (only Billing has one) takes the message's own ink: the brand purple on a saturated fill is neither on-brand nor legible. */ .app-message a { color: inherit; text-decoration: underline; text-underline-offset: 2px; } /* Reduced motion: the message appears and disappears, it just does not travel. The script honours the same preference by removing the node outright rather than waiting for an exit that will not run. The countdown runner keeps working, because it is information rather than decoration: how long you have left to read this is the same fact either way. It is the script that softens it, moving the runner in ten visible steps instead of sliding it every frame, so there is nothing continuously animating on the page. */ @media (prefers-reduced-motion: reduce) { .app-message { animation: none; } .app-message-out { transition: none; } } /* On the auth pages the bar is not a page-level flash but the reason a sign-in or a reset was refused, so it stays in the working column beside the form it is about (src/views/auth-shell.tsx). Only its spacing differs. */ .auth-main .app-messages { margin: 0 0 18px; /* And it does not stick (task #602). The sticky bar answers a problem these pages do not have: an auth page is one short card with nothing to scroll past, and its message is the reason the form directly beneath it was refused rather than a page-level flash. Pinning it to the window would let it drift away from the field it explains, which is the opposite of what #543 put it there for. */ position: static; } /* --- forms --- */ .stack-form { display: flex; flex-direction: column; gap: 16px; text-align: left; } .stack-form label { display: flex; flex-direction: column; gap: 6px; font-weight: 600; } /* THE source for how an editable control looks and how tall it is (task #501). One rule, one set of tokens, and every field a signed-in person types into reads it: the Account and Program-create forms (.stack-form), the scanner's and the landing page's inline rows (.row-form), and the Reports filter bar (.report-field). Those were three separate copies of the same four declarations before this task, and the Reports bar had none of them at all, which is how it came to be a 40px unstyled native control sitting beside a 48.8px Filter button on the same row. The vertical padding is deliberately zero and the height comes from the token instead. A single-line input and a select both centre their own text in the content box, so ONE number gives every control the same border-box height whatever the browser's own metrics for that control happen to be, which is what the padding-plus-line-height arithmetic could never promise. Nothing here resets `appearance`, so a select still draws its own indicator and a date field its own picker button, both inside a box that is now taller than they need rather than tighter (nothing is clipped, on any engine). Two deliberate overrides follow elsewhere in this sheet: the Reports bar takes 10px of inline padding instead (task #496), and the auth shell squares the corners (task #442). The Program settings page keeps its own separate rule: that surface is square by design. */ .stack-form input[type='text'], .stack-form input[type='email'], .stack-form input[type='password'], .stack-form input[type='number'], .stack-form input[type='url'], /* The telephone type joined the list with task #936 (Sam). Account Details' Business phone number (task #850) is type="tel" so a phone offers its number pad, and the sign-up page's phone box (task #805) is the same control. Neither was named here, so each was the browser's own box, 24px tall with a 2px inset grey border and 13px text, standing between a 48px email field and a 48px website field: precisely the mismatch this rule exists to end. The support contact form named its own tel field from the start (below); this closes the gap on the signed-in form and the sign-up form with one selector rather than a copy on each. The ring and the error colour already reached it, because those two rules name `input` by element. */ .stack-form input[type='tel'], /* Date and time joined the list with trading Locations (task #745): the roaming schedule is built from a day, a start and an end, and a native 40px date box beside a 48px name field is precisely the mismatch this rule exists to end. Nothing else in the app asked for either type before, so this adds two controls rather than changing any. */ .stack-form input[type='date'], .stack-form input[type='time'], /* Selects joined this rule with the Business Type field (task #525). It also picks up the invite form's Role select on Account > Users, which was the last unstyled 40px native control sitting beside a 48px text input in this app: exactly the mismatch this rule was written to end, so it is a deliberate inclusion rather than a side effect. The per-member role control is .inline-form and is untouched. */ .stack-form select, .row-form input, /* The scanner's location switcher (task #745), which is a select on a .row-form line beside a button. Every other member of this list is here because a 40px native control beside a 48px one is the mismatch the rule ends, and this is exactly that. */ .row-form select, .report-field input, .report-field select, /* Reports > Overview's two conditional selects (task #807). Named here rather than nested for the reason the list keeps learning: the Overview is not a `.report-field` filter row, and a select that dressed itself only because of where it happened to sit is a control one refactor away from losing its height, its border and its focus ring in silence. */ .ovw-field select, /* The stamp quantity on a customer card's page (task #815). A number somebody types into, standing in a row beside the button that acts on it, which is the exact shape this rule exists for: without naming itself here it would be the 40px-against-48px mismatch beside a 48px Award stamps button, on the one control in the web admin that changes a customer's balance. */ .cust-step-input, /* The trading week's controls on Account > Locations (tasks #786 and #816): a location select, two time boxes and the notice's message, standing in a row together on a pale band. They are not in a `.stack-form`, so without naming themselves here they would be the 40px-against-48px mismatch this rule was written to end. Named rather than nested, which is the lesson `.locmap-query` below cost us. THE TICK BOX IS EXCLUDED, and that exclusion is the whole reason this is two selectors rather than `.sched-cell input`: a checkbox given a 48px height and a full-width border stops looking like a checkbox. */ .sched-cell select, .sched-cell input:not([type='checkbox']), /* The Locations map search (task #778 follow-up, Sam: "the map search input box is not styled"). It USED to be in this rule without naming itself: until #778 the map lived inside `
`, so `.stack-form input[type='text']` reached it. Moving the map out of the settings grid moved it out of that selector too, and the box silently lost its height, its border, its radius and its focus ring while looking like nothing had happened. It is named here now, so the styling no longer depends on where in the page the control happens to sit. */ .locmap-query, /* The public card designer's typed controls (task #572). That page is not a form (it has nothing to submit and no element at all), but a business name field and two selects are still fields somebody types into, and an unstyled 40px native select beside a 48px text input is precisely the mismatch this rule exists to end. So they join the list rather than carrying a fourth copy of these six declarations. A CLASS AND NOT `input[type='text']`, which is what it was before the page took the shared colour well: `.cc-editor input[type='text']` also matches the well's hex field, at a higher specificity than `.colour-well-value`, so it would have dressed a 200px swatch-you-type-into as an ordinary 48px box. The class is opted into by the two fields that want it and reaches nothing inside a component. */ /* The public support section's contact form (task #603). It joins the list for the reason the list exists: an email field on /support and an email field on /account should be the same 48px box with the same border and the same radius, and the way to guarantee that is to have one rule rather than two that agree today. The textarea takes its own height below; everything else about it is this. */ .support-contact-form input[type='email'], .support-contact-form input[type='tel'], .support-contact-form input[type='text'], .support-contact-form textarea, /* Account Details' postal address (task #850), the first textarea a signed-in form has ever carried. It joins the list for the list's own reason: an address box standing directly under a website box should be the same border, the same radius and the same background, and one rule is how that stays true. Its height and its block padding are its own, just below. */ .stack-form textarea, .cc-editor .cc-text, .cc-editor select { min-height: var(--control-height); padding: 0 var(--control-pad-x); border: 1px solid var(--line); border-radius: var(--control-radius); font: inherit; background: var(--card); color: var(--ink); } /* Account Details' postal address (task #850): the one control on a signed-in form that is not a line. --control-height is the floor it inherits from the shared rule above; these four are what a textarea gets wrong without them, and they are `.support-field textarea`'s four for its reasons: it opens one row tall, it can be dragged wider than its own column, its text sits tight against the top border because the shared rule's zero block padding was written for something 48px tall, and it does not inherit the 600 weight of the label above it (nor should the typed address look like a heading). A CLASS OF ITS OWN RATHER THAN `.stack-form textarea` AGAIN, which is the shape `.support-contact-form textarea` and `.support-field textarea` already take. The shared rule above owns appearance and the height FLOOR for every consumer, and test/form-controls.test.ts enforces that no consumer redeclares either: a second `.stack-form textarea` block would be exactly the stale copy that guard exists to prevent. Height that is genuinely this control's own belongs on a selector that is this control's own. */ .stack-textarea { min-height: 7rem; padding: 10px var(--control-pad-x); line-height: 1.55; font-weight: 400; resize: vertical; } /* The field that is wrong, marked on the control as well as in the message bar above it (task #850): colour alone is not a signal everyone receives. The sentence itself lives in the page's one message bar, which is where every outcome on these pages goes since task #543, and each bad control points at its own message with aria-describedby. THE ELEMENT NAMES ARE LOAD-BEARING, exactly as they are for `.support-field` below: `.stack-form [aria-invalid='true']` ties the shared rule on classes and then loses on the element in `input[type='text']`, so only the textarea and the select would have turned red. */ .stack-form input[aria-invalid='true'], .stack-form select[aria-invalid='true'], .stack-form textarea[aria-invalid='true'] { border-color: var(--error); } /* --------------------------------------------------------------------------- The Locations map picker (task #747, restructured by Sam's third review, and moved out of the settings grid by #778). A centred search row and a map, both the full width of the panel they sit in. It replaced three address fields that nothing read: a wallet is given latitude and longitude and nothing else, so the honest control for "where is this" is the one that produces those. WHAT THIS STYLESHEET OWNS AND WHAT THE SCRIPT OWNS. Everything static is here: the frame, the shapes, the colours, where the pin's tip is relative to its box. /static/location-map.js sets exactly three kinds of inline style, all of them positions that change as the map moves: a tile's transform and size, and the pin's left/top. Nothing about how any of it LOOKS is decided in JavaScript, so the control can be restyled here without opening that file. THE COLUMN, top to bottom: the search row, the search's own status line, the results, then the map frame. */ /* THE FULL-BLEED ARITHMETIC IS GONE (task #778), and its absence is the point. Until #778 this control sat in the SECOND track of `.settings-section`'s 2fr/3fr grid and escaped it with a negative margin derived from those proportions, which a test had to hold in step with the grid's own numbers so the map could not quietly start hanging off one side of the card. Sam's restructured add/edit page puts the map in a plain full-width panel ABOVE the settings block instead, so there is no column to escape: the map is as wide as what contains it, and there is one fewer pair of numbers to keep agreed. The top rule went with the margins. It read as a divider between the form and the map, and the map is no longer below the form. */ .locmap { display: flex; flex-direction: column; gap: 14px; margin: 4px 0 0; width: 100%; } /* THE SEARCH ROW: label inline to the left of the box, and the whole row centred over the map (Sam's third review, point 8). Centred rather than left-aligned because the map underneath is now the full width of the card, and a search row pinned to its left edge reads as belonging to the column it came from rather than to the map it drives. */ .locmap-search { display: flex; flex-direction: column; gap: 8px; align-items: center; } .locmap-search-row { display: flex; align-items: center; gap: 10px; /* Wide enough to type an address into, capped so the row stays a row rather than becoming a stripe across a 1120px card. */ width: min(100%, 620px); } /* Inline, and NOT the stacked label the rest of the form uses: `.stack-form label` is a flex column, which would put "Map search" above the box. This is a plain inline label beside its input, so it needs `flex: none` or the flex row would shrink the words before it shrank the box. */ .locmap-search-label { flex: none; font-weight: 600; } .locmap-query { flex: 1 1 auto; min-width: 0; } /* `flex: none` so a long placeholder can never squeeze "Search" onto two lines, which is the failure this arrangement has on a narrow phone if the button is allowed to shrink. THE LOOK IS `.btn-ghost` (task #757, Sam), applied in the markup rather than here: the filled brand button is the one that saves the location, and having a second solid purple button halfway up the form competing with it made the search read as the thing to press last. Outlined says "helper" without inventing a third button style. */ .locmap-go { flex: none; } /* The search's own commentary: searching, how many were found, that nothing was, or the refusal when somebody tries to save with no pin down. Centred with the row it belongs to. */ .locmap-note { margin: 0; font-size: 14px; color: var(--muted); text-align: center; } .locmap-noscript { /* Shown only by the