/* ========================================================================== eSheets Mobile — design system -------------------------------------------------------------------------- Used only by m.php. Nothing else on the site loads this file, and this file loads nothing else — telstyleesheets.css, news.css, tasks.css et al. are all deliberately absent, so no rule here can reach a desktop page and no desktop rule can reach here. Every token is prefixed --m- so that even if this file were ever loaded alongside telstyleesheets.css (which owns the unprefixed --nav-bar-height), nothing could collide. Two standing rules for anyone editing this file: 1. Values live in the token block. If you find yourself typing a colour, a spacing number or a radius anywhere below the ":root" block, it almost certainly wants to be a token instead. Flow learned this the hard way: 26 hand-typed rgba(153, 51, 102, ...) tints came loose from the one variable that was supposed to control them. 2. Contrast ratios in the comments are measured, not guessed. If you change a colour, recompute the pair it is annotated against. The targets are WCAG AA: 4.5:1 for body text, 3:1 for large text and for the boundary of any interactive control. ========================================================================== */ /* ========================================================================== 1. TOKENS ========================================================================== */ :root { /* ---- Brand ----------------------------------------------------------- #993366 is the fixed Trafalgar brand colour. Every other brand value is DERIVED from it with color-mix() rather than typed as a snapshot hex, so a change to --m-brand carries through automatically. The comments record what each mix actually resolves to today, which is what the contrast figures were measured against. */ --m-brand: #993366; /* No separate --m-brand-rgb triplet. A second representation of the same colour is a second thing to keep in sync; where a translucent brand is needed, color-mix(in srgb, var(--m-brand) N%, transparent) derives it from the one source of truth. */ /* = #7a2952. Pressed/active states, and text that needs more weight than the brand itself. 9.27:1 on white, 8.88:1 on --m-surface-alt. Mixed toward --m-weight-base rather than toward `black`, because "more weight than the brand" means "further from the ground", and on a dark ground that direction is white. In this theme the base IS black, so the resolved value is unchanged. */ --m-brand-deep: color-mix(in srgb, var(--m-brand) 80%, var(--m-weight-base)); /* THE BRAND AS INK, which is not the same token as the brand as a FILL. ----------------------------------------------------------------------- --m-brand is a fill: the app bar, the FAB, a pressed chip, the primary button, the selected day. Every one of those pairs it with --m-on-brand, so what it has to satisfy is "white reads on this". A handful of rules instead use it as INK on a surface — a link, a project number, the current tab, the agenda block's left rail, the drag ghost's edge, the focus ring. What those have to satisfy is the opposite: "this reads on the surface behind it". On a light ground one colour can do both jobs and #993366 does. On a dark one nothing can — a fill that carries white text is by definition too dark to be ink on near-black. Splitting the token is what lets the dark theme answer the two separately; here it is the same colour, so this theme renders exactly as it did before the split. */ --m-brand-ink: var(--m-brand); /* = #f1e2ea. Chip fills and icon wells. --m-brand-deep on this is 7.42:1. Mixed toward --m-mix-base — the ground a tint is diluted INTO — so the same 14% reads as a tint in either theme instead of as a pale wash floating on a dark page. */ --m-brand-tint: color-mix(in srgb, var(--m-brand) 14%, var(--m-mix-base)); /* = #f7eff3. Large calm areas — sheet headers, the agenda's "now" band. --m-brand on it is 6.16:1 (the worst pair in this file, still AA), --m-brand-deep 8.20:1, --m-text 14.53:1. */ --m-brand-wash: color-mix(in srgb, var(--m-brand) 8%, var(--m-mix-base)); /* White on --m-brand is 6.95:1 — comfortably AA at any size. The brand is a dark fill in BOTH themes, so this stays white in both. */ --m-on-brand: #ffffff; /* The foreground for a saturated STATUS fill — the tick inside a completed task's checkbox (drawn on --m-success) and the confirm sheet's solid destructive button (on --m-danger). A separate token from --m-on-brand because the two diverge in the dark theme and did so silently: the status colours lighten there so they can be read as text, which turns the tick into white-on-pale-green at 1.76:1. --m-on-brand cannot follow them, because the brand fill it belongs to stays dark. Found by tools/contrast.py, which checks the tick pair in every theme. */ --m-on-fill: #ffffff; /* Pressed/hover wash for a control sitting ON the brand bar, where the usual surface tokens would be invisible. Reached only through --m-appbar-wash now, which is what lets the dark theme swap the whole wash for a brand tint without this value having to mean two things. */ --m-on-brand-wash: rgba(255, 255, 255, 0.16); /* ---- Project identity (Mobile App #71) ------------------------------- A hue per project, so a job can be recognised rather than read. Applied ONLY to .m-prjnum[data-prj]; app/text.py:project_hue() picks the step from the project number itself, so it is stable forever with no column, no admin screen and nothing to keep in sync. FIVE STEPS, AND ALL FIVE IN ONE ARC. Everything from 140° to 40° going the short way is already spoken for on this screen — brand magenta at 325°, planned teal at 175° (#68), success green at 145°, danger red at 3°, warn amber at 39°, the pinned-row yellow at 54°. The blue-violet run from 200° to 285° is the only stretch with no semantic neighbour, and it fits five hues that stay apart at 13px. Six were tried; at 16° spacing two of them read as the same colour on a phone. The cost is honest and worth stating: with five steps, two of the jobs on your screen will sometimes share a colour. That is a weaker cue than a unique one, not a wrong one — the number is right there beside it, and five is still five times the information carried by the single brand magenta every project number wore before. Deliberately NOT applied to agenda blocks. The rail on a block already means logged / planned / Outlook, and a second meaning on the same edge is the "one flag wearing two colours" mistake the --m-pin-bg note argues against. It is also why nothing here is duplicated into mobile-views.js: the hue is only ever server-rendered, so there is no second copy of the rule to drift. 5.10:1 to 7.66:1 on --m-bg, all AA at body size. */ --m-prj-1: #316e8d; --m-prj-2: #3d62ac; --m-prj-3: #423dac; --m-prj-4: #6b3dac; --m-prj-5: #913dac; /* ---- The two grounds every derivation reads (Mobile App #67) --------- Named so that one set of color-mix() expressions serves both themes. --m-mix-base is the ground a TINT or WASH is diluted into. It tracks --m-surface: a tint is a colour laid thinly over the card it sits on, so on a dark card it must dilute toward that card and not toward white. --m-weight-base is the direction MORE CONTRAST lies in — black on a light ground, white on a dark one. It is what the "-deep" values mix toward. Both are literal here rather than var(--m-surface), because --m-surface is #ffffff in this theme and the two ideas coincide; the dark block sets them apart from each other explicitly. */ --m-mix-base: #ffffff; --m-weight-base: #000000; /* ---- Surfaces -------------------------------------------------------- Three distinct roles, deliberately separate even where two happen to look similar: the page behind everything, the card/sheet surface that sits on it, and a subtly recessed fill used inside a card (input wells, zebra rows). Collapsing them would make a future dark palette fight itself. */ --m-bg: #f4f4f6; --m-surface: #ffffff; --m-surface-alt: #fafafb; --m-surface-sunken: #eeeef1; /* ---- Lines ----------------------------------------------------------- --m-border is a DECORATIVE separator (1.29:1). It must never be the only thing marking the boundary of an interactive control — WCAG requires 3:1 for that, which is what --m-control-border is for (3.41:1 on white, 3.10:1 on the page background). */ --m-border: #e2e2e8; --m-control-border: #8a8a97; /* The day-change hint tab (Plane #65 — James: "try #ccc"). A token because csscheck.py fails a hard-coded hex outside this block, and because #67 (dark mode) will need a counterpart for it like everything else here. 10.2:1 against --m-text, which is what the tab's label now uses: the old white text was for a near-black tab and would be 1.6:1 on this. */ --m-swipehint-bg: #ccc; /* ---- Text ------------------------------------------------------------ Measured on --m-surface / --m-bg respectively. */ --m-text: #1f1f24; /* 16.41:1 / 14.94:1 */ --m-text-muted: #5c5c68; /* 6.59:1 / 6.00:1 */ /* DECORATION ONLY from Mobile App #71 — never body copy, never a value somebody has to read. 5.26:1 / 4.79:1 clears AA, but AA is measured on an indoor screen and this app is used outdoors, at arm's length, through a screen protector: the figure is a floor here, not a target. The rules that used it for readable text now take --m-text-muted, eleven of them, including the agenda's hour labels - which are not decoration, they are the timeline's axis. WHAT IS LEFT IS GLYPHS AND RAILS, NEVER A WORD: the empty-state icon, the search field's magnifier, the layout grip, the hidden-widget eye, and the 3px rail down an Outlook meeting. If you find yourself putting this token on text again, the answer is --m-text-muted. tools/contrast.py holds it to the 3:1 large-text floor rather than 4.5, which is the check that keeps the distinction honest: raise it back to a body-text pair and the tool will start demanding a body-text ratio. */ --m-text-faint: #6b6b77; /* ---- Status ---------------------------------------------------------- Each foreground is AA on white AND on its own paired background, so a status pill reads correctly either way round. Colour is never the only signal — see the .m-badge rules, which always carry an icon or a word. */ --m-danger: #b3261e; /* 6.54:1 on white, 5.72:1 on --m-danger-bg */ --m-danger-bg: #fdecea; --m-success: #16733a; /* 5.92:1 on white, 5.21:1 on --m-success-bg */ --m-success-bg: #e6f4ea; --m-warn: #8a5a00; /* 5.93:1 on white, 5.36:1 on --m-warn-bg */ --m-warn-bg: #fdf3d9; /* ---- Pinned ---------------------------------------------------------- A row fill, not a status. The desktop paints a pinned ("starred") task row lemonchiffon (css/tasks.css:84) and the team reads it as a sticky note - Asif's own words on Mobile App #10. Deliberately the SAME hex rather than a mobile reinterpretation: one flag wearing two colours on two screens is a thing to learn twice. Not derived from --m-warn, though both are yellow. They are different ideas: --m-warn is a status the app asserts ("this needs attention"), --m-pin-bg is a mark the person put there themselves. Measured against every foreground a task row can actually carry: --m-text 15.48:1, --m-text-muted 6.22:1, --m-text-faint 4.96:1, --m-warn 5.59:1, --m-danger 6.17:1 - all still AA at body size. The unticked checkbox border (--m-control-border) is 3.21:1, over the 3:1 that a control boundary needs. */ --m-pin-bg: #fffacd; /* ---- Planned --------------------------------------------------------- Time SET ASIDE (Mobile App #46), and its own hue since #68 — James: "planned and outlook are too similar, make planned a different colour". They were both a dashed outline over the page, so at 1px on a phone the only thing telling them apart was the hue of a hairline. Three things on this timeline now each own a colour and each wear it as a solid left rail: brand = logged, plan = planned, --m-text-faint = an Outlook meeting. Teal is chosen for distance rather than taste. It is the far side of the wheel from --m-brand, so the two do not converge as thin lines, and it is saturated where the Outlook grey is not — which is the pair James actually reported. Green (--m-success) and amber (--m-warn/--m-pin-bg) were unavailable: both already assert something about a row. Derived from --m-plan the way the brand family is derived from --m-brand, so one value moves all three. 6.36:1 on --m-surface, 5.79:1 on --m-bg. */ --m-plan: #0f6b62; /* = #0c564e. The block's text, on --m-plan-tint: 6.93:1. 8.55:1 on --m-surface, which is what the PLANNED pill sits on. */ --m-plan-deep: color-mix(in srgb, var(--m-plan) 80%, black); /* = #ddeae9. The block fill. --m-text on it is 13.30:1, --m-plan-deep 6.93:1, and the --m-plan border on it 5.16:1. It is 1.23:1 against --m-surface — a fill this quiet is a grouping cue, never the only signal. The dashed border and the PLANNED pill still carry the meaning, which is what the note at .m-agenda__block--planned requires. */ --m-plan-tint: color-mix(in srgb, var(--m-plan) 14%, var(--m-mix-base)); /* ---- Space ----------------------------------------------------------- One scale. Every margin, padding and gap in this file comes from it. */ --m-s1: 0.25rem; /* 4px */ --m-s2: 0.5rem; /* 8px */ --m-s3: 0.75rem; /* 12px */ --m-s4: 1rem; /* 16px */ --m-s5: 1.5rem; /* 24px */ --m-s6: 2rem; /* 32px */ /* ---- Radius ---------------------------------------------------------- */ --m-r-sm: 6px; --m-r-md: 10px; --m-r-lg: 16px; --m-r-pill: 999px; /* ---- Type ------------------------------------------------------------ Sized in rem so the OS text-size setting is honoured. --m-fs-md is the body/control size: 1rem = 16px at default, which is also the threshold below which iOS Safari zooms the viewport on input focus. Do not set any input smaller than this. */ --m-font: 'Segoe UI', -apple-system, BlinkMacSystemFont, Roboto, 'Helvetica Neue', Arial, sans-serif; --m-font-num: ui-monospace, 'SF Mono', 'Cascadia Mono', Menlo, monospace; --m-fs-xs: 0.75rem; /* 14px, raised from 13px (Mobile App #71). Same reasoning as the note on --m-text-faint: this step carries nearly every meta row in the app, and 13px grey at arm's length in daylight is the pair of decisions that made those rows hard to read. Nothing here is width-constrained — the day strip's chips are sized from --m-fs-xs and --m-fs-md, not this. */ --m-fs-sm: 0.875rem; --m-fs-md: 1rem; --m-fs-lg: 1.125rem; --m-fs-xl: 1.375rem; --m-lh-tight: 1.25; --m-lh-normal: 1.5; /* ---- Elevation ------------------------------------------------------- */ --m-shadow-1: 0 1px 2px rgba(16, 16, 24, 0.06); --m-shadow-2: 0 2px 8px rgba(16, 16, 24, 0.10); --m-shadow-3: 0 -4px 24px rgba(16, 16, 24, 0.18); --m-backdrop: rgba(16, 16, 24, 0.45); /* ---- Controls -------------------------------------------------------- --m-tap is the minimum size of anything you can touch. It is a floor, applied via min-height/min-width, not a fixed size. */ --m-tap: 2.75rem; /* 44px */ --m-input-h: 2.875rem; /* 46px */ --m-field-gap: var(--m-s3); /* The ink token, not the fill one: a ring is drawn ON a surface and has to read against it. Same colour here, correct in the dark theme. */ --m-focus-ring: var(--m-brand-ink); --m-focus-width: 3px; /* ---- Chrome ---------------------------------------------------------- --m-safe-b keeps the tab bar clear of the iPhone home indicator. It resolves to 0px everywhere that has no notch, so it costs nothing. */ --m-appbar-h: 3.5rem; /* THE APP BAR'S OWN FIVE ROLES, so the dark theme can re-light the bar without a single component rule living inside a media query - the rule section 1a opens with, and the reason the bar could not be re-lit before these existed. IN THIS THEME THEY RESOLVE TO EXACTLY WHAT THE BAR ALREADY WAS: the brand as a fill, white on it, white's own 16% wash for hover and the "you are here" pill, and no bottom rule. The light bar is unchanged, in colour and in total height - James kept the maroon bar when the app bar rebalance was shown to him (Thread 49, UX_REVIEW.md §A), and that decision is untouched here. --m-appbar-edge is `transparent` rather than absent so the border BOX exists in both themes and the bar never changes height between them. Flow's own toolbar buttons keep a 1px border for the same reason, and css/home-beta.css's app-bar note records it as the thing adopted from them. box-sizing is border-box (section 2), so the 1px comes out of the content box and the bar's total height is the same number it was. */ --m-appbar-bg: var(--m-brand); --m-appbar-fg: var(--m-on-brand); --m-appbar-wash: var(--m-on-brand-wash); /* The ink for a hovered or current action. On the brand bar the only thing that reads is the white the icon is already drawn in, which is what the .is-current note below says; in the dark theme the bar stops being the brand, so the brand becomes available as an accent and this splits away from --m-appbar-fg. */ --m-appbar-current-fg: var(--m-on-brand); --m-appbar-edge: transparent; --m-tabbar-h: 3.75rem; --m-safe-t: env(safe-area-inset-top, 0px); --m-safe-b: env(safe-area-inset-bottom, 0px); --m-safe-l: env(safe-area-inset-left, 0px); --m-safe-r: env(safe-area-inset-right, 0px); /* Height of the on-screen keyboard, published by scripts/mobile.js from the VisualViewport API. 0px here is the correct resting value and the correct fallback where that API is missing, so nothing depends on the JS having run. See the sheet rules in section 21 (Mobile #6). */ --m-kb: 0px; /* The visible height, published by scripts/mobile.js from the VisualViewport API (Plane #63). DECLARED AS 100dvh, which is both the correct resting value and the correct behaviour before that JS has run or on a browser without the API - so the shell is never sized by a token that does not exist, and nothing depends on the script having run. It exists because dvh is a CSS guess at the viewport and the standalone PWA is where that guess is wrong: measured on James's phone, body resolved to 812 against an innerHeight of 775, on an 874 screen. */ --m-vvh: 100dvh; --m-content-max: 40rem; /* ---- Motion ---------------------------------------------------------- */ --m-dur-fast: 120ms; --m-dur: 200ms; --m-ease: cubic-bezier(0.2, 0, 0.2, 1); /* ---- Agenda (Phase 3 — declared here so the scale is decided once) ---- The agenda day is 96 rows of 15 minutes. --m-slot-h is one of those rows; the hour band is therefore 4x this. Kept as tokens because both the grid and the block-positioning maths read them. */ --m-slot-h: 1.125rem; /* 18px per 15 min -> 72px per hour */ /* How many of those rows the timeline draws. 44 is 07:00 to 18:00, the working day the agenda opens on (James, 2026-08-29: "hide any hours before 7 AM and after 6 PM... screen real estate is important"). renderAgenda() overwrites this on the grid element every time it draws, widening it when the day holds anything outside those hours. The value here is what the box is sized at BEFORE that runs: at 96 an empty grid would be 1728px of nothing on first paint, and the page would visibly collapse when the day arrived. Kept in step with WORKDAY_FIRST_SLOT and WORKDAY_LAST_SLOT in mobile-views.js, which are the real definition. */ --m-agenda-slots: 44; --m-agenda-gutter: 3.25rem; } /* ========================================================================== 1a. THE DARK THEME (Mobile App #67) -------------------------------------------------------------------------- ONLY TOKENS ARE REDEFINED HERE. No component rule appears in this block and none should: a colour whose only definition sits inside a media query is a colour that does not exist in the other theme, and the whole point of the token architecture in section 1 was to make this block possible without touching a single component. Following the SYSTEM setting and nothing else, which is what #67 asks for. There is no in-app light/dark switch: adding one means either a second hand-maintained copy of every token below (selected by a `data-theme` attribute) or a preprocessor, and a second copy of a palette is exactly the failure this file's header records — "26 hand-typed rgba tints came loose from the one variable that was supposed to control them". If a switch is wanted later, the thing to add is the attribute selector AND a check that the two blocks define the same token set, not the attribute alone. Every ratio in the comments below is measured by tools/contrast.py against THIS block, in the same run that measures the light one. Change a value here and re-run it; the pairs are declared once and checked in both themes. ALIGNED TO FLOW DARK, 2026-08-30. Flow opened its dark theme to every user the same week (Plane #319/#323), after a measured accessibility pass of its own, and the two apps are used by the same people on the same phone - so the neutral ramp, the text greys, the accent and the three status pairs are now Flow's values rather than a second opinion about the same problem. Read /var/www/flow/app/static/theme-dark.css beside this block: each token below that took a Flow value names the Flow token it came from. Three things did NOT follow Flow, each for a reason recorded at the token: --m-control-border (Flow's is under 3:1 on this app's pinned row), --m-surface-sunken (Flow puts input wells above the card, this app cuts them into it) and --m-pin-bg (Flow has no pinned row). The mobile-only families - the plan colours and the five project hues - had nothing in Flow to align to and were re-measured rather than re-picked. This is an alignment, not a shared stylesheet. Mobile #33 is explicit that the apps share the database and nothing else, and Flow is a different tree on a different host; a copied value that drifts is the cost, and it is the same cost the --m-pin-bg note already accepts against the desktop. What is NOT inverted, deliberately: - The app bar and the FAB keep the brand as a fill. A dark theme would normally quieten saturated chrome, and the UX review's finding A argues it should be quietened in BOTH themes - but that is a change to the most recognisable thing in the app and it needs a phone and a prototype, not a media query. Doing it here only would also mean the two themes disagreed about what the app looks like, which is a worse answer than either theme alone. - --m-on-brand stays white. It is the foreground for every SATURATED FILL, not just the brand one: the completed task tick draws it on --m-success and the confirm sheet's destructive button on --m-danger. Flipping it dark would have broken both. ========================================================================== */ @media (prefers-color-scheme: dark) { :root { /* Flow's dark theme declares this, and it is the half of a dark theme CSS cannot paint: the UA canvas, the scrollbars, and every NATIVE control - the date and time pickers the sheets use, the selects, the spinners. Without it those render light-on-light inside an otherwise dark app. Safe under prefers-color-scheme because it only ever agrees with the media query that encloses it. */ color-scheme: dark; /* ---- The two grounds. These carry the whole block: every tint, wash and "-deep" in section 1 is a color-mix() onto one of them, so redefining the pair re-derives the brand and plan families at once. */ --m-mix-base: #1e1f24; /* tracks --m-surface, as in the light theme */ --m-weight-base: #ffffff; /* "more weight" is now TOWARD white */ /* ---- Brand. --m-brand stays a FILL and keeps white on it: 5.33:1, still AA. It is lifted off #993366 because the same maroon that reads as brand on white reads as a smudge on near-black - this is the one colour that has to be chosen for the ground rather than derived from it. Unchanged by the Flow alignment: Flow has no brand-filled chrome to match it against, and the note above rules out quietening the app bar here alone. --m-brand-ink is the other half of the split made in section 1: the link, the project number, the current tab, the agenda rail and the focus ring, all of which are drawn ON a surface. It is now Flow Dark's own accent (theme-dark.css's --secondary-color), so an accent glyph is the same colour in both apps. 5.52:1 on --m-surface, 6.17:1 on --m-bg, 5.19:1 on --m-brand-wash, 4.92:1 on --m-brand-tint - lower than the #ef9ac9 it replaces, and above every floor the pairs demand. --m-brand-deep is Flow's second accent step (--button-hover-bg), which is the same relationship to the accent that this token has to the ink: one notch further from the ground. Still typed rather than derived - 80% of --m-brand mixed toward white lands at #d190b3, on the wrong side of --m-brand-ink. 6.52:1 on --m-surface, 5.82:1 on --m-brand-tint, 6.13:1 on --m-brand-wash. */ --m-brand: #b3407c; --m-brand-ink: #cc7ab8; --m-brand-deep: #d989c4; /* Near-black, because every status FILL lightens in this theme. See the note beside the token in section 1. Flow's --button-text, which does the same job on its own lightened accent. */ --m-on-fill: #1a1b20; /* ---- Surfaces. The page is the darkest thing, cards sit above it, a sunken well sits below the card it is cut into. The same three roles as the light theme, in the same order, so no component learns a new one. THE RAMP IS FLOW DARK'S, taken value for value: --m-bg is its --page-background, --m-surface its --surface/--background, and --m-surface-alt its --row-alt-bg. The greys are neutral with a slight blue lift - each step is roughly (r, r+1, r+6) - which is what makes the two apps read as one product on the same phone. --m-surface-sunken is the one step Flow has no counterpart for, and the one place the two models genuinely disagree: Flow puts its input wells ABOVE the card (--input-bg is --row-alt-bg), this app cuts them into it. The role is not changed to match - a well that is lighter than its card is a different component, not a different colour - so the value is Flow's ramp continued one step DOWN past --page-background instead. */ --m-bg: #131418; --m-surface: #1e1f24; --m-surface-alt: #26272d; --m-surface-sunken: #0e0f13; /* ---- Lines. Flow's 2026-08-30 accessibility pass found its own dark borders at 1.48:1 and called them illegible; --m-border was 1.42:1 here for the same reason. Taking Flow's --border-color puts it at 2.05:1 - raised until page structure is visible and NOT to 3:1, because 1.4.11 governs the boundary of a CONTROL and this token is a divider. Every control boundary in the app is --m-control-border, which is the whole point of them being two tokens. --m-control-border does NOT take Flow's --input-border (#73757f). That value clears 3:1 on Flow's own surfaces, but this app has a surface Flow does not: a pinned row, where #73757f lands at 2.81:1 and an unticked checkbox loses its edge. tools/contrast.py checks that pair, which is how the difference was found rather than shipped. Kept at Flow's grey family, at the strength this app's grounds need: 4.98:1 on --m-surface, 5.57:1 on --m-bg, 3.90:1 on --m-pin-bg. */ --m-border: #4e505a; --m-control-border: #8b8d97; /* Was #ccc, which on this ground is a white slab. The tab is a shape, not text, but --m-text sits on it: 6.42:1. Same value as --m-border by coincidence of Flow's ramp, not by derivation - it is a slab, not a rule, and the two are free to move apart. */ --m-swipehint-bg: #4e505a; /* ---- Text. Flow's --text-color and --light-text. Not pure white - #ffffff on a near-black ground haloes badly on OLED, which is most of the phones this runs on, and Flow stops at #e6e6e6 for its own reasons. 13.18:1 and 6.52:1 on --m-surface. --m-text-faint stays DECORATION ONLY (see the note in section 1) and is held to the 3:1 large-text floor: Flow's --scrollbar-thumb-hover, the nearest thing it has to a glyph grey, at 4.48:1 on --m-surface. */ --m-text: #e6e6e6; --m-text-muted: #a3a3a3; --m-text-faint: #83858f; /* ---- Status. Flow Dark's three status pairs, taken whole: its --danger-fg/-bg, --success-fg/-bg and --warning-fg/-bg. Like this app's own, they are not the light originals darkened - each is re-picked for a dark ground, foregrounds brightened and fills dark-tinted rather than pale - so the two palettes were already built to the same rule and adopting Flow's costs nothing but agreement. Checked both ways round by tools/contrast.py, as before: 5.93/5.38 for danger on --m-surface and on its own fill, 6.00/4.92 for success, 8.40/6.61 for warn. Success on its own fill is the tightest at 4.92:1, which is where Flow's pass left it too. */ --m-danger: #ff6b6b; --m-danger-bg: #3a2020; --m-success: #4caf6d; --m-success-bg: #1f3324; --m-warn: #e0b34d; --m-warn-bg: #3a3020; /* The sticky-note yellow. This is the ONE token that deliberately breaks the light theme's rule about matching the desktop hex: css/tasks.css paints a pinned row lemonchiffon and mobile matched it exactly so the flag would not have to be learned twice. That argument is about the DESKTOP's screen, which has no dark theme - and #fffacd here would be a floodlit row on a near-black list. Same idea, same corner of the wheel, chosen for this ground. --m-text on it is 10.31:1. Left where it was by the Flow alignment. Flow has no pinned row, and every value near enough to separate it from the new --m-warn-bg by luminance takes --m-danger on a pinned row under 4.5:1. The two are within 1.01:1 of each other, which is the case .m-badge's currentColor hairline already exists for - see the note there; it was written for the light theme, where the same pair is 1.04:1. */ --m-pin-bg: #38320f; /* ---- Planned (#68). Same split as the brand: --m-plan is the rail and the dashed edge, --m-plan-deep the text. --m-plan-tint is derived from --m-mix-base above and needs no value here. Mobile-only - the agenda has no counterpart in Flow - so the alignment leaves both alone; they were re-measured against the new grounds, at 6.56:1 and 11.07:1 on --m-surface. */ --m-plan: #3fb5a6; --m-plan-deep: #8fe3d6; /* ---- Project identity. The same five hues, lifted to sit on this ground: 6.76:1 to 6.82:1 on --m-surface, deliberately level with each other so no job looks more important than another. Mobile-only, like the plan family, and unchanged - only re-measured, the surface having moved a step lighter. */ --m-prj-1: #71aecd; --m-prj-2: #8fa7d7; --m-prj-3: #a3a0dd; --m-prj-4: #b69bdc; --m-prj-5: #c894d9; /* ---- The app bar, DARK ONLY (James, 2026-08-30: "only adjust the header top bar for dark mode. Check esheets beta dark mode"). ------------------------------------------------------------------ THE REFERENCE IS css/home-beta.css's .hb-appbar, which James had already approved and pointed at. That bar is `background: var(--panel)` - the SURFACE, not the brand - with `border-bottom: 1px solid var(--grid-2)`, its nav items transparent and tinting to the brand on hover, and its current item a brand wash carrying brand ink. Every one of those five roles is reproduced here, token for token: home-beta here resolves to --panel --m-appbar-bg #1e1f24 --ink --m-appbar-fg #e6e6e6 --brand-hover --m-appbar-wash --m-brand-tint (#332430) --brand --m-appbar-current-fg --m-brand-ink (#cc7ab8) --grid-2 --m-appbar-edge --m-border (#4e505a) Flow's own --toolbar-bg is #1a1b20, a step DARKER than its surface. The beta's choice is followed instead of Flow's, because the beta is the reference James named and it is the eSheets-family answer; the bar reads as a raised surface over --m-bg either way. WHY THIS IS NOT THE REBALANCE THAT WAS REVERTED. That one took the maroon off the bar in the LIGHT theme, on a salience argument, and James declined it - see the tokens in section 1, which are untouched. This is the narrower case the note at the top of this block had already reserved judgement on: at #b3407c the bar is the single brightest thing on a #131418 page, which is the specific effect a dark theme exists to avoid, and the app is used in the dark by people who chose the setting. The two themes now disagree about the bar, which that note called a worse answer than either theme alone - it is overruled, and this is why: the disagreement it feared was mobile-light against mobile-dark, and the family has since settled. Flow's toolbar and the eSheets beta's app bar are BOTH neutral in both of their themes. Mobile-light's maroon bar is the outlier now, kept deliberately because James chose it; matching the family in the one theme where it also fixes a real glare problem is not the same bet the reverted change made. Three things this does NOT do, all of them out of the stated scope: the FAB, the tab bar's current-tab brand and the primary button keep the brand as a fill, and the light bar is not touched. --m-appbar-current-fg carries the Admin "you are here" pill and a hovered action. On --m-appbar-wash it is 4.92:1 and on the bar itself 5.52:1 - the same two numbers as the brand-ink pairs, because it is the same colour doing the same job on the same two grounds. */ --m-appbar-bg: var(--m-surface); --m-appbar-fg: var(--m-text); --m-appbar-wash: var(--m-brand-tint); --m-appbar-current-fg: var(--m-brand-ink); --m-appbar-edge: var(--m-border); /* ---- Elevation. A shadow cannot darken a near-black page, so the values deepen and the backdrop goes nearly opaque; separation in this theme is carried by --m-surface being lighter than --m-bg, which is why those two are further apart here than their light counterparts. Already the same weight as Flow Dark's single --shadow (black at 0.5), so the alignment had nothing to change. */ --m-shadow-1: 0 1px 2px rgba(0, 0, 0, 0.40); --m-shadow-2: 0 2px 8px rgba(0, 0, 0, 0.50); --m-shadow-3: 0 -4px 24px rgba(0, 0, 0, 0.60); --m-backdrop: rgba(0, 0, 0, 0.66); } } /* ========================================================================== 1b. THE [hidden] RESET -------------------------------------------------------------------------- The HTML `hidden` attribute only hides an element because the UA stylesheet says `display: none` - which ANY author `display` immediately outranks. So `element.hidden = true` silently does nothing to a component that sets its own display, and this file is full of those. That had already bitten five times and been patched five times, once per component (.m-toast, .m-panel, .m-task, .m-progress, #m-bug-status). Two were missed, and both were live bugs: - .m-btn is display:inline-flex, so `$('m-task-delete').hidden = !isEdit` did nothing and a DELETE button sat on the New task sheet. - .m-field__hint is display:block, so the "One per line creates several tasks" hint stayed on screen while EDITING an existing task, where it is not true. One rule instead of a sixth patch. !important is deliberate and is the same thing every CSS reset does here: `hidden` is an author's explicit statement that an element is not to be shown, and no component rule should be able to overrule it by accident. Nothing in this app sets an inline display, so there is nothing legitimate for it to fight. The five per-component rules below are now redundant. They are left in place, doing no harm, rather than making this change bigger than it is. ========================================================================== */ [hidden] { display: none !important; } /* ========================================================================== 2. RESET / BASE ========================================================================== */ *, *::before, *::after { box-sizing: border-box; } html { /* Prevent iOS bumping text up in landscape, which breaks the agenda grid. */ -webkit-text-size-adjust: 100%; text-size-adjust: 100%; /* THE CANVAS. Not a workaround - the only mechanism there is. --------------------------------------------------------------------- Whatever sits between the bottom of the layout viewport and the bottom of the screen is painted by the CANVAS. No element can reach it: that is what made .m-tabbar::after pointless, and it is why the shell below - which correctly ends the bar at the bottom of the LAYOUT viewport - does not by itself make that strip disappear. With no background on , the BODY's propagates to the canvas, so the strip was --m-bg: grey, and visibly not the bar. Setting one here stops that propagation and makes this the canvas colour. --m-surface, because the thing the strip meets is the tab bar. */ background: var(--m-surface); } body { margin: 0; font-family: var(--m-font); font-size: var(--m-fs-md); line-height: var(--m-lh-normal); color: var(--m-text); background: var(--m-bg); /* Kept for the two pages that are NOT the app shell - the sign-in page and the deposit slip - which still scroll as ordinary documents. */ overscroll-behavior-y: none; } /* THE APP SHELL (Plane #63, settled 2026-08-30). ------------------------------------------------------------------------- James: "the taskbar element should be anchored to the bottom of the screen... always... without exception." Three attempts before this one tried to make a `position: fixed` tab bar reach the bottom of the SCREEN. It cannot, and that is not a bug to work around: `fixed` is defined against the LAYOUT viewport, and on iOS that is not the screen whenever browser chrome is showing - this issue's own figures say Viewport 812, Screen 874. Colouring the leftover 62 px to match the bar hid it; it did not anchor anything. So the document stops scrolling and the shell does the work: exactly one dynamic viewport tall, laid out as a column of app bar / main / tab bar. The tab bar is the last child of a box exactly as tall as the visible area, so it ends where the visible area ends - by construction, with nothing positioned and nothing that can drift. `dvh`, not `vh`: vh is the LARGEST viewport on iOS and would overshoot by the height of the chrome, putting the bar back off the bottom. vh first as the fallback for anything that does not know dvh. SCOPED TO [data-view], which only the app shell carries. m-login.html and the deposit slip share this stylesheet and are ordinary scrolling documents; giving them `height: 100dvh; overflow: hidden` would clip the sign-in form the moment the keyboard shrank the viewport, which is precisely when it must still scroll. The scroll moves to .m-main. Checked before doing it: the client has no document-scroll dependencies - only scrollIntoView, which works in any scroll container, and one horizontal strip.scrollTo. */ body[data-view] { display: flex; flex-direction: column; /* Three steps, weakest first, so every browser lands on the best value it has: vh for anything ancient, dvh where it is understood, and --m-vvh once the VisualViewport API has answered. The last is the only one that is measured rather than inferred. */ height: 100vh; height: 100dvh; height: var(--m-vvh); overflow: hidden; } h1, h2, h3, p, ul, ol, figure { margin: 0; } ul, ol { padding: 0; list-style: none; } img { max-width: 100%; height: auto; display: block; } a { color: var(--m-brand); text-decoration-thickness: 1px; text-underline-offset: 2px; } button { font: inherit; color: inherit; } input, select, textarea { font: inherit; /* Never below 1rem — iOS Safari zooms the viewport on focus otherwise, and there is no way back out of that zoom without a pinch. */ font-size: var(--m-fs-md); color: var(--m-text); } /* Focus. One rule, applied to everything, never removed anywhere below. :focus-visible so a touch tap does not leave a ring behind, while keyboard and switch-control users always get one. */ :focus-visible { outline: var(--m-focus-width) solid var(--m-focus-ring); outline-offset: 2px; border-radius: var(--m-r-sm); } /* Visible only to assistive technology. Used for the text of icon-only controls where an aria-label would lose the punctuation/context. */ .m-sr-only { position: absolute; width: 1px; height: 1px; padding: 0; margin: -1px; overflow: hidden; clip: rect(0, 0, 0, 0); white-space: nowrap; border: 0; } /* Skip link — hidden until focused, then pinned to the top-left. */ .m-skip { position: absolute; left: var(--m-s2); top: -10rem; z-index: 100; padding: var(--m-s2) var(--m-s3); background: var(--m-surface); color: var(--m-brand); border-radius: var(--m-r-sm); box-shadow: var(--m-shadow-2); } .m-skip:focus { top: calc(var(--m-safe-t) + var(--m-s2)); } /* ========================================================================== 3. LAYOUT — app bar, main, tab bar ========================================================================== */ .m-appbar { /* In flow at the top of the shell, not fixed over it. `relative` only so z-index still applies - it must paint above .m-main's scrolling content, which is what a fixed bar used to get for free. */ position: relative; flex: 0 0 auto; z-index: 30; display: flex; align-items: center; gap: var(--m-s2); height: calc(var(--m-appbar-h) + var(--m-safe-t)); padding: var(--m-safe-t) calc(var(--m-s4) + var(--m-safe-r)) 0 calc(var(--m-s4) + var(--m-safe-l)); background: var(--m-appbar-bg); color: var(--m-appbar-fg); /* Transparent in this theme, --m-border in the dark one. Declared in both so the border box exists either way and the bar's height never moves between themes - see the token note in section 1. */ border-bottom: 1px solid var(--m-appbar-edge); } .m-appbar__title { font-size: var(--m-fs-lg); font-weight: 600; line-height: var(--m-lh-tight); letter-spacing: 0.01em; margin-right: auto; min-width: 0; overflow: hidden; text-overflow: ellipsis; white-space: nowrap; } .m-appbar__sub { display: block; font-size: var(--m-fs-xs); font-weight: 400; opacity: 0.85; } /* Icon button sitting on the brand bar. */ .m-appbar__action { display: inline-flex; align-items: center; justify-content: center; min-width: var(--m-tap); min-height: var(--m-tap); padding: 0 var(--m-s2); background: transparent; border: 1px solid transparent; border-radius: var(--m-r-pill); color: var(--m-appbar-fg); cursor: pointer; } .m-appbar__action:hover, .m-appbar__action:active { background: var(--m-appbar-wash); /* Same colour it already was on the brand bar, the brand accent on the dark one - home-beta's .hb-nav a:hover does exactly this. */ color: var(--m-appbar-current-fg); } .m-appbar__action:focus-visible { /* The bar's own foreground, so the ring is white on the maroon bar and near-white on the dark one. Not --m-focus-ring: the brand ink it resolves to is the thing the ring would have to read against up here. */ outline-color: var(--m-appbar-fg); } /* The Admin control's "you are here" state (Mobile App #29). The tab bar signals current with a brand-coloured inset rule, which cannot work up here - the bar IS the brand colour, so a brand-on-brand marker is invisible. On this background the only thing that reads is the white the icon is already drawn in, so it is a filled pill: a solid wash plus a visible ring, which is distinguishable from :hover's wash alone. THE DARK THEME IS THE CASE THAT PARAGRAPH RULES OUT. There the bar is a surface, not the brand, so the brand IS available as a marker and the pill becomes what home-beta's .hb-nav a.is-current already is: a brand wash carrying brand ink. Both come from --m-appbar-* tokens, so the rule is one rule and the light bar keeps the white-on-wash pill described above. */ .m-appbar__action.is-current { background: var(--m-appbar-wash); border-color: var(--m-appbar-current-fg); color: var(--m-appbar-current-fg); } /* forced-colours mode throws away both the wash and the border colour above, so the only surviving signal would be nothing at all. */ @media (forced-colors: active) { .m-appbar__action.is-current { border-color: Highlight; border-width: 2px; } } .m-main { /* THE SCROLLER. The document does not scroll any more - see the shell note on body - so this is the box that does. The padding no longer clears the two bars: they are siblings in the column and take their own space, including their own safe-area insets. What is left is the page's own gutter. The bottom keeps a little more than the top so the last card does not sit hard against the tab bar. */ flex: 1 1 auto; overflow-y: auto; /* Contain, not none: a scroll that reaches the end of THIS box must not chain to the document behind it and rubber-band the whole shell. */ overscroll-behavior-y: contain; -webkit-overflow-scrolling: touch; padding: var(--m-s4) calc(var(--m-s4) + var(--m-safe-r)) var(--m-s5) calc(var(--m-s4) + var(--m-safe-l)); max-width: var(--m-content-max); margin: 0 auto; width: 100%; } /* ---- Tab bar ------------------------------------------------------------ Four destinations plus a central create button. Anything more than four destinations stops being scannable at a glance on a phone, which is why filing a note and writing a status update live on the create button instead of taking tabs of their own — they are things you DO, not places you go. */ .m-tabbar { /* The last child of a shell that is exactly one viewport tall, so it ends where the viewport ends. Nothing is positioned and there is nothing to drift - which is the whole point of Plane #63. */ position: relative; flex: 0 0 auto; z-index: 30; display: grid; /* Auto columns rather than a hard-coded count. This bar carries five items and the "+" must sit dead centre, which is the whole reason Admin is NOT in here (Mobile App #29 - it was, and a sixth item moved the "+" to 41.7% and squeezed "Expenses" to a width that clips on a 360px screen). Admin lives in the app bar instead. The count is left to the markup anyway: it was `repeat(5, 1fr)` when m.php briefly emitted six children, and the sixth wrapped to an implicit second row that the fixed height below pushed off the bottom of the screen - so the tab was invisible rather than merely cramped. Auto-flow cannot fall out of step with the markup the way a literal count did. */ grid-auto-flow: column; grid-auto-columns: 1fr; align-items: stretch; height: calc(var(--m-tabbar-h) + var(--m-safe-b)); padding-bottom: var(--m-safe-b); background: var(--m-surface); border-top: 1px solid var(--m-border); } .m-tab { display: flex; flex-direction: column; align-items: center; justify-content: center; gap: 2px; min-height: var(--m-tap); padding: var(--m-s1) var(--m-s1); color: var(--m-text-muted); font-size: var(--m-fs-xs); line-height: 1; text-decoration: none; border: 0; background: none; } .m-tab__icon { display: inline-flex; line-height: 0; } /* Icons are inline SVG sized in em, so they scale with the text around them rather than needing a size per call site. currentColor means they inherit whatever the parent control's colour already is, including in forced-colours mode. */ .m-icon { width: 1.25em; height: 1.25em; flex: 0 0 auto; } .m-tab__glyph { width: 1.375rem; height: 1.375rem; flex: 0 0 auto; } .m-badge__glyph { width: 0.875em; height: 0.875em; flex: 0 0 auto; } .m-empty__glyph { width: 2rem; height: 2rem; } /* The active tab is marked three ways on purpose — colour, weight, and the bar above it — so it does not depend on colour perception alone. The markup also carries aria-current="page". */ .m-tab[aria-current='page'] { color: var(--m-brand); font-weight: 600; box-shadow: inset 0 3px 0 0 var(--m-brand); } /* Central create button. Sits in the grid like the others so nothing overlaps and the hit areas stay even. */ .m-tab--create { justify-content: center; } .m-fab { display: inline-flex; align-items: center; justify-content: center; width: var(--m-tap); height: var(--m-tap); border: 0; border-radius: var(--m-r-pill); background: var(--m-brand); color: var(--m-on-brand); line-height: 0; box-shadow: var(--m-shadow-2); cursor: pointer; } .m-fab:active { background: var(--m-brand-deep); } /* ========================================================================== 4. SECTIONS, CARDS, LISTS ========================================================================== */ .m-section + .m-section { margin-top: var(--m-s5); } .m-section__head { display: flex; align-items: baseline; gap: var(--m-s2); margin-bottom: var(--m-s2); padding: 0 var(--m-s1); } .m-section__title { font-size: var(--m-fs-sm); font-weight: 700; letter-spacing: 0.06em; text-transform: uppercase; color: var(--m-text-muted); } .m-section__link { margin-left: auto; font-size: var(--m-fs-sm); } .m-card { background: var(--m-surface); border: 1px solid var(--m-border); border-radius: var(--m-r-lg); box-shadow: var(--m-shadow-1); overflow: hidden; } .m-card__body { padding: var(--m-s4); } /* A stack of rows inside one card, hairline-separated. */ .m-list > * + * { border-top: 1px solid var(--m-border); } /* One row. Rendered as a