@charset "UTF-8"; /* USER VARIABLES SECTION */ /* ============================================================================ Theme v3 "Merged design" tokens (MERGED-PLAN-2026-07-24 + CANVAS-SPEC — R7). Green is RETIRED as a UI color: #00467F is THE one action color (Q1). Light theme lives on :root; the dark theme overrides live under [data-bs-theme="dark"], which the inline theme script (Resources.ascx) stamps on before first paint (OS auto via prefers-color-scheme + header toggle persisted in localStorage). The design is light-first, so every dark value here is DERIVED (plan §5-D5) — dark stays fully shipped. Legacy variable names (--black, --darker-grey, ...) are ALIASED onto the new tokens so the existing partials inherit the new world without a mass rewrite; new/updated code should prefer the canonical names. POLISH S6a, P3-21 (2026-08-20): the alias list is not open-ended - an alias with ZERO consumers is deleted, not kept. --green / --green-accent / --green-text, --orange, --link, --panel, --blue-light, --blue-lighter, --charcoal, --caution, --caution-check, --shadow-card and the four non-rgb --bs-* greys all went that way (17 declarations); their 15 live uses were rewritten onto --cta / --ok first. ========================================================================== */ /* ── THE palette, authored once (R12) ───────────────────────────────────────── Every colour below used to exist in THREE hand-maintained places: the canonical --token custom properties, a "--bs-* Bootstrap bridge" block inside :root, and the $theme-colors map Bootstrap compiles its components and utilities from. Nothing kept the three in sync — which is exactly how R11 came to measure .bg-light at 1.06:1 in dark mode (the bridge had no dark values while the ink inside followed the theme) and why --bs-blue only resolved to COLAMCO blue because _skin.css happens to load after bootstrap.css. They are Sass variables now and all three consumers DERIVE from them, so the drift is structurally impossible rather than merely patched. to-rgb() needs Bootstrap's functions, hence the import here; the rest of the chain (variables → variables-dark → maps → utilities) is imported further down as before, and Bootstrap's own variables are all !default so setting $blue and $theme-colors above it still wins. */ /* Session K, 2026-08-11: the $blue / $c-* / $d-* declarations that used to sit here now live in _palette.scss, unchanged apart from the two Session K values ($c-paper-2, $c-input) and two new names ($c-ink-faint, $c-input / $d-input). Nothing else moved and no consumer below changed. The reason for the split is stated in that file: _myaccount.scss is its own compilerconfig entry, cannot see THIS file, and had therefore re-stated eight of these hex values by hand — two of them already a session out of date. A Sass-only partial can be imported by an entry that must not inherit the token/Bootstrap layers, and it emits nothing. This file still owns what the numbers MEAN: the :root token layer, the dark overrides, and the Bootstrap $theme-colors bridge. */ /* ============================================================================ THE palette, as Sass variables only — no selectors, no declarations, so this file emits ZERO bytes wherever it is imported. Extracted from _variables.scss in Session K (2026-08-11) for one reason: _myaccount.scss is its own compilerconfig entry and cannot see _variables.scss, so its `.myaccount-module .message-body` document surface (the transactional-email sheet that must stay light in BOTH themes) had re-stated eight of these values as hex literals — and two of them had already drifted a session behind (--ink #14181d, --ink-2 #5f6670, both pre-Harbor). That is R11/R12's lesson for the third time: a colour restated by hand in a second place is a colour that will disagree with the first. Anything that needs a palette value at COMPILE time imports this file. Anything that needs it at RUNTIME uses the var(--token) custom properties that _variables.scss derives from it — which is almost everything. _variables.scss owns the token layer, the [data-bs-theme="dark"] overrides and the Bootstrap maps; it is still the place to read to understand a token's MEANING. This file is only where the numbers live. ========================================================================== */ :root { /* — canonical tokens (CANVAS-SPEC token table) — */ --ink: #0f1b26; /* body text */ --ink-2: #51636f; /* muted text — AA-safe (replaces #727880) */ /* Harbor §2.3 asks for #8a99a6 here and it CANNOT ship: measured 2.92:1 on white, under the 3:1 floor this tier exists to hold for large text (the old #8a95a0 was 3.05:1). #8695a2 is the same Harbor hue one step darker — 3.07:1 — so the tier keeps its meaning and axe keeps its zero. Do not "restore" the plan's value without re-measuring. */ --ink-3: #8695a2; /* faint ink — large/struck-price text ONLY (3.07:1 on white) */ /* Session K: #656f7a → #626c77, ONE step darker and nothing more. --paper-2 moved down to #e9eff5 to become a visible panel (see $c-paper-2); at that value #656f7a measured 4.41:1 on --paper-2, i.e. this tier would have lost the AA claim its own comment makes. #626c77 restores it (4.61:1 on --paper-2, 5.3:1 on --paper). Darkening is a monotone improvement — every other surface this tier lands on gains contrast — so there is nothing else to re-measure. */ --ink-faint: #626c77; /* R11: THE quiet small-text tier — the faintest neutral that still clears AA at 12px on BOTH --paper (5.3:1) and --paper-2 (4.6:1). Use for the PDP ID row, "Share", struck price, inventory timestamp, part numbers, pagination — anything faint that is still text. --ink-3 is large-text-only and --rule-strong is a BORDER: neither is AA-safe for small copy (R10 measured 2.53:1 light / 1.99:1 dark). */ --paper: #ffffff; /* cards / primary surfaces */ --paper-2: #e9eff5; /* soft panels / image plates */ --ground: #f4f7fa; /* page ground / alt bands */ /* ================================================================================== SURFACE SWAP, 2026-08-21 (SURFACE-SWAP-TRUST-RAIL-PLAN, S1, decision 1). LIGHT WAS SWAPPED. DARK DELIBERATELY WAS NOT. --paper itself is NOT flipped, because "white" is still meant literally in a lot of places: form fields, image wells, brand-logo plates, wallet buttons, overlay sheets. A repointable token per ROLE is what makes the swap triageable: --surface-card the fill of a real card/panel that sits ON the page field. light --paper-2 (#e9eff5) dark --paper (#101d2c) --surface-plate a plate/well/quiet control INSIDE such a card - it must not equal the card it sits in, which --paper-2 now does in light. light --paper (#ffffff) dark --paper-2 (#16273a) --control-hover the hover/focus fill of a WHITE control that sits on a card. The old --paper-2 wash is now the card's own colour, i.e. invisible. light --rule (#d8e2ec) dark --paper-2 (#16273a) The dark values of all three are exactly what those sites already computed, so dark is pixel-unchanged - that is the cheapest proof the swap is token-level. WHY DARK CANNOT USE THE SAME MAPPING: light --paper-2 sits BELOW --paper in luminance (the field recedes, the cards come forward). In dark, $d-paper-2 (#16273a) is LIGHTER than $d-paper (#101d2c) - it had to be, see _palette.scss - so carrying the light mapping through would put every card IN FRONT of the field it sits on. Dark's field is --ground, which is the one token darker than --paper there. ================================================================================== */ --surface-card: var(--paper-2); --surface-plate: var(--paper); --control-hover: var(--rule); --pill-border: var(--rule); /* the inset ring that makes a white pill a pill (see --pill-bg) */ --blue: #00467f; /* COLAMCO blue — brand fields, seals (constant across themes) */ --blue-deep: #051526; /* masthead, footer, dark hero, ASSIST band */ --blue-tint: #e8f0f7; /* selected/active washes */ --blue-link: #00579e; /* text links & accents (flips light in dark theme) */ --cta: #00467f; /* THE one action color (Q1: blue CTA, green retired) */ --cta-press: #0a5391; --cta-ink: #ffffff; /* text on the action blue — white (8.7:1) */ --cta-outline: #00467f; /* outline-CTA border/text — flips lighter in dark */ --focus: #00467f; /* focus-visible ring — flips to the on-dark accent in dark */ --ok: #3d6785; /* positive text semantic (steel family — ticks, savings text; AA on white) */ --steel: #5980a6; /* ornaments, icon strokes, review bars — never a CTA */ --steel-tint: #e7edf3; /* "Buying for an organization?" panels */ /* SURFACE SWAP S1 (2026-08-21): LIGHT went #e7edf3 -> #ffffff and gained --pill-border. The pill now sits on --surface-card (#e9eff5), and #e7edf3 on #e9eff5 is a hairline - the fill stopped reading as a pill at all (the same failure Session E fixed in dark, one surface over). White needs an edge to be a pill rather than a hole, hence --pill-border; it is drawn as an INSET RING, not a border, so no pill anywhere changes size. DARK IS UNTOUCHED. */ --pill-bg: #ffffff; /* SAVINGS PILL fill (Session E). Was --steel-tint's value in LIGHT, and a separate token on purpose: in dark, --steel-tint (#14222f) is a hairline from dark --paper (#101d2c), so the SAVE pill's fill vanished and the pill read as plain text — it passes contrast (the ink is fine) so axe never flagged it. Retuning --steel-tint would have moved the organization panel and the cart with it; the pill needed its own pair. Harbor's own values. */ --pill-ink: #3d6785; /* ink on --pill-bg */ --warn: #b45309; /* warnings AND the amber risk stamp. 2026-08-12: "stock states render blue/neutral (D12)" was struck — DESIGN.md supersedes §5-D12 with "in-stock = blue stamp, backorder/limited = amber stamp", and the neutral outline D12 mandated measured 1.77:1, below the 3:1 a stamp's border owes as the sole carrier of a state. Now on .mc-chip-special / .mc-chip-out / .cs-est-tag (5.02:1 light, 7.4:1 dark). */ --err: #b3261e; --rule: #d8e2ec; /* hairline card + row rules */ --rule-2: #eceff2; /* softer inner rules */ --rule-strong: #b9c4ce; /* limited / neutral stamp outline — DECORATION, 1.77:1 on --paper. Never the sole carrier of a control's boundary or of a state: use --input for that (see below). Session N raised the DARK value only (1.66:1 -> 3.49:1); this light value is unchanged by ruling — see the dark block for why the two themes diverge. */ /* Session K, 2026-08-11 (PLAN §6 last bullet). The reported defect was that --input and --rule-strong had collided; measured, the ladder was INVERTED — #cdd5dd is 1.50:1 on --paper against --rule-strong's 1.77:1, so the token named "form-field borders" was the WEAKER of the two, and _components.scss had (correctly, for the values it found) put --rule-strong on .form-control / .form-select instead. Both were far under the 3:1 WCAG 1.4.11 asks of a control boundary; axe never says so, because 1.4.11 on borders is not one of its automated rules — which is how six redesign sessions held axe 0 over it. --input is now THE 3:1 interactive-boundary tier and .form-control / .form-select name it: light #798896 — 3.64:1 on --paper, 3.38:1 on --ground, 3.14:1 on --paper-2 (the worst case, since a darker surface costs a dark border contrast) dark #5c7488 — 3.49:1 on --paper, 3.80:1 on --ground, 3.11:1 on --paper-2 --rule-strong keeps its decorative sites. Its use as a SECONDARY BUTTON border (.btn-neutral, .myaccount-* outline buttons) is a genuine 1.4.11 gap at 1.77:1 and a sitewide restyle, so it is measured and recorded in SESSION-K §Owed rather than changed here. Session N, 2026-08-11 enumerated the survivors by parsing the SCSS, not by grep count: the real figure is 38 declarations in 10 files, not 46 — and FOUR of them were not decoration. .co-change (_cart.scss), .qo-upload (_cart.scss) and .newsletter-signup input[type=email] (_components.scss) moved to --input in that session; .theme-toggle (_chrome.scss) is dead at runtime (the topbar rule wins at 3.19:1) and was left alone. */ --input: #798896; /* interactive boundaries: form fields, the qty spinner group, the warranty radio, .view-details, suggestion chips — anything whose outline IS the control. Held at ≥3:1 against --paper / --ground / --paper-2. */ --stamp-instock: #00467f; /* in-stock stamps are COLAMCO blue */ --field-ink: #ffffff; /* text on brand/navy fields — CONSTANT, never theme ink */ --field-ink-2: #b9cddf; /* secondary text on navy */ --field-ink-3: #9fb2c6; /* tertiary text on navy */ --field-accent: #8cc0e8; /* kickers / accents on navy (large text + chrome only) */ --gold: #e6a817; /* review stars (ornament only) */ --badge-amber: #c2410c; /* cart count badge — distinct from everything, NOT green */ /* Caution family: amber, for the states where the order can still proceed. Session K widens it from "ONLY the backorder acknowledgment" to the cart's stock-issue banner (.cart-alert), which already called itself a caution treatment while spending --warn on its fill, bar AND ink — and measured 4.38:1 for that ink. --caution-ink exists because --warn is a 4.5:1-on-PAPER token, not a 4.5:1-on-amber-fill one. Anything that draws an amber panel belongs here; --warn stays for warning text on paper. */ --caution-bg: #fbf6ef; --caution-bd: #e7d4bd; --caution-ink: #7a4a12; --caution-mark: #9a5b16; /* Harbor §2.3. --band-grad is not in the plan's table but is the hero's sibling (the ASSIST band): it is re-stopped on the same three navies so the two bands cannot drift apart. */ --hero-grad: radial-gradient(120% 150% at 80% -30%, #0e3d68 0%, #07223c 52%, #041526 100%); --band-grad: radial-gradient(130% 130% at 20% 0%, #0e3d68, #07223c 55%, #041526); --shadow-cta: 0 8px 22px rgba(0, 70, 127, 0.32); /* Redesign type system (PLAN §2.2). Three families, all self-hosted latin subsets — the @font-face blocks are in _global.scss. Both text stacks still fall back through `Arial, Helvetica, sans-serif`, the one fallback stack the rest of the site spells out by hand; R79 measured an Arial/Helvetica tail at ZERO element displacement against the settled webfont layout where `system-ui` moved 68 (1px each), and that holds regardless of which webfont sits in front of it. The "Archivo Fallback" metric face that --ff-d used to interpose is GONE with Archivo — it was tuned to Archivo's metrics at font-stretch:66% (see _global.scss). */ --ff-d: "Schibsted Grotesk", Arial, Helvetica, sans-serif; /* display: headings, hero, display prices */ --ff-u: "IBM Plex Sans", Arial, Helvetica, sans-serif; /* UI/body */ /* ⚠ THE NAME IS HISTORICAL — this is NOT a monospace stack any more. Refinement A5 (2026-08-12, Juan): IBM Plex Mono is retired sitewide. The eyebrow / ALL-CAPS-label grammar keeps its own token so the 53 places that spend it stay one decision, but the face it resolves to is now the UI face. The Mono @font-face blocks are deleted from _global.scss with it — four static weights that nothing requests. Every rule that names --ff-m and also relies on figure alignment already carries its own `font-variant-numeric: tabular-nums`, which IBM Plex Sans supports, so column alignment survives the change; do not re-add a mono fallback to "protect" it. */ --ff-m: "IBM Plex Sans", Arial, Helvetica, sans-serif; /* eyebrows, ALL-CAPS captions, labels */ /* Display tracking. Theme v3 drew its display grammar through Archivo's width axis (font-stretch:66%) with -0.01em on top; Schibsted Grotesk has no width axis, so the condensation is gone and the tightening is all in the tracking. One token so a later session can retune the whole display grammar in one place. */ --display-tracking: -0.025em; /* — legacy aliases (keep old partials on-palette) — */ --black: var(--ink); --darker-grey: var(--ink-2); /* R11: was var(--rule-strong) — a BORDER token. Every one of the nine places the legacy partials spend --dark-grey is faint TEXT (part numbers, struck price, stock timestamp, pagination, "Remove"), so it rendered at 2.53:1 light / 1.99:1 dark. Re-pointed at the AA-safe small-text tier; the one place that genuinely wanted a rule (the ID-row separator bar, _product.scss) now names --rule-strong directly. */ --dark-grey: var(--ink-faint); --grey: var(--rule); --light-grey: var(--rule); --lightest-grey: var(--paper-2); --error: var(--err); --caution-text: var(--warn); --success: var(--ok); --white: #ffffff; /* constant true white (text on blue/dark fields) */ /* Refinement A1/A2 (D1, 2026-08-12): the page FIELD is tinted; panels and cards stay --paper. --paper-2 (#e9eff5), not --ground (#f4f7fa) — --ground was mocked as the softer alternative and Juan picked the stronger one. HOME needs no exception (Juan, 2026-08-12): all eight of its sections are full-bleed bands that paint their own background and are spaced with padding, not margin, so the body field is never exposed there. If a future home section ships with no band of its own it will show the tint — that is the moment to revisit, not before. */ /* SURFACE SWAP S1 (2026-08-21, Juan): the LIGHT field and the LIGHT card TRADE PLACES. The field is --paper (#ffffff) and a card is --surface-card (#e9eff5, i.e. the old field tint). The A1/A2 note above records why the tint was on the field; the swap keeps the same two values and the same 1.158:1 separation, it only decides which side of the edge carries it. DARK IS DELIBERATELY NOT SWAPPED - see --surface-card in the dark block for why it cannot be (--paper-2 is LIGHTER than --paper there), so dark keeps --bgbody: var(--ground). */ --bgbody: var(--paper); --fontsize: 16px; --textcolor: var(--ink); --lineheight: 1.55; --userfont: var(--ff-u); /* POLISH S2, P2-06 (2026-08-20): the token carried a duration and an easing but NO property, so every `transition: var(--transition)` site expanded to `transition-property: all` and animated layout as well as colour. All seven live sites (_button.scss:178, _category.scss:165, _components.scss:875 and :887, _global.scss:371, _myaccount.scss:121 and :128) only ever change colour, background, border colour or opacity on hover/focus, so the property list is named here once rather than per component. `a { transition: var(--transition) }` is what made the skip link interpolate its padding, radius and font weight from the visually-hidden box (P2-05). */ --transition: color 0.3s ease, background-color 0.3s ease, border-color 0.3s ease, opacity 0.3s ease; /* POLISH S2, P2-06/P2-08 (2026-08-20): the ONE quiet-interactive hover wash, for control families that carry no colour of their own to step - the .chip-stamp explainer buttons, the PDP gallery thumbnails and the filter rail's facet rows. An ink wash rather than a paper token because those three sit on different fields (--paper card, --paper-2 page, the sticky bar's blurred surface) and a fixed surface colour reads on only one of them; a translucent wash reads on all of them and flips with the theme for free. */ --hover-wash: color-mix(in srgb, var(--ink) 8%, transparent); /* ------------------------------------------------------------------------------------ POLISH S3, P2-07 (2026-08-20): THE HEADING RAMP, PUBLISHED AS TOKENS. Measured before this session at 1440: four different page-H1 sizes across the five commerce surfaces (home 60, category 40, cart 34, checkout 34, PDP 28), FIVE section-H2 sizes on home alone (36/40/44/46 plus a 30px catalog card), and five sizes for the one ALL-CAPS eyebrow role (12.5 / 12.8 / 11.52 / 11.5 / 10.5). Of all of them only 36 was on the scale DESIGN.md publishes. The scale itself was never the problem - the base h1..h6 rules in _global.scss already implement it - the problem was that every component wrote its own clamp() instead of naming a step, so there was nothing for a new component to inherit and nothing a review could check against. So the steps are named here and consumed by role. A component may pick a DIFFERENT step from its tag (a page H1 that carries catalog data takes --fs-3, see .product-title) but it may not invent a size between two steps. The values are the clampFunction() output for the same pairs _global.scss already uses - written out because _variables.scss does not @import _mixin.scss. $clampLaptop is 1440, so each middle term is max/1440*100vw and every step hits its max at exactly 1440. ------------------------------------------------------------------------------------ */ --fs-display: clamp(38px, 4.16667vw, 60px); /* 60/38 - the home hero, one instance sitewide */ --fs-1: clamp(34px, 3.61111vw, 52px); /* 52/34 - h1 base */ --fs-2: clamp(27px, 2.5vw, 36px); /* 36/27 - page title, band title */ --fs-3: clamp(21px, 1.94444vw, 28px); /* 28/21 - data page title, sub-section, empty state */ --fs-4: clamp(18px, 1.52778vw, 22px); /* 22/18 - spec group, card title */ --fs-5: clamp(16px, 1.25vw, 18px); /* 18/16 - panel title */ --fs-6: clamp(14px, 1.11111vw, 16px); /* 16/14 - row title, minor title */ --fs-label: 12.5px; /* the ALL-CAPS eyebrow / rail label / footer column head - does NOT clamp */ /* POLISH S3, P2-18 (2026-08-20): ONE stroke weight for the authored inline-SVG icon set. Five weights were in the tree: 1.75 in markup (48 bare , not on (measured 0px of padding on body and on header.sticky-top with a modal open, before and after this change). SweetAlert2 measures its own way, gets the real 10px, and writes it inline on . Against the stable gutter that is a second, opposite 10px - so it is neutralised rather than left to fight. `!important` is not decoration: the declaration it has to beat is an inline style, and nothing weaker can. swal2 restores its own value on close, which this simply keeps at 0. */ body.swal2-shown { padding-right: 0 !important; } /* SESSION 6 ITEM 3, third half — and this one is the part that actually moved the page. Neutralising swal2's padding was not enough: measured with the padding rule already live and computing 0px, body.clientWidth STILL went 1430 -> 1420 and the content still slid 55 -> 50. The cause is `body.swal2-height-auto { height: auto !important }`, which swal2 applies to AND to let a tall dialog scroll the page. This site does not need that - the swal2 container is `position: fixed; inset: 0` with its own `overflow-y: auto`, so the dialog already scrolls itself - and here it is actively harmful: at rest html and body are BOTH 900px (the viewport) with the page scrolling inside body, and `height: auto` takes them both to the document's 6080px, which hands a scrollbar of its own ON TOP of body's reserved gutter. Two gutters, 20px, hence the 5px slide. Restoring the resting height puts it back. `html body.swal2-height-auto` is (0,2,1) so it beats the vendor's own !important at (0,2,0) without needing to load later than it. Measured with this rule in place, dialog open and the page scrolled to 1500: html.clientWidth 1440, body.clientWidth 1430, content x 55.0, content y 1950.2 and scrollTop 1500 - identical to at rest and identical after close. */ html.swal2-height-auto, html body.swal2-height-auto { height: 100% !important; } .pac-container { z-index: 1060; } h1, .h1, h2, .h2, h3, .h3, h4, .h4 { font-family: var(--ff-d); letter-spacing: var(--display-tracking); text-wrap: balance; } /* R100 (2026-08-21): `.cond` DELETED. It was published as "the canonical display utility for non-heading display type" but nothing ever reached for it: zero `cond` class tokens across every .cshtml / .ascx / .js / .cs in all three projects, in dbo.HtmlText / TabSettings / ModuleSettings on DEV, and in 24 rendered page loads (the many textual hits are the words "second"/"condition" inside comments and identifiers, which is why this needed a word-boundary grep). Components that want the display face state `font-family: var(--ff-d)` themselves. If a shared utility is wanted again, re-add it WITH its first consumer. */ /* POLISH S3, P2-07 (2026-08-20): these six rules ARE the published ramp and they were already right - what was missing was a name a component could reach for, so each step now reads from the --fs-* token in _variables.scss instead of repeating the clampFunction() pair. The emitted clamp() is byte-identical; nothing here changes size. */ h1, .h1 { font-size: var(--fs-1); font-weight: 800; } h2, .h2 { font-size: var(--fs-2); font-weight: 800; } h3, .h3 { font-size: var(--fs-3); font-weight: 700; } h4, .h4 { font-size: var(--fs-4); font-weight: 700; } h5, .h5 { font-size: var(--fs-5); font-weight: 600; font-family: var(--ff-u); } h6, .h6 { font-size: var(--fs-6); font-weight: 600; font-family: var(--ff-u); } p { font-size: var(--fs-6); font-family: var(--ff-u); } /* Tabular numerals on every price, quantity, countdown and part number (DESIGN.md). `.num` is the canonical utility; number inputs and the cart count badges get it implicitly. */ .num, .tabular-nums, input[type=number], .lbl-cart-itemcount { font-variant-numeric: tabular-nums; } /* DARK-MODE HOVER FIX 2026-07-30: `.table-hover` was unreadable in dark theme everywhere it is used (reported on the PDP technical-specification rows). Two separate halves of the same bug: 1. `$table-hover-bg: $c-paper-2` in _variables.scss is a Sass LITERAL, so Bootstrap compiles `--bs-table-hover-bg: #f4f6f8` into the `.table` rule once. It is not a var(), so it never flips — dark theme kept painting the hovered row near-white. 2. Bootstrap's own `--bs-table-hover-color: var(--bs-emphasis-color)` resolves to #fff under [data-bs-theme="dark"]. Together: #fff text on #f4f6f8. Re-point both at theme tokens so they flip with the theme. `--paper-2` IS #f4f6f8 in light theme, so light rendering is byte-identical to before. Declared on `.table` at the same (0,1,0) specificity as Bootstrap's rule and loaded after it, so it wins; .myaccount-grid__table's own --blue-tint override is (0,2,0) and still wins here. */ .table { --bs-table-hover-bg: var(--paper-2); --bs-table-hover-color: var(--ink); } /* R100 (2026-08-21): `.entry-title` (+ its `span`) and `.max-w-500` DELETED. Both are leftovers from the pre-modernization hand-maintained skin.css - `entry-title` is a WordPress-era name and `max-w-500` a one-off px cap outside the token scale. Zero writers across every .cshtml / .ascx / .js / .cs in all three projects, dbo.HtmlText on DEV, and 24 rendered page loads. Page titles come from `.page-hero__title` / `.co-sec-head` / `.home-sec-head`. */ /* Focus system (theme v3): pointer clicks stay ringless, but keyboard focus ALWAYS gets a visible 2px action-blue outline with 2px offset (--focus flips to the on-dark accent in dark theme). Composite inputs shift their border via :focus-within (see _components.scss). POLISH S6b, P3-25 (2026-08-20): both `!important`s below are LOAD-BEARING, and the reason is that `:not(:focus-visible)` buys no specificity - `:not()` counts as its argument, so `input:focus:not(:focus-visible)` is only (0,2,1) and `.btn:focus:not(:focus-visible)` (0,3,0). Two authored rules set a VISIBLE ring on a plain `:focus` and both outrank them: - `.dnnForm.dnnLogin .dnnLoginService input[type="text"]:focus { box-shadow: var(--focus-ring) }` (_chrome.scss, (0,3,1)) - a mouse click into the sign-in modal's field would paint the ring. - `.qty-stepper .qty-btn:focus { box-shadow: inset var(--focus-ring) }` (_cart.scss) - a mouse click on the PDP / cart quantity +/- would paint an inset ring. Fixing the specificity "properly" here would mean re-stating this policy at or above every such component rule, i.e. duplicating the policy per component - which is the thing one shared rule exists to avoid. So it keeps the !important, with the competition named. */ input:focus:not(:focus-visible), button:focus:not(:focus-visible), textarea:focus:not(:focus-visible), .btn:focus:not(:focus-visible) { outline: none !important; box-shadow: unset !important; } /* POLISH S6b, P3-25 (2026-08-20): `!important` is LOAD-BEARING and it is DNN core that makes it so. MEASURED with CDP on the focused skip link: `default.css` declares `a, a:visited { outline: initial }` AND `a:hover, a:focus, a:active { outline: initial }`, and each selector in those lists counts on its own, so `a:focus` is (0,1,1) against this rule's (0,1,0). Without !important the keyboard ring is `initial` on EVERY anchor - the one indicator the whole focus system exists to guarantee. Cannot be fixed by specificity without re-stating the ring for every element type; a bare `:focus-visible` is the point. Same family as [[a-visited-beats-a-bare-class-and-getcomputedstyle-lies]]. */ :focus-visible { outline: 2px solid var(--focus) !important; outline-offset: 2px; } input:focus:required:invalid, textarea:focus:required:invalid { border-color: var(--error); } input:required:valid, textarea:required:valid { border-color: var(--ok); } input.form-control { /* border: 1px solid var(--grey); border-radius: 5px;*/ } input.form-control::placeholder { color: var(--ink-2); font-weight: 400; } /* ===================================================================== UI BATCH 2026-08-27-E ITEM 1 (Juan): EVERY CHECKBOX ON THE ESTATE IS A TOGGLE SWITCH. "Anywhere we show a checkbox in the skin or modules (MVC or WebForms) change it to a toggle button instead. Make sure all toggles (even ones that already exist) are appropriately sized and spaced to make tapping with a finger on mobile easy and accurate." THIS IS DONE IN CSS, IN ONE PLACE, AND DELIBERATELY NOT IN MARKUP. There are ~45 checkbox render sites across the MVC views, the WebForms authentication controls and the DNN module Settings views, plus every facet row search.js BUILDS at runtime (_HydrateFacetOverflow) - a markup sweep would have to touch all of them and would still miss the ones JavaScript creates. The control stays a real `input[type="checkbox"]`, so every `:checked` read, every `.filter-checkbox` handler, every KO binding and every screen-reader announcement is unchanged; only its painting is. Four of the render sites ALREADY carried `role="switch"` and Bootstrap's `.form-switch` (ContentManager's live-preview toggle, MyAccount's "only mine" quotes filter and its approvals filter, and the compare sheet's "differences only"). They are not special-cased: this rule out-specifies `.form-switch .form-check-input` (0,2,1 against 0,2,0) so all of them land on ONE size instead of the 32x16 the ContentManager one used to hand-set - which is the second half of Juan's ask, since 16px of height is not a finger target. SIZE: 44x26 with a 20px thumb. 44px is the WCAG 2.5.5 (Enhanced) target width and the figure this estate already uses for a touch row; the height is carried past the 24px WCAG 2.2 minimum by the control itself rather than by a hitTarget overlay, so the switch IS its own target. Vertical spacing is the row's - the facet rail's `.form-check` is a 44px flex row (_filter.scss), and the `gap` below is what separates a switch from its label everywhere else. `appearance: none` is what lets the track and thumb be drawn at all, and it makes `accent-color` inert - so the local `accent-color` declarations that used to tint the UA control are dead and were removed with the size overrides they sat beside (_filter.scss, _components.scss). ===================================================================== */ input[type=checkbox], input[type=checkbox].form-check-input { appearance: none; -webkit-appearance: none; box-sizing: border-box; position: relative; flex: 0 0 auto; float: none; width: 44px; height: 26px; min-width: 44px; margin: 0; padding: 0; border: 1px solid var(--input); border-radius: 999px; background-color: var(--rule); background-image: none; vertical-align: middle; cursor: pointer; transition: background-color 0.15s ease, border-color 0.15s ease; } /* The thumb. A pseudo-element is never an event target, so the click still lands on the input and nothing that reads `event.target` changes. */ input[type=checkbox]::after, input[type=checkbox].form-check-input::after { content: ""; position: absolute; top: 50%; left: 2px; width: 20px; height: 20px; border-radius: 50%; background-color: var(--field-ink); box-shadow: 0 1px 2px rgba(0, 0, 0, 0.3); transform: translateY(-50%); transition: left 0.15s ease; } /* Selection controls carry COLAMCO blue (status/action separation: CTA green is reserved for purchase actions, form state is blue). `background-image: none` is not decoration: Bootstrap paints its tick (and, for .form-switch, its own thumb) as a background-image on the checked state, and both would print underneath the thumb drawn above. */ input[type=checkbox]:checked, input[type=checkbox].form-check-input:checked { background-color: var(--cta); border-color: var(--cta); background-image: none; } input[type=checkbox]:checked::after, input[type=checkbox].form-check-input:checked::after { left: 20px; } input[type=checkbox]:disabled, input[type=checkbox].form-check-input:disabled { opacity: 0.55; cursor: not-allowed; } @media (prefers-reduced-motion: reduce) { input[type=checkbox], input[type=checkbox].form-check-input, input[type=checkbox]::after, input[type=checkbox].form-check-input::after { transition: none; } } /* Bootstrap indents `.form-check` by 1.5em and pulls the control back into that gutter with a negative margin, which is sized for a 1em box - a 44px switch would hang outside the row. Any .form-check holding a checkbox is laid out as a plain flex row instead; the `:has()` arm leaves RADIO rows (checkout's address / card / shipping options, the star rating) on Bootstrap's own float layout, which they still want. Specificity: `:has()` takes the specificity of its most specific argument, so this is (0,2,1) and beats both `.form-check` (0,1,0) and `.form-check.form-switch` (0,2,0). */ .form-check:has(> input[type=checkbox]) { display: flex; align-items: center; gap: 0.625rem; padding-left: 0; } /* SESSION 3 ITEM 4 (Juan, 2026-08-16): THE SITEWIDE RADIO ORNAMENT IS DELETED AT SOURCE. This block used to give EVERY input[type="radio"] an ::after that drew a 14px circle offset over the control (top:-2px left:-1px, blue when checked) - a hand-rolled REPLACEMENT for the platform radio. Nothing on the estate wants that any more: every radio either restores the platform control outright (`appearance: auto; -webkit-appearance: radio` on checkout's .co-opt, .co-shipopt and .cps-opt), draws its own dot (.warranty-plan__dot), or is visually hidden (.star-rating-radio). So the ornament only ever painted a second blob beside a real radio - Juan's "doubled up" - and two pages had already grown a local `content: none` to kill it (_cart.scss's .checkout-page block and _product.scss's .warranty-plan__dot). Both are deleted with this: the root cause was ONE inherited ornament, and a third local override would have been the third page paying for it. `accent-color` is what replaces it. It is the platform's own tinting hook, so the control stays a real radio - focus ring, arrow-key group navigation, checked state and forced-colors all come from the browser - and it simply paints COLAMCO blue instead of the UA default. Verified against the whole radio estate rather than the two pages that complained: checkout (shipping, payment, delivery options), the add-warranty sheet, the PDP plan rows, the write-a-review stars, My Account and the listing filters. */ input[type=radio] { accent-color: var(--cta); } /* 2026-08-09: this was "\f107" (fa-angle-down) and drew NOTHING - the header's My Account and Contact Us menus were the only two top-level menus with no chevron, while the mega menu's own .mm-caret (a CSS border triangle) rendered fine beside them. The shipped FontAwesome webfont is a hand-built ~73-glyph subset (Tools/FontAwesomeSubset) and U+F107 is not in its cmap - verified against fa-solid-900.woff2, not inferred from the class list, because all.subset.css DOES still define .fa-angle-left/.fa-angle-right whose glyphs are equally absent. U+F078 (fa-chevron-down) IS in the font, is the same affordance, and matches the .fa-chevron-* family used elsewhere in the skin. The reserved 12px box was always there, so nothing shifts - the glyph simply appears. */ .dropdown-toggle::after { content: "\f078"; font-family: "Font Awesome 6 Free"; font-weight: 600; /* .72rem lands the chevron at ~11.5px, the same visual weight as the mega menu's 9px .mm-caret two links away; 1rem read as a second piece of copy next to the label. */ font-size: 0.72rem; vertical-align: baseline; border: unset; margin-left: 0.5rem; } a { color: var(--blue-link); text-decoration: none; transition: var(--transition); } a:visited { color: var(--blue-link); text-decoration: none; } a:hover { color: var(--textcolor); } a.btn:visited { color: var(--bs-btn-color); } a.btn:hover, a.btn:visited:hover { color: var(--bs-btn-hover-color); } a.dropdown-item:visited, a.dropdown-item:visited:hover, a.nav-item:visited, a.nav-item:visited:hover { color: var(--bs-dropdown-link-color); } /* R45 item 5: shared reset for the sitewide javascript:void(0) anchor-as-action-trigger anchors converted to