/* ============================================================================ travelmean-standalone.css — the colour seam for the NINE SELF-CONTAINED PAGES. WHAT THIS FILE IS, AND WHY IT IS NOT travelmean-tokens.css ---------------------------------------------------------- Nine pages render with `Layout = null` and link only the theme's app.min.css: the eight Account pages (activation, forgotten password, password reset and their outcome screens) and Shared/_ConsumerLayout. A308 says they must carry the brand — "marka rengi değiştiğinde giriş ekranı da değişir" — while A231's surviving half says they must not become dependent on the admin chrome. 🔴 THE OBVIOUS MOVE — LINKING travelmean-tokens.css HERE — WAS MEASURED AND REJECTED, AND THE MEASUREMENT IS THE ANSWER TO A308'S FONT QUESTION. That file carries ten @font-face declarations (Plex Serif, Sans and Mono) and maps `--bs-font-sans-serif` / `--bs-font-monospace` / `--bs-body-font-size` / `--bs-body-line-height` onto them from `:root`. Two of the three faces would cost NOTHING here: a browser fetches a @font-face src only when a matching family is actually used, and these nine pages contain no

-

, .page-title, .card-title, .modal-title, .offcanvas-title, .card-header, , , .text-end, .font-monospace or number/date input — measured, not assumed — so no rule that applies the display or data face matches anything. Plex Serif and Plex Mono would never download and never appear. The BODY face is the one that does reach them, through that `:root` mapping, and it would change the typeface and the body size of a login screen. That is typography, not colour, and A308 asked for the two to be separated where they can be. Here they can be, exactly: this file carries the colours those pages need and NOTHING else — no @font-face, no font-family, no font-size, no line-height. The nine pages keep the type they have today, to the pixel, and still follow the assigned palette. HOW IT IS USED -------------- Each of the nine links this file and travelmean-theme-presets.css, in that order, after app.min.css, and stamps `data-admin-theme` on its own . With no assignment the attribute is "default", no preset block matches, and every value below is the literal that page shipped with — so an unassigned installation renders these pages byte-for-byte as before. 🔴 THE VALUES BELOW ARE NOT THE PANEL'S PALETTE AND MUST NOT BE WIRED TO IT. These pages were built with their own small palette (#1f4cbf, #10b981, #ef4444) which is NOT the admin theme's (#5369f8, #43d39e, #ff5c75). Deriving one from the other would repaint a login screen on a build that assigned nothing, which is the one thing this wave may not do. They converge only when a preset is assigned, and each preset states both sides explicitly. ============================================================================ */ :root { /* --- surfaces ---------------------------------------------------------- */ /* The page canvas. All nine: `body { background: #f6f8fb }`. */ --sa-page: #f6f8fb; /* The card. Eight Account pages `.card-box`, _ConsumerLayout `.tm-card`. */ --sa-surface: #fff; /* The card's drop shadow, as a CHANNEL rather than a colour, because the two families use different alphas over the same black: the Account cards are `0 2px 12px rgba(0,0,0,0.05)` and the consumer card is `0 1px 4px rgba(0,0,0,.06)`. One token with one alpha would have had to round one of them; the channel keeps both exact. */ --sa-shadow-rgb: 0, 0, 0; /* --- ink --------------------------------------------------------------- */ /* The wordmark, and the only brand-coloured thing on these pages. Account `.logo`, _ConsumerLayout `.tm-brand`. */ --sa-brand: #1f4cbf; /* Body text. Declared by _ConsumerLayout only; the Account pages inherit the theme's own body colour and do not set one. */ --sa-ink: #1f2937; /* The quieter line under a heading. Account `.muted`, consumer `.tm-note`. */ --sa-muted: #6b7280; /* --- outcome icons ------------------------------------------------------ */ /* The large glyph on the four "this went wrong" screens (ActivationExpired, ResetPasswordExpired) and on the three "this worked" ones (ActivationSuccess, ForgotPasswordSent, ResetPasswordSuccess). */ --sa-danger: #ef4444; --sa-success: #10b981; /* The border of _ConsumerLayout's `.tm-danger-zone` — a rule, not a fill, and a different value from --sa-danger on purpose. */ --sa-danger-rule: #f3c8c8; /* --- the primary button (added 2026-08-08) ------------------------------- */ /* 🔴 WHY THESE EXIST: WITHOUT THEM AN ASSIGNED PALETTE HALF-LANDS. --sa-brand repaints the wordmark, but `.btn-primary` does NOT read it — or any token in this file. Bootstrap 5.3 paints a filled button from literals declared ON THE VARIANT CLASS (--bs-btn-bg and friends, specificity 0,1,0), so nothing at :root can reach it, and travelmean-tokens.css — which does remap them for the admin panel — is deliberately not linked here. Measured on the rendered login page, deep-sea assigned: the wordmark came up #0d6b83 and the Sign-in button stayed #5369f8. One card, two blues, neither of them wrong on its own. docs/design/README.md already warned that solid buttons were "not free"; this closes it for these pages only. 🔴 THE DEFAULTS BELOW ARE THE INHERITED THEME'S OWN VALUES, READ OFF THE LIVE PAGE — not chosen. An unassigned installation therefore renders these buttons exactly as before, which is the promise the whole file is built on. The derived tones keep the inherited RELATIONSHIP rather than inventing one: #5369f8 → #4759d3 is 85% toward black, → #4254c6 is 80%, and the two border tones are 80% and 75%. Each preset states only its base colour and lets color-mix reproduce those four ratios. */ --sa-btn: #5369f8; --sa-btn-hover: #4759d3; --sa-btn-active: #4254c6; --sa-btn-rule: #5369f8; --sa-btn-rule-hover: #4254c6; --sa-btn-rule-active: #3e4fba; --sa-on-btn: #ffffff; /* W-FARK-ADMIN-DIGER -- the ADMIN sign-in page only (Views/Membership/Index): the design (_giris-tasarim.html) draws its wordmark and Sign in button in the admin navy, with the design's blue under the pointer (A1047 "Lacivert, tasarimdaki gibi" + A1049 hover). Read by that view's own rules; the Account pages keep --sa-brand / --sa-btn. */ --sa-admin-navy: #10203d; --sa-admin-navy-hover: #1e5ff0; /* --- control rule + text link (added 2026-08-14, contrast audit) --------- 🔴 THESE ARE THE TWO PROPERTIES THE THEME LEFT UNDER THRESHOLD ON THE CONSUMER LOGIN GATE, and neither was tokenised before — both came straight from app.min.css, which is why an assigned palette never touched them and a contrast pass never reached them either. Measured on /account/login, deep-sea assigned: * .form-control / .form-check-input border was app.min.css's #e8ebf2 = 1.19:1 on white, well under the 3.0 WCAG non-text-contrast floor a form control's edge must clear. --sa-control-rule #87888c = 3.54:1 on white (--sa-surface, white in every preset) and 3.23:1 on --sa-page. * a plain text link was #5369f8 = 4.43:1, one notch under 4.5. --sa-link #5166f1 = 4.65:1 on white. The surface these controls sit on is white in the default AND in all three presets (--sa-surface is #ffffff everywhere), so a single neutral rule value clears the floor under every assignment — these do not need to be restated per preset the way --sa-btn does, because unlike the button they do not change with the brand. This is the same split A495 made in the panel (--tm-rule / --tm-faint): a rule that must carry contrast gets its own named token, kept apart from the decorative borders. */ --sa-control-rule: #87888c; --sa-link: #5166f1; /* --- the three tokens the DARK scheme needs (added 2026-08-17, A577) ------ 🔴 EVERY ONE OF THESE IS SEEDED WITH THE VALUE THIS SURFACE ALREADY RENDERS, so adding them moves nothing in light. That is the same promise the button block above makes, kept the same way: read the live value, name it, then give the name a second value in the other scheme. A token minted with a "nicer" light value would repaint a sign-in screen on a build that asked for nothing, which is the one thing this file may never do. * --sa-field-ink is app.min.css's own --bs-body-color (#4B4B5A, read off `:root,[data-bs-theme=light]`). It is NOT --sa-ink: body text on these pages is #1f2937 and a form control's text is #4B4B5A, and those two genuinely differ today. Mapping the Bootstrap variable onto --sa-ink would have "fixed" that difference and moved live pixels, so the difference is preserved and only the DARK value is decided here. * --sa-brand-strong and --sa-btn-ink are `var(--sa-brand)` / `var(--sa-btn)` in light — literally the same computed colour, and written as a reference rather than a copy so an assigned preset still reaches them. They exist because --sa-brand (#1f4cbf) and --sa-btn (#5369f8) are BRAND tokens: the dark blocks below must not redeclare them (see the white-label note there), but a dark blue wordmark on a #121214 page is 2:1. So the brand's HUE stays the brand's, and the tone that has to carry text off a dark ground is derived from it. */ --sa-field-ink: #4B4B5A; --sa-brand-strong: var(--sa-brand); --sa-btn-ink: var(--sa-btn); --sa-btn-ink-hover: var(--sa-btn-hover); /* A726 — THIS PALETTE'S BINDING FOR THE SHARED AUTOFILL MASK (travelmean-autofill.css owns the rule; four palettes bind it, this is one). Same shape as --sa-brand-strong two lines up: a REFERENCE, not a copy, so the dark block below redefines --sa-surface/--sa-field-ink and the mask follows without a second declaration here. Measured against a real non-autofilled `.form-control` on the sign-in page rather than assumed: light #ffffff on #4B4B5A = 8.56:1, dark #1b1b1f on #f5f5f7 = 15.77:1. Ground is the SURFACE token and ink is the FIELD-INK token — never swapped (A574/A577: the two invert between schemes, so borrowing one as the other renders white on white). */ --tm-autofill-ground: var(--sa-surface); --tm-autofill-ink: var(--sa-field-ink); /* 🔴 A747 — THIS PALETTE'S BINDING FOR THE SHARED FIELD FOCUS RING, and this sheet was the emptiest of the four. Measured before this wave: the word "focus" appeared ZERO times in this file. Not a weak ring, not a ring the theme happened to erase — no focus declaration at all, on the page an operator signs in with and on every consumer account page that wears this palette. The owner's round-7 answer 4 (2026-08-22) is "add it to the storefront, the admin sign-in page and the admin panel; same token family, each surface follows its OWN palette". 🔴 IT READS --sa-brand-strong, NOT --sa-brand, AND THAT IS THE WHOLE POINT OF THE TOKEN TWO BLOCKS UP. The presets assign --sa-brand per installation and declare it LIGHT-ONLY on purpose (A308 — these pages had no switcher when it was written), so in the dark scheme the raw brand is still the light hue: measured on --sa-surface #1b1b1f it reads 2.33:1 default, 2.82:1 deep-sea, 1.96:1 plum, and no opacity reaches 3:1 from there because those ARE the full-strength numbers. --sa-brand-strong is the tone this file already derives for exactly that ground (60% toward #fff, its own measurement is in the dark block below), so binding to it makes the ring follow both the assignment AND the scheme with one declaration. Borrowing the wrong one of the pair is the A574/A577 inversion, one line down from where this file already says so about ground and ink. Opaque, for the reason argued in storefront-base.css: SC 2.4.11 asks 3:1 against the unfocused pixel and a translucent ring lands on the floor at these hues. Measured against both grounds a field sits on (--sa-surface and --sa-page), worst per palette: light default 6.94:1 deep-sea 5.56:1 graphite 4.89:1 plum 7.95:1 dark default 5.74:1 deep-sea 6.37:1 graphite 6.62:1 plum 5.33:1 */ --tm-focus-ring: 0 0 0 3px var(--sa-brand-strong); } /* ============================================================================ THE DARK SCHEME (A577) — keyed on the ATTRIBUTE ONLY, and the missing @media block is a measurement rather than an omission. ============================================================================ A574 gave the storefront three CSS states: `:root`, a `@media (prefers-color-scheme: dark)` block guarded by `:root:not([data-theme="light"])`, and `:root[data-theme="dark"]`. This sheet deliberately has only TWO, and a later reader who "restores" the third will break ten pages. Both reasons were measured on this branch: 1. BOOTSTRAP'S DARK LAYER IS ATTRIBUTE-ONLY. app.min.css is the full Bootstrap 5.3 build; it declares a complete `[data-bs-theme=dark]` variable layer (--bs-body-bg, --bs-body-color, --bs-border-color, --bs-emphasis-color, and the -bg-subtle / -text-emphasis family that .alert-success, .alert-warning and .table paint from) and it contains ZERO `prefers-color-scheme` rules. A palette keyed on the media query would turn the page dark while every form control, alert and table stayed light — the "one card, two palettes" defect this file already documents for the button. 2. THIS SHEET IS SHARED BY ELEVEN ENTRY POINTS AND ONLY ONE STAMPS A SCHEME. _ConsumerLayout stamps data-bs-theme. The other ten — the eight Views/Account pages, Views/Membership/Index and Views/Storefront/Gate — render Layout = null and stamp `data-admin-theme` and nothing else. A media block here would repaint all ten, half-dark, including the sign-in gate, without anything asking it to. Keyed on the attribute, this block simply never matches for them and they render byte-for-byte as they do today. 🔴 THE THIRD STATE IS NOT LOST — IT MOVED FROM CSS TO THE STAMP. "System" is resolved by SurfaceThemeChoice.SchemeFor plus _ConsumerLayout's head script, which writes this attribute before first paint exactly as A574's does. So all five combinations still resolve, and a hand-made choice still wins in BOTH directions: OS light + chose light -> attribute light LIGHT OS light + chose dark -> attribute dark DARK OS dark + chose light -> attribute light LIGHT OS dark + chose dark -> attribute dark DARK OS dark + chose system -> script writes dark DARK Scriptless, "system" renders light — the same fallback A574 ships and for the same reason: prefers-color-scheme is a property of the reader's machine and never reaches the request. 🔴 THE BRAND'S OWN HUE IS NOT REDECLARED BELOW — the white-label contract, identical to A574 §5. travelmean-theme-presets.css assigns --sa-brand, --sa-btn and the button's four derived tones at `html[data-admin-theme=X]`, which weighs (0,1,1); this block weighs (0,2,0) and would outrank every one of them. So it redeclares NEUTRALS only — ground, ink, field ink, rule — which a palette sets to off-whites that carry no identity. --sa-brand, --sa-btn*, --sa-on-btn, --sa-danger and --sa-success are left alone, and the two tones that must lift off a dark ground are MIXED from them in the @supports block below, so an assigned teal stays teal in dark. Measured (WCAG 2.1 relative luminance; AA text 4.5, non-text 3.0): --sa-ink #f5f5f7 on --sa-page 17.18 on --sa-surface 15.77 --sa-muted #c6c6ce on --sa-page 11.02 on --sa-surface 10.11 --sa-field-ink #f5f5f7 on --sa-surface 15.77 --sa-link #98a5fb on --sa-page 8.12 on --sa-surface 7.45 --sa-brand-strong on --sa-page 6.28 on --sa-surface 5.76 (default palette) --sa-btn-ink on --sa-page 8.12 on --sa-surface 7.45 (default palette) --sa-control-rule on --sa-page 4.47 on --sa-surface 4.10 (floor 3.0) --sa-danger-rule is 2.05:1 on --sa-surface and that is stated rather than excused: it is the border of .tm-danger-zone, a decorative boundary around a card that already carries its own heading and warning sentence, so 1.4.11 does not reach it — the same call A574 wrote for --tm-rule, and it is MORE visible here than the 1.30:1 the light scheme ships. The CONTROL edge is a separate token and clears 3.0 on both grounds above. ============================================================================ */ :root[data-bs-theme="dark"] { --sa-page: #121214; --sa-surface: #1b1b1f; --sa-ink: #f5f5f7; --sa-muted: #c6c6ce; --sa-field-ink: #f5f5f7; --sa-control-rule: #7b7b86; --sa-link: #98a5fb; --sa-danger-rule: #7a3b39; /* Fallbacks for a browser without color-mix(); the @supports block below re-derives both from the assigned brand. These literals are the DEFAULT palette mixed at the same 60%, computed by hand. */ --sa-brand-strong: #7994d9; --sa-btn-ink: #98a5fb; --sa-btn-ink-hover: #919be5; } /* The dark derivation. It mixes toward #fff where light uses the brand neat, and the ratio was MEASURED across all four shipped palettes rather than copied from A574 — the storefront's 72% fails here: plum-moss (#7a2e63) mixed at 72% is 4.00:1 on --sa-surface, under AA. At 60% the worst of the four is 5.34:1. default #1f4cbf -> 6.28 page / 5.76 surface deep-sea #0d6b83 -> 6.94 / 6.36 graphite #b34a12 -> 7.18 / 6.59 plum #7a2e63 -> 5.82 / 5.34 Placed after the block above because both weigh (0,2,0) and source order is what separates them. */ @supports (color: color-mix(in srgb, red 50%, blue)) { :root[data-bs-theme="dark"] { --sa-brand-strong: color-mix(in srgb, var(--sa-brand) 60%, #fff); --sa-btn-ink: color-mix(in srgb, var(--sa-btn) 60%, #fff); --sa-btn-ink-hover: color-mix(in srgb, var(--sa-btn-hover) 60%, #fff); } } /* ============================================================================ The one RULE in this file. Everything above is a value; this maps the values onto the Bootstrap variables the button actually reads. Scope is safe by construction: only the ten self-contained pages link this stylesheet, so this selector cannot reach the admin panel, the agency portal or anything else. It wins over app.min.css's own `.btn-primary` block at equal specificity because this file loads after it — the same source-order contract travelmean-tokens.css relies on, and the reason neither needs !important. ============================================================================ */ .btn-primary { --bs-btn-bg: var(--sa-btn); --bs-btn-hover-bg: var(--sa-btn-hover); --bs-btn-active-bg: var(--sa-btn-active); --bs-btn-disabled-bg: var(--sa-btn); --bs-btn-border-color: var(--sa-btn-rule); --bs-btn-hover-border-color: var(--sa-btn-rule-hover); --bs-btn-active-border-color: var(--sa-btn-rule-active); --bs-btn-disabled-border-color: var(--sa-btn-rule); --bs-btn-color: var(--sa-on-btn); --bs-btn-hover-color: var(--sa-on-btn); --bs-btn-active-color: var(--sa-on-btn); --bs-btn-disabled-color: var(--sa-on-btn); } /* ============================================================================ THE TWO SURFACE VARIABLES (A577) — the same move as the button above, one layer down, and the reason the dark card does not end up wearing two palettes. Bootstrap paints a form control's fill and text from --bs-body-bg and --bs-body-color, declared at `:root,[data-bs-theme=light]`. Its dark layer re-declares them as #36404a / #94a0ad — Shreyu's blue-greys, which are a perfectly good pair and belong to a DIFFERENT dark system than the neutral one this sheet ships. Left alone, a dark _ConsumerLayout card (#1b1b1f) would hold inputs filled #36404a: "one card, two blues" again, exactly the defect the button block above was written to end. 🔴 LIGHT IS UNCHANGED TO THE PIXEL, and that is why the seeds matter: --sa-surface is #ffffff in the default AND in all three presets, which is precisely what --bs-body-bg already resolves to; --sa-field-ink was seeded with Bootstrap's own #4B4B5A. So in light this rule re-states the values that were already there, and only the dark block gives them somewhere else to go. These sit at `:root` (0,1,0) and this file loads after app.min.css, so they beat both `:root,[data-bs-theme=light]` and `[data-bs-theme=dark]` at equal specificity on source order — the same contract the button rules rely on, and the reason none of this needs !important. ⚠️ The PAGE background is not one of these. _ConsumerLayout sets `body { background: var(--sa-page) }` in its own head, and the eight Views/Account pages each set their own; --bs-body-bg reaches the controls only. ============================================================================ */ :root { --bs-body-bg: var(--sa-surface); --bs-body-color: var(--sa-field-ink); } /* The outline button, wired for the first time — and it was a REAL half-applied palette, not a hypothetical one. .btn-outline-primary declares --bs-btn-color and --bs-btn-border-color as the literal #5369f8 on the variant class (0,1,0), so like .btn-primary before it nothing at :root could reach it: with deep-sea assigned, Views/Error/ConsumerStatus rendered an INDIGO "Back to sign in" button on a page whose every other button had gone teal. The same bug the button block above fixed, one variant over, found by reading this file's own argument back against the rest of the sheet. In light every value below resolves to what Bootstrap already declared, so nothing moves; in dark --sa-btn-ink lifts off the ground while the fill, the hover and the border keep the brand's own hue. */ .btn-outline-primary { --bs-btn-color: var(--sa-btn-ink); --bs-btn-border-color: var(--sa-btn-rule); --bs-btn-hover-color: var(--sa-on-btn); --bs-btn-hover-bg: var(--sa-btn); --bs-btn-hover-border-color: var(--sa-btn-rule); --bs-btn-active-color: var(--sa-on-btn); --bs-btn-active-bg: var(--sa-btn); --bs-btn-active-border-color: var(--sa-btn-rule); --bs-btn-disabled-color: var(--sa-btn-ink); --bs-btn-disabled-border-color: var(--sa-btn-rule); } /* The checked checkbox is the same story one component over: Bootstrap fills it from --bs-form-check-bg-image plus a background-color declared on `.form-check-input:checked` at (0,2,0), so :root cannot reach it either. Left alone it stayed indigo beside a teal button on the same card — the smallest visible piece of a half-applied palette, and the easiest to miss because nobody looks at a checkbox. The tick GLYPH is a background-image data-URI with the colour baked into the SVG; it is white in the inherited theme and stays white, which is correct against every palette base we ship. It is called out rather than silently inherited: a preset with a pale base would need its own glyph, and there is nothing here that would warn about it. */ .form-check-input:checked { background-color: var(--sa-btn); border-color: var(--sa-btn); } /* ============================================================================ The control edge and the text link — the two contrast fixes (2026-08-14). Scope is safe by the same construction as the button rules above: only the self-contained pages link this stylesheet, so neither selector can reach the admin panel. Both win over app.min.css at equal-or-lower specificity because this file loads after it — the source-order contract, no !important. The border rule leaves the CHECKED checkbox alone: `.form-check-input:checked` above is (0,2,0) and re-states its border as the fill colour, which beats this (0,1,0) rule, so a ticked box keeps its brand edge and only the empty controls pick up the readable grey. The link rule targets classless links only — `a:not([class])` — so button- shaped anchors (.btn-primary / .btn-outline-primary / .tm-pager__btn) keep their own colours and only the plain "I forgot my password" / "Back to sign in" text links darken to clear 4.5:1. ============================================================================ */ .form-control, .form-select, .form-check-input { border-color: var(--sa-control-rule); } a:not([class]) { color: var(--sa-link); }