/* ============================================================================ TYPEFACE REPAIR — RETIRED, and kept as a note because the reasoning is worth more than the rule was. ============================================================================ CoreUI hard-set a legacy typeface on .form-control, .btn-info and .btn-info2, and only _layout_fullscreen.njk loaded CoreUI, so the damage was confined to the eight auth views and highly visible on them: every login field and the "Log in" button itself. This block undid it with font-family: inherit. The auth layout now loads bootstrap.min.css instead, whose reboot already does `button,input,optgroup,select,textarea { font-family:inherit }`. There is nothing left to repair, so the rule went. Measured on the login screen before and after removing it: Public Sans at 14px either way. ==========================================================================*/ /* ============================================================================ P4-T2 — BUTTON GEOMETRY. ============================================================================ The colour layer for buttons was already done. This adds the SHAPE, which Bootstrap was still supplying: padding .375rem .75rem, font-size 1rem, weight 400. The design is 13px / 600 and roomier. >> WHERE THESE NUMBERS COME FROM. Not from grepping the prototype — that approach had 18 of its claims refuted on review. The prototype ships a support.js runtime and HYDRATES into a working app, so its buttons were rendered across 23 screens and read with getComputedStyle: node .specs-local/tools/design-measure.js buttons 103 buttons -> 29 distinct looks. The design is hand-tuned per screen, so these are measured PLURALITIES applied uniformly. That is deliberate: a token system exists to normalise exactly this kind of drift. >> NO HEIGHT IS DECLARED, AND THAT IS NOT AN OVERSIGHT. Measured button heights vary WITHIN a single look (31px and 33px for the same style), which proves height is a consequence of padding + line-height rather than a designed value. Authoring a fixed height would be inventing a constraint the design does not have, and would break any button whose label wraps. >> VENDOR DOM IS EXCLUDED. ui-select emits "btn btn-default form-control ui-select-toggle" on ONE node from vendors/ui-select/select.min.js, so it is simultaneously a button and a field. It is a FIELD, and button geometry is the wrong answer for all of them. main.css:205 already owns .ui-select-toggle.btn but loads EARLIER than this file, so without the :not() below we would silently take it over. Those controls belong to P4-T4b. >> VARIANT MAPPING, recorded because half of it was already decided in silence: .btn-primary -> accent solid (226 uses) .btn-info -> accent solid (108 uses) — IDENTICAL to .btn-primary in this file since before P4. Not a decision made here, but one that had never been written down. Consequence: ~47% of the app's 839 buttons render accent green, against roughly 20-32% in the design. Closing that needs markup edits to encode a semantic the app never carried, so it is a RECORDED PARITY GAP, not a carve-out. See tasks.md. .btn-secondary -> outlined (190 uses) .btn-danger -> destructive (135 uses) .btn-success -> accent solid (23 uses). NOTE: --al-success-solid and --al-accent-primary both resolve to #157a52, so this is already the accent look. An earlier review called the hover a "hue jump"; it is not — hover goes to #0f5f3f, the same rung .btn-primary uses. The token NAMES cross families, which is a maintainability wart with zero pixel impact. Deliberately not chased in a reskin. .btn-warning -> warning solid (7 uses) ==========================================================================*/ /* `:not(.k-icon-button):not(.k-button-icon)` spares icon-only Kendo buttons. Grid row-action buttons render `.btn.btn-sm.btn- …k-icon-button` with a fixed square vendor width; the padding + font-size here (border-box) shrank that square until the 16px glyph clipped to a ~2px sliver (P4-T2 regression, reported on the customer-notes + discounts grids). Excluding them lets Kendo keep its own square geometry; the `.btn-` chip colours below still apply, so the red/ green/blue chips are unchanged — only the glyph comes back. The guard is added to EVERY geometry tier below to keep the specificity balance the comment at .btn-sm describes. */ /* [PASS6-F13 / recipe #8] The confirm-dialog buttons join this rule rather than keeping their own copy of it. Recipe #8 ordered the bespoke confirm-dialog and save-bar systems "folded into the one .btn set"; the colours were folded in an earlier pass but the GEOMETRY never was, so 180 instances across all three surfaces stayed padding-sized at 41.5px, and 61px on the five where the label wrapped. They keep their own class (44 files emit `.al-confirm-btn`, and this is a reskin — chrome, not markup), but they no longer keep their own geometry. */ .btn:not(.ui-select-toggle):not(.ui-select-match-item):not(.k-icon-button):not(.k-button-icon), .al-confirm .modal-footer .al-confirm-btn { /* [PASS6-F12] These three values were MEASURED off the old app, not chosen. The recipe was silent on button type size, so tokens.css filled the gap with body default and the drift became invisible. Recipe amendments 12/13/14 close it. */ padding: 0 16px; /* [12] zero vertical — height does the sizing, not padding */ font-size: var( --al-fs-md ); /* [12] 14px, Jeff's call. An EXISTING rung: the recipe demo's 13.5px was its own house body size, never a button decision, and minting a half-pixel token for it would start a second type scale. */ font-weight: var(--al-fw-semibold); line-height: 1; /* [PASS6-F13] Radius belongs HERE, stated, not inherited from Bootstrap's own .btn. Found this the hard way: F13 removed `border-radius` from the confirm rule on the assumption that joining this rule supplied it, and all 180 confirm buttons went square. They were living off Bootstrap's default the whole time. The recipe locks 8px for all kinds, all sizes, all states — so say so. */ border-radius: var(--al-radius-md); white-space: nowrap; /* [14] locked — and it is what makes `height` safe below */ /* [PASS6-F12 / amendment 14] `height`, NOT `min-height`. The comment this replaces defended min-height so a wrapping label could grow; the recipe locks `white-space: nowrap` precisely so that case cannot arise. min-height is the gap five tiers escaped through, rendering at 39/40/44/47/48px. */ height: var(--al-h-control); display: inline-flex; align-items: center; justify-content: center; gap: 6px; /* icon+label spacing now that we're a flex container */ } /* >> THE :not() CHAIN MUST MATCH THE BASE RULE'S LENGTH. << `.btn:not(.ui-select-toggle):not(.ui-select-match-item)` is specificity (0,3,0). A tier written as `.btn-sm:not(.ui-select-toggle)` is only (0,2,0), so the BASE rule wins and every small button silently renders at default size. Caught by the gate on the first run: .btn-sm reported padding 4px 8px -> 9px 16px instead of the small value. Equal specificity plus later source order is what actually makes these tiers work. */ .btn-sm:not(.ui-select-toggle):not(.ui-select-match-item):not(.k-icon-button):not(.k-button-icon), .btn-group-sm > .btn:not(.ui-select-toggle):not(.ui-select-match-item):not(.k-icon-button):not(.k-button-icon) { padding: 0 11px; /* [13] */ /* [PASS6-F12] 13px, one rung below the 14px default. The recipe demo shows 12.5px on the sm tier, but 12.5 is not a rung in tokens.css and minting one would be the exact half-pixel mistake amendment 12 exists to avoid. Flagged to Jeff. */ font-size: var(--al-fs-base); height: var(--al-h-control-sm); /* [14][19] hard height, now a token */ } /* The page-header CTA tier — measured 10px 18px / 700, 5 instances, the single largest cluster. --al-fw-bold's own note ("primary buttons DRIFT 600/700") predicted this split; measuring 103 rendered buttons confirmed it. */ .btn-lg:not(.ui-select-toggle):not(.ui-select-match-item):not(.k-icon-button):not(.k-button-icon), .btn-group-lg > .btn:not(.ui-select-toggle):not(.ui-select-match-item):not(.k-icon-button):not(.k-button-icon) { padding: 0 22px; /* [13] */ font-size: var(--al-fs-15); /* [12] 15px, one rung above the default */ /* [PASS6-F12] 600, not bold. The recipe locks weight 600 across ALL kinds and ALL sizes; the 700 this replaces was measured off 5 page-header CTAs in the old app, which is the same measure-don't-decide pattern amendment 12 closes. */ font-weight: var(--al-fw-semibold); height: var(--al-h-control-lg); /* [14] */ } /* [PASS7-F20] VENDOR FALLBACK INK — stated BEFORE the variant blocks on purpose. ============================================================================= Kendo renders plenty of buttons carrying no variant of its own (solid-base, flat-base, outline-base), and F17 gave them a token-driven label colour because their stock #212529 / #333 exist nowhere in tokens.css. That was right. What was wrong was WHERE it sat: 1100 lines further down, after every .btn-* variant. An element can wear both systems at once. On /admin/config/sell/price_groups the row actions are literally class="btn btn-sm btn-secondary k-button k-button-solid-base" and .k-button-solid-base, .btn-secondary and .btn-danger are ALL (0,1,0). Equal specificity is broken by source order, so the later rule won and this fallback repainted three buttons that had already been told what colour to be: emerald "Edit"/"Duplicate" and a white-on-red "Delete" all came out #3d4550. Moving it above the variants closes the whole class of collision by position, with NO change in specificity. Raising specificity instead — the obvious :not(.btn-primary):not(.btn-secondary)… chain — would have introduced a worse bug: it lifts this rule to (0,7,0), where it would beat its OWN hover at (0,2,0) and freeze the label colour on hover. This file already states that contract for .btn:disabled a few blocks down: "Stated before the variant blocks so a variant can still override if one ever genuinely needs to, rather than winning by accident of source order." A fallback belongs first; that is what makes it a fallback rather than an override. */ .k-button-solid-base, .k-button-flat-base, .k-button-outline-base { color: var(--al-text-body); } .btn-primary { color: var(--al-accent-on-primary); background-color: var(--al-accent-primary); border-color: var(--al-accent-primary); } /* ============================================================================ [F4] INTERACTION STATE LAYER — one overlay for every button. ============================================================================ Jeff's call: instead of a named hover and press colour per button kind, a translucent film fades in over whatever colour the button already is (8% hover, 12% press). One rule covers both states for every button in every colour, so a new button kind needs no new tokens and cannot disagree with its neighbours. That disagreement is what he spotted on the POS queue screen. Implemented as ::after rather than a background swap so it layers over ANY fill (solid, outline, white) without knowing what that fill is, and sits under the label. `isolation:isolate` keeps the film inside the button's own stacking context. Buttons that carry their own ::after are excluded above. */ .btn::after { content: ''; position: absolute; inset: 0; /* UNDER THE LABEL. The comment above has always said so and nothing implemented it: generated content paints after in-flow content, so the film was over the label the whole time. It went unnoticed because --al-state-layer is the label's own colour, so the film was veiling white with white. isolation:isolate above is what makes a negative z-index safe -- it keeps the film inside the button. */ z-index: -1; border-radius: inherit; background: var(--al-state-layer); opacity: 0; transition: opacity var(--al-dur-base) var(--al-ease-standard); pointer-events: none; } /* A SELECT IS NOT A BUTTON, however it is marked up. ui-select emits .btn on BOTH the toggle and the clear affordance inside it, so the button film applied to both: the control darkened on hover, and hovering the clear painted a grey slab across the right end of the field, square-cornered against the field's own radius and overlapping the caret. The recipe's select answers a hover on its EDGE and leaves its fill alone. SCOPED TO THE CONTAINER, not to the toggle. It was written for the toggle alone, and the clear had the identical bug sitting next to it for exactly as long. Anything ui-select marks .btn is part of a field, not a button. Worth knowing how these survive: the film is painted by a pseudo-element, so comparing the element's own background-color reports white in every state and cannot see it. */ .ui-select-container .btn::after { content: none; } /* THE CLEAR IS A CLEAR, not a link. ui-select gives it .btn-link, whose bootstrap blue never showed because the glyph is a child with its own colour -- so the anchor was carrying an off-brand colour that happened to be invisible. It is set anyway: an inert wrong value becomes a visible wrong value the moment someone puts a label in it. The mark itself was at FULL INK, the same strength as the value it sits beside, and competed with it. The recipe's clear is muted and strengthens under the pointer, which is the whole difference between "you may remove this" and "this is part of the value". */ .ui-select-container .btn-link { color: var(--al-sys-color-text-muted); } .ui-select-container .btn-link > .cil, .ui-select-container .btn-link > i { color: var(--al-sys-color-text-muted); transition: color var(--al-dur-base) var(--al-ease-standard); } .ui-select-container .btn-link:hover > .cil, .ui-select-container .btn-link:hover > i { color: var(--al-sys-color-text-primary); } /* A SINGLE SELECT'S VALUE IS ONE LINE. ui-select already gives .ui-select-match-text both `overflow: hidden` and `text-overflow: ellipsis`, and then leaves `white-space: normal`, which stops the ellipsis working: a value with a space in it breaks at the space instead, and the second line renders 3.8px below the control's bottom border. "Star TSP100 Cash Drawer" showed "Drawer" cut in half. A value with nothing to break at truncated correctly, so only some of them looked broken and it read as random rather than as one missing declaration. Measured on ALLM-7255 terminal Hardware. Excludes the multiple variant, whose match items are chips and are supposed to wrap. */ .ui-select-container:not(.ui-select-multiple) .ui-select-match-text { white-space: nowrap; } .btn { position: relative; isolation: isolate; } /* THE FILM'S COLOUR IS DECIDED BY THE GROUND IT SITS ON, which is the one thing that makes a single rule work across every button in every colour. OVER AN ACCENT FILL IT DARKENS. The fill is a known colour carrying a known label, and lightening it eats that label's contrast -- the button gets paler exactly as the white words on it need the ground to hold. This used to lighten, and a primary button went FURTHER toward white the harder you pressed it. OVER THE SURFACE IT IS THE INTENT. An outline button's ground is the canvas, so a neutral darkening film greys it out; its own intent deepens it into its own family instead, which is why a pressed Delete stays red rather than going slate. The two alphas differ for the same reason: over a fill the label only gains contrast as the ground deepens, over the surface the film moves the ground TOWARD the label, so the on-surface press has a ceiling the on-fill one does not. */ .btn-primary, .btn-danger, .btn-success, .btn-info, .btn-warning { --al-state-layer: var(--al-sys-color-veil-on-accent); --al-state-hover: var(--al-sys-state-hover-opacity-on-fill); --al-state-press: var(--al-sys-state-press-opacity-on-fill); } .btn-secondary, .al-confirm .modal-footer .al-confirm-cancel { --al-state-layer: var(--al-accent-primary); --al-state-hover: var(--al-sys-state-hover-opacity-on-surface); --al-state-press: var(--al-sys-state-press-opacity-on-surface); } .btn:hover:not(:disabled):not(.disabled)::after { opacity: var(--al-state-hover); } .btn:active:not(:disabled):not(.disabled)::after { opacity: var(--al-state-press); } /* ============================================================================ THE PRESS. Held down, .btn deepened its film and did nothing else, and the app's own buttons -- Unlock, Delete, Save, Discard, the carets, the confirm buttons -- did nothing at all: hover and press were the same pixels. Two separate gaps, one state. THE SCALE IS THE HALF THAT MAKES IT PHYSICAL. The recipe's words: "colour alone under-sells a press, and it reads on every fill." It is also the half that works on a button whose press is otherwise invisible, which is most of the list below. Transform costs no layout, so nothing around the button moves. EVERY SELECTOR CARRIES ITS OWN SUFFIX and the lists are not folded. A pseudo-class written once after a comma-separated list binds to the LAST selector only, so the other fifteen buttons took the pressed transform and the pressed film AT REST -- permanently small, under a permanent veil. It looked deliberate enough to miss by eye; Playwright caught it refusing to click a login button that was no longer where its layout box said it was. ============================================================================ */ .btn:active:not(:disabled):not(.disabled), .al-user-action:active:not(:disabled):not(.disabled), .al-user-secondary:active:not(:disabled):not(.disabled), .al-cfg-add:active:not(:disabled):not(.disabled), .al-cfg-addsq:active:not(:disabled):not(.disabled), .al-cfg-delete:active:not(:disabled):not(.disabled), .al-cfg-new:active:not(:disabled):not(.disabled), .al-cfg-iconbtn:active:not(:disabled):not(.disabled), .al-cfg-editbtn:active:not(:disabled):not(.disabled), .al-curbside__btn:active:not(:disabled):not(.disabled), .al-login__btn:active:not(:disabled):not(.disabled), .al-confirm .modal-footer .al-confirm-btn:active:not(:disabled):not(.disabled) { transform: scale(var(--al-sys-state-press-scale)); } /* The film, for the buttons that never had one. Their HOVER is a background swap and stays exactly as it is -- this is press-only, so the press reads as a deeper version of the hover rather than a second answer competing with it. */ .al-user-action, .al-user-secondary, .al-cfg-add, .al-cfg-addsq, .al-cfg-delete, .al-cfg-new, .al-cfg-iconbtn, .al-cfg-editbtn, .al-curbside__btn, .al-login__btn, .al-confirm .modal-footer .al-confirm-btn { position: relative; isolation: isolate; } .al-user-action::after, .al-user-secondary::after, .al-cfg-add::after, .al-cfg-addsq::after, .al-cfg-delete::after, .al-cfg-new::after, .al-cfg-iconbtn::after, .al-cfg-editbtn::after, .al-curbside__btn::after, .al-login__btn::after, .al-confirm .modal-footer .al-confirm-btn::after { content: ''; position: absolute; inset: 0; z-index: -1; border-radius: inherit; background: var(--al-state-layer); opacity: 0; transition: opacity var(--al-dur-base) var(--al-ease-standard); pointer-events: none; } .al-user-action:active:not(:disabled):not(.disabled)::after, .al-user-secondary:active:not(:disabled):not(.disabled)::after, .al-cfg-add:active:not(:disabled):not(.disabled)::after, .al-cfg-addsq:active:not(:disabled):not(.disabled)::after, .al-cfg-delete:active:not(:disabled):not(.disabled)::after, .al-cfg-new:active:not(:disabled):not(.disabled)::after, .al-cfg-iconbtn:active:not(:disabled):not(.disabled)::after, .al-cfg-editbtn:active:not(:disabled):not(.disabled)::after, .al-curbside__btn:active:not(:disabled):not(.disabled)::after, .al-login__btn:active:not(:disabled):not(.disabled)::after, .al-confirm .modal-footer .al-confirm-btn:active:not(:disabled):not(.disabled)::after { opacity: var(--al-state-press); } /* The film takes the button's OWN meaning, so a press deepens it into its own colour instead of greying it. Without this a delete button pressed toward ink and stopped reading as destructive at the moment it mattered most. */ .al-cfg-delete, .al-user-action--danger { --al-state-layer: var(--al-danger-solid); } .al-user-secondary, .al-cfg-add, .al-cfg-addsq, .al-cfg-new, .al-curbside__btn, .al-login__btn { --al-state-layer: var(--al-accent-primary); } /* ============================================================================ [PASS6-F15 / amendment 15(b)] THE STANDALONE ICON BUTTON. Amendment 15 split a family that was never one thing. Of 78 captured icon-only buttons, 49 were dropdown carets and numeric spinners sized by their HOST control and 6 were Google Maps chrome — neither is a button, and both are now excluded from the taxonomy outright. Jeff caught that before a blanket square rule shipped: "it depends on the context. If some of those carets are inside of dropdowns, does that still work?" They are, and it does not — a 36x36 square cannot live inside a 36px input. What is left is the real icon button: square at the tiers already locked, radius 8, transparent fill, muted glyph strengthening on hover. Defined on the selectors that EXIST rather than as a fresh .al-icon-btn nobody consumes. That mistake is already in this codebase once — .al-segmented was built correctly, wired to nothing, and sat unused (see F16). ============================================================================ */ .al-cfg-iconbtn, .al-cfg-editbtn { display: inline-flex; align-items: center; justify-content: center; flex: none; position: relative; border: 1px solid transparent; border-radius: var(--al-radius-md); background: transparent; color: var(--al-text-muted); cursor: pointer; } .al-cfg-iconbtn { width: var(--al-h-control); /* 36 — was a bespoke 34, same as .al-cfg-new was */ height: var(--al-h-control); } .al-cfg-editbtn { width: var(--al-h-control-sm); /* 28 — a row-level affordance */ height: var(--al-h-control-sm); } /* Hit target keyed to the RENDERED BOX, not the tier — Jeff's rule: "you only really need the larger hit target if it is a smaller icon like the X." A 28px glyph button is a 28px target without this; the expansion is invisible and costs no layout. */ .al-cfg-iconbtn::before, .al-cfg-editbtn::before { content: ''; position: absolute; left: 50%; top: 50%; width: max(100%, 44px); height: max(100%, 44px); transform: translate(-50%, -50%); } /* [PASS6-F14 / amendment 17] Disabled is ONE blanket rule, not a per-variant table. The recipe locks `opacity:.5` and nothing else, deliberately: a faded button still reads as the KIND of button it is. The per-variant swap this replaces repainted .btn-secondary's text and border to grey, so 12 disabled secondaries stopped looking like secondaries at all — an invented rule the recipe never asked for. Stated before the variant blocks so a variant can still override if one ever genuinely needs to, rather than winning by accident of source order. */ .btn:disabled, .btn.disabled { opacity: 0.5; pointer-events: none; } /* [F4] the per-kind hover colours below are GONE — the state layer replaces them. Only the border/colour parts that are not a hover fill remain. */ .btn-primary:focus, .btn-primary.focus { /* [PASS7-F24] The resting colours are RESTATED here, exactly as F19 had to do for disabled. Bootstrap ships `.btn-{v}.focus,.btn-{v}:focus{{color;background-color; border-color;box-shadow}}` at (0,2,0). This block used to declare box-shadow ALONE, so the three colours fell through to our resting rule at (0,1,0) and Bootstrap outranked it — every focused button repainted itself vendor blue/grey and held until blur. Focus is a ring, not a recolour. Same specificity, so we win on load order. */ color: var(--al-accent-on-primary); background-color: var(--al-accent-primary); border-color: var(--al-accent-primary); box-shadow: none; } /* [PASS7-F19] RESTORED. The comment that stood here said the removal was "harmless" because "the blanket rule does that job now by not changing colour at all", and that was simply wrong: the blanket `.btn:disabled` rule sets `opacity` and `pointer-events` and NO COLOUR, so it cannot hold anything off. Bootstrap ships `.btn-primary:disabled{background-color:#007bff}` at (0,2,0); our resting `.btn-primary` is (0,1,0). With this rule deleted, Bootstrap outranked us and every disabled primary in Admin repainted itself Bootstrap blue — measured live, 15/15, with our opacity:.5 sitting correctly on top of the wrong colour. F14 removed the protection and wrote a comment claiming the opposite. The lesson is not "restore the old rule": it is that a per-variant disabled block must RESTATE THE RESTING COLOURS (what amendment 17 actually asks for) rather than swap in new ones (what the pre-F14 secondary rule wrongly did). Same values as resting, stated at (0,2,0) so Bootstrap cannot reach past them. */ .btn-primary.disabled, .btn-primary:disabled { color: var(--al-accent-on-primary); background-color: var(--al-accent-primary); border-color: var(--al-accent-primary); } /* [PASS6-F14 / amendment 16] These seven blocks pin the RESTING fill on :hover and :active, so the state layer is the only thing that moves on either. >> A PRE-EXISTING BUG, FOUND HERE, NOT CAUSED HERE. << Primary buttons were turning BOOTSTRAP BLUE on hover in the live product: rest rgb(21,122,82) -> hover rgb(0,105,217). Confirmed by measuring with this change stashed out, so it is not mine. A previous pass removed "the per-kind hover colours" on the grounds that the state layer replaced them, without checking what would win once ours were gone — and vendored bootstrap.min.css has .btn-primary:hover{background:#0069d9} at higher specificity than our .btn-primary. The layer was faithfully painting 8% black over blue. Nothing caught it because THE GALLERY ONLY CAPTURES RESTING STATE. An audit instrument that never hovers cannot see a hover bug. The rest of the note still applies: these cannot simply be deleted. They do two jobs — neutralise the vendor, and (previously) darken the fill. I deleted them for the second reason and only then discovered the first. */ /* superseded note: These seven :active blocks now pin the RESTING fill rather than the darker hover rung, so the state layer is the only thing that moves on press. They cannot simply be deleted, which I found out by deleting them: they are doing TWO jobs, and I had only noticed one. Besides darkening the fill, they suppress Bootstrap's own vendored `.btn-primary:…:active{background:#0062cc}`. With them gone, pressing a primary turned it BLUE. Keep the selector, neutralise the vendor, let the layer do the work. */ .btn-primary:not(:disabled):not(.disabled):hover, .btn-primary:not(:disabled):not(.disabled):active, .btn-primary:not(:disabled):not(.disabled).active, .show > .btn-primary.dropdown-toggle { color: var(--al-accent-on-primary); background-color: var(--al-accent-primary); border-color: var(--al-accent-primary); } .btn-primary:not(:disabled):not(.disabled):active:focus, .btn-primary:not(:disabled):not(.disabled).active:focus, .show > .btn-primary.dropdown-toggle:focus { box-shadow: none; } /* SECONDARY = emerald outline (Jeff's pick from the button lab, 2026-07-30): white fill + emerald border/text — the outline partner to the solid primary. */ .btn-secondary { color: var(--al-accent-primary); background-color: var(--al-surface-card); border: 1px solid var(--al-accent-primary); } .btn-secondary:focus, .btn-secondary.focus { /* [PASS7-F24] The resting colours are RESTATED here, exactly as F19 had to do for disabled. Bootstrap ships `.btn-{v}.focus,.btn-{v}:focus{{color;background-color; border-color;box-shadow}}` at (0,2,0). This block used to declare box-shadow ALONE, so the three colours fell through to our resting rule at (0,1,0) and Bootstrap outranked it — every focused button repainted itself vendor blue/grey and held until blur. Focus is a ring, not a recolour. Same specificity, so we win on load order. */ color: var(--al-accent-primary); background-color: var(--al-surface-card); border-color: var(--al-accent-primary); box-shadow: none; } /* [PASS7-F19] The F14 note here was half right and half wrong, and the wrong half shipped a bug. Right: the OLD per-variant swap repainted the text muted-grey and the border input-grey, stripping the emerald outline off every disabled secondary, so deleting it was correct. Wrong: "the blanket opacity:.5 above now carries it, and the button keeps its own colours at half strength." It does not. The blanket rule sets no colour, and Bootstrap's `.btn-secondary:disabled{background-color:#6c757d}` is (0,2,0) against our (0,1,0) resting rule — so disabled secondaries went SOLID BOOTSTRAP GREY, which is further from a secondary than the grey outline ever was. What amendment 17 asks for is the resting appearance at half strength. That needs the resting colours RESTATED at the disabled specificity, which is this rule. It is not a revival of the old swap: every value below is identical to the resting block above. */ .btn-secondary.disabled, .btn-secondary:disabled { color: var(--al-accent-primary); background-color: var(--al-surface-card); border-color: var(--al-accent-primary); } .btn-secondary:not(:disabled):not(.disabled):hover, .btn-secondary:not(:disabled):not(.disabled):active, .btn-secondary:not(:disabled):not(.disabled).active, .show > .btn-secondary.dropdown-toggle { color: var(--al-accent-primary); background-color: var(--al-accent-primary-tint); border-color: var(--al-accent-primary); } .btn-secondary:not(:disabled):not(.disabled):active:focus, .btn-secondary:not(:disabled):not(.disabled).active:focus, .show > .btn-secondary.dropdown-toggle:focus { box-shadow: none; } .btn-success { color: var(--al-accent-on-primary); background-color: var(--al-success-solid); border-color: var(--al-success-solid); } .btn-success:focus, .btn-success.focus { color: var(--al-accent-on-primary); background-color: var(--al-success-solid); border-color: var(--al-success-solid); box-shadow: none; } .btn-success.disabled, .btn-success:disabled { color: var(--al-accent-on-primary); /* [PASS7-F19] was --al-accent-primary while the resting block above uses --al-success-solid. Both resolve to #157a52 today, so nothing looked wrong, but a disabled success button was reading its colour from a DIFFERENT ROLE than the same button at rest. Re-theme success away from emerald and only the disabled state would stay green. Invisible today, wrong by construction, and exactly the kind of thing the token layer exists to prevent — so it is conformed rather than left. */ background-color: var(--al-success-solid); border-color: var(--al-success-solid); } .btn-success:not(:disabled):not(.disabled):hover, .btn-success:not(:disabled):not(.disabled):active, .btn-success:not(:disabled):not(.disabled).active, .show > .btn-success.dropdown-toggle { color: var(--al-accent-on-primary); background-color: var(--al-accent-primary); border-color: var(--al-accent-primary); } .btn-success:not(:disabled):not(.disabled):active:focus, .btn-success:not(:disabled):not(.disabled).active:focus, .show > .btn-success.dropdown-toggle:focus { box-shadow: none; } .btn-info { color: var(--al-accent-on-primary); background-color: var(--al-accent-primary); border-color: var(--al-accent-primary); } .btn-info:focus, .btn-info.focus { color: var(--al-accent-on-primary); background-color: var(--al-accent-primary); border-color: var(--al-accent-primary); box-shadow: none; } .btn-info.disabled, .btn-info:disabled { color: var(--al-accent-on-primary); background-color: var(--al-accent-primary); border-color: var(--al-accent-primary); } .btn-info:not(:disabled):not(.disabled):hover, .btn-info:not(:disabled):not(.disabled):active, .btn-info:not(:disabled):not(.disabled).active, .show > .btn-info.dropdown-toggle { color: var(--al-accent-on-primary); background-color: var(--al-accent-primary); border-color: var(--al-accent-primary); } .btn-info:not(:disabled):not(.disabled):active:focus, .btn-info:not(:disabled):not(.disabled).active:focus, .show > .btn-info.dropdown-toggle:focus { box-shadow: none; } .btn-info2 { color: var(--al-accent-on-primary); background-color: var(--al-info-solid); border-color: var(--al-info-solid); } .btn-info2:focus, .btn-info2.focus { box-shadow: none; } .btn-info2.disabled, .btn-info2:disabled { color: var(--al-accent-on-primary); background-color: var(--al-info-solid); border-color: var(--al-info-solid); } .btn-info2:not(:disabled):not(.disabled):hover, .btn-info2:not(:disabled):not(.disabled):active, .btn-info2:not(:disabled):not(.disabled).active, .show > .btn-info2.dropdown-toggle { color: var(--al-accent-on-primary); background-color: var(--al-info-solid-hover); border-color: var(--al-info-solid-hover); } .btn-info2:not(:disabled):not(.disabled):active:focus, .btn-info2:not(:disabled):not(.disabled).active:focus, .show > .btn-info2.dropdown-toggle:focus { box-shadow: none; } .btn-warning { color: var(--al-text-strong); background-color: var(--al-warning-solid); border-color: var(--al-warning-solid); } .btn-warning:focus, .btn-warning.focus { color: var(--al-text-strong); background-color: var(--al-warning-solid); border-color: var(--al-warning-solid); box-shadow: none; } .btn-warning.disabled, .btn-warning:disabled { color: var(--al-text-strong); background-color: var(--al-warning-solid); border-color: var(--al-warning-solid); } .btn-warning:not(:disabled):not(.disabled):hover, .btn-warning:not(:disabled):not(.disabled):active, .btn-warning:not(:disabled):not(.disabled).active, .show > .btn-warning.dropdown-toggle { color: var(--al-text-strong); background-color: var(--al-warning-solid); border-color: var(--al-warning-solid); } .btn-warning:not(:disabled):not(.disabled):active:focus, .btn-warning:not(:disabled):not(.disabled).active:focus, .show > .btn-warning.dropdown-toggle:focus { box-shadow: none; } .btn-danger { color: var(--al-accent-on-primary); background-color: var(--al-danger-solid); border-color: var(--al-danger-solid); } .btn-danger:focus, .btn-danger.focus { color: var(--al-accent-on-primary); background-color: var(--al-danger-solid); border-color: var(--al-danger-solid); box-shadow: none; } .btn-danger.disabled, .btn-danger:disabled { color: var(--al-accent-on-primary); background-color: var(--al-danger-solid); border-color: var(--al-danger-solid); } .btn-danger:not(:disabled):not(.disabled):hover, .btn-danger:not(:disabled):not(.disabled):active, .btn-danger:not(:disabled):not(.disabled).active, .show > .btn-danger.dropdown-toggle { color: var(--al-accent-on-primary); background-color: var(--al-danger-solid); border-color: var(--al-danger-solid); } .btn-danger:not(:disabled):not(.disabled):active:focus, .btn-danger:not(:disabled):not(.disabled).active:focus, .show > .btn-danger.dropdown-toggle:focus { box-shadow: none; } /* ---- THE RING IS FOR THE KEYBOARD ---- Every :focus block above sets box-shadow:none and the ring is re-applied here on :focus-visible, because a mousedown FOCUSES a button: pressing Validate painted a 3px emerald ring around it and held it there until something else took focus. That is a focus indicator answering a press, and it was the loudest thing about the pressed state. The colour restatements in those blocks stay where they are. They are not about the ring -- bootstrap ships colour AND shadow together at (0,2,0), so a block that declared shadow alone let its recolour through and every focused button went vendor blue until blur. That still has to be beaten on plain :focus. Only the ring moves. */ .btn:focus-visible { box-shadow: var(--al-ring-focus-strong); } /* .btn-light and .btn-dark retired (P9-BTN5, recipe: no neutral/grey button). .btn-light had 0 uses; .btn-dark's uses were reclassed to .btn-secondary (grow Transfer / Print Tags; inventory Batch/Manage; metrc Resolve). Ink survives only as POS payment tiles, not as a button. */ /* ============================================================ v2 radius + emerald focus (T5) Bootstrap's flat 4px defaults -> the DS radius scale; the blue focus glow -> the emerald ring. Kendo / ag-Grid controls keep their own look for now (folded into one grid style in P2). ============================================================ */ .btn, .form-control, .custom-select { border-radius: var(--al-radius-md); } /* ============================================================================ P4-T3 — SECTION CARD. ============================================================================ Measured by rendering the prototype across 23 screens (45 cards): node .specs-local/tools/design-measure.js cards Two properties are UNANIMOUS at 45/45 — 1px border, and box-shadow:none. The design's card is FLAT. 44/45 use #e4e7ec and white. Radius is 10px at 58% (then 12px, 8px), which --al-radius-xl already carries. The card was already at the right radius; what it was still inheriting from Bootstrap was a translucent-black border and a grey-on-grey header. >> PADDING DISCREPANCY, RECORDED NOT RESOLVED. --al-pad-card is 18px 20px and its note claims "23/26 agree, well settled". Rendering gives 16px 17px (13 cards) and 16px 18px (7). The gap is 2-3px and my card detector is a heuristic that may be measuring the padded wrapper rather than the semantic body, so the established token WINS here. Not worth churning a settled value on a heuristic's word. Revisit if T4 makes it matter. */ .card { border-radius: var(--al-radius-xl); border-color: var(--al-border-default); background-color: var(--al-surface-card); box-shadow: none; } /* Bootstrap gives the header a grey tint (rgba(0,0,0,.03)) and a 3px radius that does not follow the card's 10px, so the corners visibly disagree. The design's header is the same white as the card, separated by the hairline alone. */ .card-header { background-color: transparent; border-bottom-color: var(--al-border-default); border-top-left-radius: var(--al-radius-xl); border-top-right-radius: var(--al-radius-xl); padding: var(--al-pad-card-head); } .card-footer { background-color: transparent; border-top-color: var(--al-border-default); border-bottom-left-radius: var(--al-radius-xl); border-bottom-right-radius: var(--al-radius-xl); } .card-body { padding: var(--al-pad-card); } /* ---------------------------------------------------------------------------- FORM LAYOUT GRID — OPT-IN, deliberately NOT applied to .card-body. ---------------------------------------------------------------------------- The Design Guide canvas claims the card body IS the form grid at "1fr 1fr, gap 18px". Rendering the PROTOTYPE — which is the authority here — says: - equal-width columns: CONFIRMED (4 of 5 measured form grids) - two columns: NOT universal. The customer detail form is THREE. - gap 18px: appears ZERO times. Measured column-gaps are 16px (x2), 14px, 10px; row-gaps 14px (x2), 16px, 10px. Hence 14px 16px below, which is exactly what the largest form (customer detail) uses. >> WHY THIS IS NOT ON .card-body. << Setting display:grid on .card-body would change LAYOUT for 169 card bodies app-wide, most of which contain Bootstrap .row/.col markup that grid would fight. That is a functional change with a large blast radius, and this is a reskin. So the grid is an opt-in class a view applies where a form actually wants it. --al-form-cols lets a 3-column form override without a new class. -------------------------------------------------------------------------- */ .al-form-grid { display: grid; grid-template-columns: repeat(var(--al-form-cols, 2), minmax(0, 1fr)); gap: 14px 16px; align-items: start; } /* A field that must span the full form width regardless of column count. */ .al-form-grid > .al-field-wide { grid-column: 1 / -1; } /* ---------------------------------------------------------------------------- P5-T-filtercard — LIST-PAGE FILTER CARD (design: Prototype:3696, the Retail Order History page). A white card wrapping a responsive grid of labeled filter fields. The fields themselves are already styled (P4-T4); this adds the container chrome, the auto-fit field grid, and the uppercase eyebrow labels. Reusable — consumed today by retail_order_history + add_inventory, and by the T11 list archetype later. Scope: only the two pages that HAND-ROLL a labeled-field bar can take this as a pure reskin. The dominant list pages inject a Kendo filter widget into a placeholder div (deliberately excluded from the field restyle, see :1093) — converting those is a markup/behaviour change, deferred to T11/Tier-3. */ .al-filter-card { background-color: var(--al-surface-card); border: 1px solid var(--al-border-default); border-radius: var(--al-radius-xl); padding: 16px 18px; margin-bottom: 16px; } /* Auto-fit field grid — cells reflow to fill the row (design: repeat(auto-fit, minmax(190px, 1fr)), gap 14/16). align-items:end so labels sit at the top and the controls — plus a trailing Apply button — share one baseline (this preserved the app's original .align-items-end intent). */ .al-filter-grid { display: grid; grid-template-columns: repeat(auto-fit, minmax(190px, 1fr)); gap: 14px 16px; align-items: end; } /* Uppercase eyebrow labels for the filter fields (design: 11/700/.04em/#8a92a0). Scoped to the filter card so it does not touch other .form-label uses. Beats .form-label on specificity (0,1,1 vs 0,1,0). */ .al-filter-card label { display: block; margin-bottom: 6px; font-size: var(--al-fs-xs, 11px); font-weight: var(--al-fw-bold); letter-spacing: 0.04em; text-transform: uppercase; color: var(--al-accent-primary); /* [P9-CRD-ADM-EYE #3] filter-card eyebrow -> emerald (was ink-300 #8a92a0) */ } .dropdown-menu { border-radius: var(--al-radius-lg); } /* ============================================================================ P4-T7 — MODALS. Measured by rendering the prototype and OPENING modals (a closed modal computes styles but is not a measured modal — the T4b lesson). The design's dialog: container #fff, radius 14px, shadow 0 24px 60px rgba(0,0,0,.28) header padding 18px 22px, border-bottom 1px #eef0f3, title 16px/700 body padding 20px 22px footer padding 14px 22px, border-top 1px #eef0f3, right-aligned, gap 10 backdrop rgba(20,25,35,.5) (blue-ink, not Bootstrap's flat black) Every value already had a token — this task is wiring, not new tokens. Modal chrome is deliberately roomier than card chrome (18/20/14 vs the card's 18/20), so it uses its OWN --al-pad-modal-* tokens; do not stretch card padding over it. */ .modal-content { border-radius: var(--al-sys-radius-container); box-shadow: var(--al-sys-elevation-overlay); border: var(--al-sys-control-border-width) solid var(--al-sys-color-border); } .modal-header { padding: var(--al-sys-space-200) var(--al-sys-space-300); border-bottom: var(--al-sys-control-border-width) solid var(--al-sys-color-border); } .modal-title { font-size: var(--al-sys-font-size-400); font-weight: var(--al-fw-bold); color: var(--al-text-strong); } .modal-body { padding: var(--al-sys-space-200) var(--al-sys-space-300); } /* A HEADING INSIDE A DIALOG MUST NOT OUTRANK THE DIALOG'S OWN TITLE. Bootstrap's h1-h6 are page-scale, so "Metrc Endpoints Called:" came out 20px/500 under a 17px/700 title — the section label read as the more important of the two, and it was lighter as well as bigger. Inside a modal these step DOWN from the title, and they are section labels, so they are set at the heading weight rather than the 500 bootstrap gives them. Scoped to .modal-body so it cannot reach a heading on the page behind it. */ .modal-body h1, .modal-body h2, .modal-body h3, .modal-body h4, .modal-body h5, .modal-body h6 { font-size: var(--al-sys-font-size-300); font-weight: var(--al-sys-font-weight-heading); line-height: var(--al-sys-line-height-heading); color: var(--al-sys-color-text-primary); } /* Bootstrap's rule is a raw rgba(0,0,0,.1); ours is the hairline every other divider in the app uses, so a rule inside a dialog matches the one under its header. */ hr { border-top-color: var(--al-sys-color-border); } /* .text-muted was still bootstrap's #6c757d — a warm grey next to the blue-ink secondary every label, hint and caption in the app already uses. 74 uses across 34 views, all of them meaning the same thing, all of them the wrong grey. THE !important IS THE UTILITY'S OWN. Bootstrap ships .text-muted with it, so nothing short of !important replaces it, and scoping under an ancestor cannot. This is not beating a rule on specificity — it is the same utility in our colour. */ .text-muted { color: var(--al-sys-color-text-secondary) !important; } .modal-footer { padding: var(--al-sys-space-150) var(--al-sys-space-300); border-top: var(--al-sys-control-border-width) solid var(--al-sys-color-border); justify-content: flex-end; gap: var(--al-sys-space-100); } /* Bootstrap spaces footer children with per-child margins; the design uses a flex gap. Zero the child margins so the two do not compound into uneven gaps. */ .modal-footer > * { margin: 0; } /* The design's scrim is a dark blue-ink (--al-scrim = rgba(20,25,35,.5)), not Bootstrap's flat black. Set the colour (its own .5 alpha carries the dimming) and pin .show to opacity 1 so Bootstrap's opacity:.5 does not halve the alpha to ~.25 and wash the scrim out. */ .modal-backdrop { background-color: var(--al-sys-color-scrim); } .modal-backdrop.show { opacity: 1; } /* Kendo's Window and Dialog are the same shell as a Bootstrap modal, so they take the same container radius and the same scrim rather than the vendor's own. */ .k-window, .k-dialog { border-radius: var(--al-sys-radius-container); } .k-overlay { background-color: var(--al-sys-color-scrim); opacity: 1; } /* Centre every modal vertically. The design centres its dialogs; Bootstrap top-aligns by default. Jeff's rule: centre as the general default, revisit only if a large modal reads worse centred. >> WHY NOT Bootstrap's .modal-dialog-centered. << That relies on `min-height: 100%` on .modal-dialog resolving against the full- height .modal. Several config modals wrap .modal-dialog in a
(e.g. config_templates/inventory/brand.html:46), and the block is only as tall as its content, so `100%` collapses and the dialog sticks to the top — even though the markup already carries .modal-dialog-centered. Centring on the .modal itself is wrapper-proof: whatever the single child is (.modal-dialog or a around it) gets centred as a unit. `safe center` keeps it scroll-safe: when a modal is taller than the viewport it falls back to top-aligned so the header can't be clipped above the scroll, which plain `center` would do. Chrome (the app's target) supports it. */ .modal.show { display: flex !important; align-items: safe center; justify-content: center; } /* ============================================================================ P5-T1 — CONFIRMATION DIALOG. Design: Guide §10 + Prototype:3062-3072. ============================================================================ The app's Bootstrap confirm/delete modals get a scoping hook `.al-confirm` plus a `--danger` (delete) or `--warning` (guarded) variant, and adopt the design: a 46px icon-circle over a centered title, a body that NAMES the record, and a Cancel-first footer of two full-width buttons. Filled red is the confirm action for DELETES only; guarded actions use a warning icon and a GREEN confirm (Guide §10:234). Builds on the P4-T7 frame above. >> Per-modal markup the surgery (P5-T1 batches) produces:
(--warning = guarded)
delete
Delete this discount?
{{ name }} will be permanently removed. This can't be undone.
Confirm buttons carry `.al-confirm-btn` (NOT `.btn`) so button geometry does not double-apply. --warning uses the `warning` icon + verb-specific label. */ .al-confirm .modal-dialog { max-width: 384px; } /* a confirm that has to SHOW something -- a diff, a list of what will change -- rather than just ask. 384px is right for a question and wrong for two columns of evidence. */ .al-confirm--wide .modal-dialog { max-width: 720px; } /* Clip children to the frame's rounded corners. `.modal-content` carries the radius but no overflow, so an opaque per-page `.modal-body{background:#fff}` (left over in note.css / file.css from the old modals) paints a square that bleeds over the rounded top corners. Clipping here makes the frame win. */ .al-confirm .modal-content { overflow: hidden; } /* the design confirm has no header/X — icon + title live in the centered body */ .al-confirm .modal-header { display: none; } .al-confirm .modal-body { padding: 24px 24px 18px; text-align: center; } .al-confirm-icon { width: 46px; height: 46px; margin: 0 auto 14px; border-radius: 50%; display: flex; align-items: center; justify-content: center; } .al-confirm-icon .material-symbols-outlined { font-size: var(--al-fs-4xl, 24px); } .al-confirm--danger .al-confirm-icon { background-color: var(--al-danger-bg); } .al-confirm--danger .al-confirm-icon .material-symbols-outlined { color: var(--al-danger-fg); } .al-confirm--warning .al-confirm-icon { background-color: var(--al-warning-bg); } /* A FILL RUNG IS NOT AN INK, AND FOR TWO WEEKS THIS RULE SAID SO TO NOBODY. [ALLM-7295] The glyph takes --al-dialog-tone from recipe-controls.css:11431, and for warning that is amber-500, a rung meant for a fill or an edge. Measured on the real #timeoutModal in views/account/login.njk, which needs no session: #c38313 on #fdf3e3 is 2.91:1, under even the 3:1 a glyph has to clear. THE FIRST FIX NEVER APPLIED, AND THE SELECTOR IS WHY. It was written .al-confirm--warning with two dashes; every dialog in views/ spells it .al-confirm-warning with one, and the recipe defines the one-dash name at recipe-controls.css:11503. A two-dash selector cannot match a one-dash class, so the ticket reported 2.91 fixed to 5.51 while the page went on reading 2.91. Corrected here and re-measured on the same element: 5.51:1. ONLY WARNING IS TOUCHED, because only warning fails. Measured on the same dialog by swapping its tone class: info 4.95:1 and danger 4.47:1 both clear 3:1 on the tone alone. The neighbouring --warning/--danger/--alert rules in this file are dead for the same spelling reason, and correcting them would change two tones that pass today. Left alone deliberately; the ground here still comes from the recipe's tone-tint, which is what the 5.51 was measured against. DARK IS NOT ANSWERED HERE. .al-on-dark .al-confirm--warning at line 3728 carries the same two-dash spelling, so the dark pairing ALLM-7292 recorded as settled cannot be applying either. That wants measuring on a surface that genuinely renders dark, not on this one. */ .al-confirm-warning .al-confirm-icon .material-symbols-outlined { color: var(--al-warning-fg); } /* The third dialog variant: alert/info, a single acknowledge, recipe Modals #8. CSS-ready; renders once a neutral prompt adopts .al-confirm--alert. */ .al-confirm--alert .al-confirm-icon { background-color: var(--al-info-bg, #eaf1fb); } .al-confirm--alert .al-confirm-icon .material-symbols-outlined { color: var(--al-info-fg, #2a6fdb); } .al-confirm-title { font-size: var(--al-sys-font-size-300); font-weight: var(--al-fw-bold); color: var(--al-text-strong); margin-bottom: 7px; } .al-confirm-text { font-size: 13.5px; line-height: 1.55; color: var(--al-text-muted); } /* the bold record name the dialog always states */ .al-confirm-text b { color: var(--al-text-body); } /* footer: no divider, two full-width buttons, Cancel first */ .al-confirm .modal-footer { padding: 0 24px 22px; border-top: none; flex-wrap: nowrap; gap: 10px; } /* Scoped `.al-confirm .modal-footer …` (0,0,3,0) so per-page modal CSS — e.g. customer/file.css's `.modal-footer button:first-of-type{background:#880000}` positional overrides left over from the old modals — can't repaint these. */ .al-confirm .modal-footer .al-confirm-btn { /* [PASS6-F13] GEOMETRY REMOVED — padding, font-size, font-weight and radius now come from the shared tier rule above, which these selectors joined. What is left is genuinely dialog-specific: the footer stretches its two buttons to fill. Leaving even one geometry value here would silently re-fork the system, because this rule is (0,3,0) and sits later in the file. */ flex: 1; width: auto; margin: 0; font-family: inherit; cursor: pointer; } /* .al-confirm-btn is not a .btn, so the ring the button rules give does not reach it; button ring never applied (recipe Modals #6). Keyboard only, for the reason above: with :focus in the list, clicking Delete ringed the button under the pointer. */ .al-confirm .modal-footer .al-confirm-btn:focus { outline: none; } .al-confirm .modal-footer .al-confirm-btn:focus-visible { outline: none; box-shadow: var(--al-ring-focus); } /* [P9-BTN7] Cancel folds onto the standard Secondary (recipe #8): emerald outline, was a grey outline (text-body / border-input). Hover = emerald-100 ghost fill, matching .btn-secondary (BTN2). */ .al-confirm .modal-footer .al-confirm-cancel { color: var(--al-accent-primary); background-color: var(--al-surface-card); border: 1px solid var(--al-accent-primary); } .al-confirm .modal-footer .al-confirm-cancel:hover { color: var(--al-accent-primary); background-color: var(--al-accent-primary-tint); border-color: var(--al-accent-primary); } /* Third, negative-but-not-dismiss action for 3-outcome confirms (approve / DENY / cancel — the admin email-change approval). Red outline: distinct from the grey Cancel outline and the filled action, fills red on hover. Only 3-button confirms use it; two-button confirms never render it. */ .al-confirm .modal-footer .al-confirm-deny { color: var(--al-danger-solid); background-color: var(--al-surface-card); border: 1px solid var(--al-danger-solid); } .al-confirm .modal-footer .al-confirm-deny:hover { color: var(--al-accent-on-primary); background-color: var(--al-danger-solid); border-color: var(--al-danger-solid); } /* the confirm action — RED filled for deletes, GREEN filled for guarded */ .al-confirm .modal-footer .al-confirm-action { /* THE FILL BELONGS ON THE BASE. It only ever lived on the --danger and --warning variants, and every confirm in the app had one -- so the first plain .al-confirm rendered white text on the framework's #f0f0f0 and the primary button was unreadable. A variant re-points this; it does not supply it. */ background: var(--al-accent-primary); color: var(--al-accent-on-primary); border: 1px solid transparent; } .al-confirm--danger .modal-footer .al-confirm-action { background-color: var(--al-danger-solid); border-color: var(--al-danger-solid); } .al-confirm--danger .modal-footer .al-confirm-action:hover { background-color: var(--al-danger-solid-hover); border-color: var(--al-danger-solid-hover); } .al-confirm--warning .modal-footer .al-confirm-action { background-color: var(--al-accent-primary); border-color: var(--al-accent-primary); } .al-confirm--warning .modal-footer .al-confirm-action:hover { background-color: var(--al-accent-primary-hover); border-color: var(--al-accent-primary-hover); } /* ============================================================================ P4-T9 — ag-GRID CHROME. Renders on the orders + cash grids (16-20 mounts). ============================================================================ Measured: the design's data table has a muted-grey UPPERCASE header band over a hairline, and a 13px/400 body. ag-Grid v25 ships NO --ag-* custom properties (those arrived in v27), so every value is a hand-authored override. header bg #f8f9fb, text #8a92a0 11px/700 uppercase +0.05em, border #e4e7ec body 13px/400 #161b24, row border #eef0f3, selected row #e9f4ef Ours was dark 13px non-uppercase header, 14px/500 body — restated to the above. >> DOUBLED CLASS IS DELIBERATE, NOT A TYPO. ag-theme-alpine.min.css loads AFTER this file (T0 put ag-Grid last on both layouts for consistency), so a plain `.ag-theme-alpine .ag-header-cell` (0,2,0) would lose to the vendor on load order. `.ag-theme-alpine.ag-theme-alpine ...` is (0,3,0) — it beats the vendor rule without re-opening the load order or reaching for !important. Row HEIGHT is left alone — ag-Grid sets it inline from a JS option, not CSS; changing it here is fragile and is a functional concern, not chrome. Cell horizontal padding is also left to the page (order_status.css pins it with !important); this task is colour/type/border, not spacing. */ .ag-theme-alpine.ag-theme-alpine .ag-header { background-color: var(--al-surface-sunken); border-bottom: 1px solid var(--al-border-default); } .ag-theme-alpine.ag-theme-alpine .ag-header-cell { /* THE HEADER IS SENTENCE CASE, the same call the Kendo block below already carries: 13px / 600 / secondary ink, which is what .al-grid and .al-table say. This block held 11px / 700 / uppercase at 0.05em in the faint ink, so two of the product's three grid families disagreed with the third and with the recipe. Values are read off the sys tokens rather than restated as numbers, so they cannot drift from .al-grid's. */ color: var(--al-sys-color-text-secondary); font-size: var(--al-sys-font-size-200); font-weight: var(--al-sys-font-weight-control); letter-spacing: normal; text-transform: none; } .ag-theme-alpine.ag-theme-alpine .ag-row { color: var(--al-text-strong); font-size: var(--al-fs-base); font-weight: var(--al-fw-regular); border-bottom: 1px solid var(--al-surface-nested); } .ag-theme-alpine.ag-theme-alpine .ag-row-selected, .ag-theme-alpine.ag-theme-alpine .ag-row-selected .ag-cell { background-color: var(--al-accent-primary-tint); } /* ============================================================================ P4-T10 — BOOTSTRAP .table CHROME. 338 tables, on grow / cash / process / … ============================================================================ Same design table chrome as ag-Grid (T9): light muted UPPERCASE header band, 13px/400 body, hairline row borders. Ours had a DARK header (white on #343a40 via .thead-dark) and 500-weight body. Bootstrap loads before this file, so plain selectors win — no doubled-class needed here (unlike ag-Grid). >> THE .table-dark ROWS ARE PROTECTED. The app uses `` for dark emphasis rows (9 in views/). Setting body text to dark ink globally would paint dark-on-dark and make them unreadable, so every body rule is scoped `tr:not(.table-dark)`. Header dark (.thead-dark / thead.table-dark) IS overridden to the light band — the design has no dark headers. */ /* `.table .thead-dark th` is included because Bootstrap's own rule for the dark header is (0,2,1) and beats a plain `.table thead th` (0,1,2) on the colour + background — caught by the gate: grow's dark header took the uppercase/size but kept its white-on-#343a40. Matching that selector (and loading after Bootstrap) wins it back. */ .table thead th, .table .thead-dark th, .table thead.table-dark th { /* Sentence case, off the same three sys tokens as ag-Grid above and Kendo below. One look across all three grid families and the recipe, in one place each. */ color: var(--al-sys-color-text-secondary); background-color: var(--al-surface-sunken); font-size: var(--al-sys-font-size-200); font-weight: var(--al-sys-font-weight-control); letter-spacing: normal; text-transform: none; border-top: 0; /* border-color as well as the bottom edge: this block absorbed a second, later `.table thead th` rule that restated the whole band and recoloured Bootstrap's 2px bottom border. Same selector, same intent, two copies free to drift -- and they had, which is how a case fix here would have been silently overruled by the copy. */ border-color: var(--al-border-default); border-bottom: 1px solid var(--al-border-default); } /* neutralise the dark thead's own element background for the band to read clean */ .table thead.thead-dark, .table thead.table-dark { background-color: var(--al-surface-sunken); } /* body — normal rows only; .table-dark emphasis rows keep their own colours */ .table tbody tr:not(.table-dark) > td, .table tbody tr:not(.table-dark) > th { border-top: 1px solid var(--al-border-default); /* [P9-TBL-HAIRLINE-ADM] one hairline #e4e7ec (was #eef0f3) */ } .table tbody tr:not(.table-dark) > td { color: var(--al-text-strong); font-size: var(--al-fs-base); font-weight: var(--al-fw-regular); } .table-hover tbody tr:not(.table-dark):hover, .table-hover tbody tr:not(.table-dark):hover > td { background-color: var(--al-surface-sunken); /* [P9-TBL-SEL-ADM-CORE] neutral hover #f8f9fb (was emerald-100 == selected) */ } /* ============================================================================ P4-T11 — KENDO GRID CHROME. The tar pit, last. 9 grids on grow/cash/process/ customer, ~7,350 vendor rule blocks, ZERO custom properties. ============================================================================ Same design table chrome as ag-Grid (T9) and Bootstrap tables (T10) — one consistent data-table look across all three grid systems: header #f8f9fb band, #8a92a0 11px/700 uppercase +0.05em, #e4e7ec hairline body 13px/400 #161b24, #eef0f3 row border Kendo shipped a #f5f5f5 header, #333 13px/500 body, and a #f5f5f5 zebra. >> NO ZEBRA, on purpose. Kendo stripes .k-alt at #f5f5f5. ag-Grid and the Bootstrap tables are un-striped (hairline borders do the row separation), so the .k-alt stripe is removed here for consistency across all three. If a dense grid later needs a scan aid, a far fainter --al-gray-50 stripe is the move, not Kendo's heavy grey. Kendo CSS loads BEFORE this file (T0 order), so plain selectors win on load order — no doubled-class needed, unlike ag-Grid. Grid FILTER cells and row HEIGHT are left to Kendo: T4c already excluded grid-embedded fields (`:not(.k-grid *)`), and height is Kendo's own metric. This is colour / type / border only. */ /* THE THIRD SELECTOR IS THE ONE THAT DOES ANYTHING. kendo.common declares `.k-filter-row th, .k-grid-header th.k-header { font-weight: 400 }`, which is (0,2,1) against this rule's (0,2,0), so the weight below was silently losing and the headers rendered regular while every other property here applied. Measured 400 on the Users grid. Matching Kendo's selector length is what lets later source order decide it — the same lesson the .btn tiers in this file already carry. */ /* THE VENDOR FIELD CHROME IS THREE LITERALS, AND ALL THREE OUTLIVE A THEME. bootstrap `.form-control` is #fff on #495057, its `.dropdown-menu` is #fff on #212529, and Kendo's `.k-input` is #fff on #333 with a #ccc edge. On a dark ground each becomes a white slab -- the ui-select popup on Item detail is white rows under white text, and a Kendo picker's selected value measured 1.37:1. Repointed at the recipe roles they were imitating. The GROUNDS are a no-op on light: surface-control and surface-raised are both white there, which is exactly what the vendor was painting. The INKS move on light, from three vendor greys to the recipe's one ink, which is the direction every conformed field has already gone. */ .form-control { background-color: var(--al-sys-color-surface-control); color: var(--al-sys-color-text-primary); } /* AND THE FOCUS STATE, WHICH IS THE HALF THAT WAS MISSING. [ALLM-7428] The rule above is (0,1,0) and bootstrap.min.css carries `.form-control:focus { background-color: #fff }` at (0,2,0), so on any focused field the vendor won and the control painted white -- in dark mode, a white box among dark ones. It went unseen because almost nothing here is focused while you look at it. The exception is a ui-select: opening one moves focus into its search input, so it is the one control that is ALWAYS focused when you are looking at it, and it was the only one reported. Measured on the running admin in dark, on the State field of Editing _Testing Location: the open search input read rgb(255,255,255) with rgb(73,80,87) ink while every sibling field composited to rgb(13,17,23) with white ink. After: transparent over the same dark ground, white ink, indistinguishable from its neighbours. .btn-default-focus is the same gap wearing different clothes: ui-select's own stylesheet paints the CLOSED control #EBEBEB while it holds focus, which is the pale grey in the second screenshot on that ticket. Both are the vendor answering a state our theme only answered at rest. */ .form-control:focus { background-color: var(--al-sys-color-surface-control); color: var(--al-sys-color-text-primary); } .btn-default-focus { background-color: var(--al-sys-color-surface-control); color: var(--al-sys-color-text-primary); border-color: var(--al-sys-color-border-control); } .dropdown-menu { background-color: var(--al-sys-color-surface-raised); color: var(--al-sys-color-text-primary); border-color: var(--al-sys-color-border); } .k-input, .k-widget.k-input, .k-autocomplete, .k-picker { background-color: var(--al-sys-color-surface-control); color: var(--al-sys-color-text-primary); border-color: var(--al-sys-color-border-control); } /* AND AGAIN FOR EVERY STATE, because the rule above only wins while nobody is using the control. Kendo paints that same white FOUR times, and the rule above is only the first of them: .k-input, .k-widget.k-input (0,1,0) the rule above .k-input.k-hover, .k-input:hover, .k-widget... (0,2,0) the two below .k-input.k-focus, .k-input:focus, .k-widget... (0,2,0) .k-input:focus-within, .k-widget.k-input:focus-within (0,2,0) So the re-point above holds at rest and loses the instant anyone touches the control. On a dark ground that is a white slab appearing under white text exactly when someone is looking at it: the Retail Areas multiselect on Config > Sell > Terminals measured 1:1 on its own chips, and the vendor combobox on /inventory/add does the same. Matching the vendor's chain is what lets source order decide it, the same trick the .btn tiers and the grid header in this file already use. >> ENUMERATE ALL FOUR, WHICH IS THE PART I GOT WRONG. The first version of this covered focus and focus-within and stopped, because those were the states I happened to be driving. Hover shipped still white and Jeff caught it on the screen. Grep the vendor sheet for every rule that sets the property, then cover the list -- do not fix the states you noticed. >> AND THE ROOTS ARE A SECOND AXIS. [ALLM-7161] All four states were enumerated and `.k-picker` was not: it is named in the resting rule above and was missing from both of these, so a DropDownList was correct until somebody touched it and then took Kendo's `.k-picker.k-hover { color: #333 }`. On the Items pager in dark the page-size value measured 17.26:1 at rest and 1.37:1 with its list open -- the number you are changing FROM disappears at the moment you go to change it. Cover the vendor chain on both axes: every state, and every root the vendor applies the property to. */ .k-input.k-focus, .k-input:focus, .k-input:focus-within, .k-widget.k-input.k-focus, .k-widget.k-input:focus, .k-widget.k-input:focus-within, .k-picker.k-focus, .k-picker:focus, .k-picker:focus-within, .k-widget.k-picker.k-focus, .k-widget.k-picker:focus, .k-widget.k-picker:focus-within { background-color: var(--al-sys-color-surface-control); color: var(--al-sys-color-text-primary); } /* HOVER IS ITS OWN RULE so that it can carry the edge without touching the focused edge. Kendo's hover also darkens the border to a literal #aeaeae, and the recipe's answer to an input's hover is that there is not one: `.al-input:hover` does not exist. So hover holds the resting edge and changes nothing, which is the same call the grid header got under ALLM-7134 for the same reason -- conform to what the recipe already decided rather than invent a state for a vendor control that the app's own control does not have. */ .k-input.k-hover, .k-input:hover, .k-widget.k-input.k-hover, .k-widget.k-input:hover, .k-picker.k-hover, .k-picker:hover, .k-widget.k-picker.k-hover, .k-widget.k-picker:hover { background-color: var(--al-sys-color-surface-control); color: var(--al-sys-color-text-primary); border-color: var(--al-sys-color-border-control); } /* the selected value and the placeholder inside those, which carry their own vendor ink */ .k-input-value-text, .k-input-inner, .k-input-inner::placeholder { color: inherit; } /* AND THE TRIGGER BUTTON, which carries its own vendor GROUND rather than its own ink. The block above re-points the ink of the input's children and the block above that re-points the input's ground in all four of its states. The button that opens the list is neither: it is a