` — .list-group and .collapsable-card-body are the SAME element there, not the two nested elements includes/sidebar.tpl uses for its own left-nav panels (search "a case the rules above cannot reach at all" below) — a THIRD structural shape, distinct from both cases already handled, that a inherit-only approach would need yet another selector for every time a future page introduces a fourth. Decided against giving .list-group-item:first-child/:last-child their own explicit (non-inherit) radius instead — that would mean mirroring the ENTIRE first/last/collapsable-card-body selector matrix above a second time, one DOM level deeper, and staying in sync with it forever after. overflow: hidden here is one rule, fixes the current bug and every future markup shape at once, and costs nothing visible when .list-group's own radius is already correct (which it is, once the rules above are right) — it only ever matters as a backstop. The .card itself was the other candidate raised and rejected: .card is used far too broadly (dashboard panels, ticket cards, invoice panels) to safely clip everything inside it — a dropdown menu or a focus glow opening from a .card-header button, for instance, would be cut off. .list-group is the right element to clip precisely because it's also the element whose own radius is what's supposed to be showing through — clipping it to itself is a no-op when correct and a fix when it isn't. */ .list-group { overflow: hidden; } /* .list-group as a direct child of .card — theme.css:4138-4156. Mirrors Bootstrap's own :first-child/:last-child split on our token (real in this theme: the KB/downloads "related articles"/"popular" widgets and the dashboard's .client-home-cards panels all put .list-group as a card's last child, after a .card-body acting as a plain heading — so :last-child fires in practice, :first-child structurally can't, since something always precedes the list). Bootstrap needs no rule for the corner that ISN'T the true edge — at 4px nobody could see it was still rounded — so :not(:first-child)/:not(:last-child) are new here, not copied from the source; without them the un-zeroed corner would still show 14px from the base rule once it stopped being excluded by position (it isn't excluded — .card > .list-group is a real, matched selector, just not the FIRST-matching one; explicit zero, not omission, is what keeps it square). */ .card > .list-group:first-child { border-top-left-radius: calc(var(--mh-radius-lg) - 1px); border-top-right-radius: calc(var(--mh-radius-lg) - 1px); } .card > .list-group:last-child { border-bottom-right-radius: calc(var(--mh-radius-lg) - 1px); border-bottom-left-radius: calc(var(--mh-radius-lg) - 1px); } .card > .list-group:not(:first-child) { border-top-left-radius: 0; border-top-right-radius: 0; } .card > .list-group:not(:last-child) { border-bottom-right-radius: 0; border-bottom-left-radius: 0; } /* .list-group inside a sidebar card (includes/sidebar.tpl) — a case the rules above cannot reach at all, checked against the actual template rather than assumed. Sidebar panels wrap their list-group in an extra .collapsable-card-body div, between .card-header and .list-group (it exists for the panel-collapse JS, not for us), which breaks the .card > .list-group child combinator outright: neither Bootstrap's own position rules nor the four just above can match through it. Before this fix the sidebar's list-group — including the current-page ("active") item, styled green via .sidebar .list-group-item.active — got the (now-excluded) blanket rule uncontested on every corner: not the 3px/14px mismatch above, but the same top-corner problem, since .card-header unconditionally precedes .collapsable-card-body in this template — the list is never at the card's true top edge, so the top is always an interior seam and needs no first-child conditional. The bottom genuinely varies: $item->hasFooterHtml() is a live per-panel condition. No footer -> .collapsable-card-body is .card's last child and the list sits at the true bottom edge, rounds like the direct-child case above; a footer -> that edge is an interior seam too and stays square. */ .card > .collapsable-card-body > .list-group { border-top-left-radius: 0; border-top-right-radius: 0; } .card > .collapsable-card-body:last-child > .list-group:last-child { border-bottom-right-radius: calc(var(--mh-radius-lg) - 1px); border-bottom-left-radius: calc(var(--mh-radius-lg) - 1px); } .card > .collapsable-card-body:not(:last-child) > .list-group { border-bottom-right-radius: 0; border-bottom-left-radius: 0; } /* Collapsed sidebar panel — stray border line inside the card's rounded bottom corner. Traced, not guessed: .card-header's own border-bottom (theme.css:4185-4190, stock, correct when the panel is open — that's the seam between the title and the list below it) doesn't go away when the panel is minimised. js/whmcs.js:95-104 handles the collapse entirely in JS: clicking .card-minimise calls jQuery .slideUp() on .collapsable-card-body (an inline style, not a class — nothing to select there directly) and toggles a class called "minimised", but that class lands on .card-minimise itself (the chevron, for its own rotation animation), never on .card-header, .card, or the body. With the body gone, the card shrinks to wrap just the header, and the header's flat bottom border is now sitting right at the card's own --mh-radius-lg curve (CARDS & PANELS) instead of the straight seam it was drawn for. .card-minimise IS a real, live-toggled class, and it lives inside .card-header (nested in .card-title) — :has() reaches it from there, same technique already used for the invoice-panel case in CARDS & PANELS. (0,3,0): .card-header contributes 1, :has(.card-minimise .minimised) contributes the specificity of its own argument, 2 classes — comfortably past the stock (0,1,0) rule, no source-order dependency needed. Also covers the "minimise on load below 720px" branch in the same JS block, which sets the identical class through a different trigger. Scoped to :has(), not to .card-sidebar generally, so a panel that's open keeps its border exactly as before — this is the collapsed state only, not a blanket removal. */ .card-header:has(.card-minimise.minimised) { border-bottom: 0; } /* Active list-group item — theme.css:4848-4852. */ .list-group-item.active { background-color: var(--mh-primary); border-color: var(--mh-primary); } /* Sidebar current-page marker — parent is .sidebar .list-group-item.active, .sidebar .list-group-item.active:hover, .sidebar .list-group-item.active:focus at theme.css:10439, specificity (0,3,0) — three classes (.sidebar, .list-group-item, .active). The general .list-group-item.active override above is only (0,2,0) and loses to this hand-written sidebar rule, so the sidebar's current-page marker still renders the parent's #666 instead of brand (confirmed on staging). Match the parent's specificity here; equal specificity plus later source order (custom.css loads last) wins, per the verified .btn-primary case above. */ .sidebar .list-group-item.active, .sidebar .list-group-item.active:hover, .sidebar .list-group-item.active:focus { background-color: var(--mh-primary); border-color: var(--mh-primary); } /* .list-group-item-primary — theme.css:4991-5001. The plain :hover/:focus background (#b5c7d9) is a further shade not covered by this pass's ratios — left untouched, same as the matching .alert-primary hr note in ALERTS & BADGES. */ .list-group-item-primary { color: var(--mh-primary-mix-text); background-color: var(--mh-primary-mix-surface); } .list-group-item-primary.list-group-item-action.active { background-color: var(--mh-primary-mix-text); } /* ---- Header chrome — theme.css:9564-9656. Every page. -------------- */ /* Header bar itself. Moved from --mh-surface (#FFFFFF, which is what the stock #fff tokenised to) to --mh-bg, the brand's page background — tokens.css calls stone-100 "PAPER", and the header is chrome rather than a raised surface like a card or a modal, so surface was the wrong role for it. Nothing separates the header from the page by border or shadow (stock sets background-color and nothing else), so it was relying on white-against-paper to define its edge. That still holds: header.tpl renders

unconditionally directly beneath it, and the breadcrumb band is --mh-bg-sunken (#EFEDE8) — a distinctly warmer tone — so the boundary stays legible even though the header now matches the body colour below that band. Text contrast is effectively unchanged: --mh-text-body (#3A3D42) goes from 10.90:1 on white to 10.36:1 on paper, both far above AA. */ header.header { background-color: var(--mh-bg); } /* Logo, swapped to the SVG. WHMCS's logo upload doesn't accept SVG, so {$assetLogoPath} (header.tpl:83-84, `

`) always resolves to the PNG — CSS content: url() replaces the rendered image without touching the template, keeping the zero-override discipline (CLAUDE.md hard constraint 1). header.header .logo-img already carries WHMCS's own sizing (max-width:400px, max-height:60px, theme.css:9593-9596); content: url() replaces what the renders, not the element's own box model, so that constraint still applies to the SVG untouched — no extra sizing needed here. No specificity fight to win: nothing else in either stylesheet sets `content` on .logo-img, so this doesn't need to out-rank anything, just state a new property. Matched the exact selector for locality with the rule above, not because winning required it. Path is theme-relative: logo.svg lives in theme/img/ (part of this repo, deploys with everything else — confirmed present locally, 15688 bytes, matching the file already served from the earlier, separately-uploaded copy this replaces), one directory up from theme/css/custom.css, hence ../img/. Known, accepted trade-off: the tag's own `src` still names the PNG, so some browsers may fetch it even though it's never painted — not worth a template change to avoid one small unused request. */ header.header .logo-img { content: url('../img/logo.svg'); } /* Topbar (logged-in only — header.tpl:15 wraps it in {if $loggedin}) is a dark surface, mapped to surface-inverse. The source used three tiers of white-on-#404040 opacity (.65 base, .75 for the "logged in as" label, .65 dashed underline); preserved as two tiers against the new, darker background rather than carried over as literal alpha, since alpha alone doesn't guarantee AA on a different base colour — checked directly: --mh-text-inverse-muted (#9AA0A6) on --mh-surface-inverse (#1A1D21) is 6.4:1, --mh-text-inverse (#FAF9F6) on the same is 16.1:1. Both clear WCAG AA's 4.5:1 with room to spare. */ header.header .topbar { background-color: var(--mh-surface-inverse); color: var(--mh-text-inverse-muted); } header.header .topbar .btn, header.header .topbar .active-client .btn { color: var(--mh-text-inverse-muted); } /* "Logged in as:" sitting above the client name rather than beside it. Cause is structural, in stock markup: header.tpl:49-50 renders

, and .d-md-inline is `display: inline !important`, which overrides the .input-group-prepend { display: flex } that would normally centre the label. Being a flex item of .input-group, that inline display is then blockified to `block` (CSS Display 3 §2.7), so the prepend is a plain block stretched to the row height with its label parked at the TOP, while the .btn-group beside it centres its own text against the button padding — hence two different vertical positions. The two boxes are also unequal heights: stock keeps this label at 0.25rem padding / 0.8rem type via a (0,4,1) rule, but sets no line-height, so 4B's control-height line-height (18px, sized for a 42px form control) reaches it through the generic (0,1,0) .input-group-text rule and applies — a directly-set value beating the container's inherited line-height: 1. Centring the group on the cross axis fixes it at the level the layout is actually decided, rather than trying to match the two boxes by hand: each item then shrinks to its own content and sits on a shared centre line whatever its height. Same selector stock uses for this group, (0,3,1), and a property it doesn't set. */ header.header .topbar .active-client { align-items: center; } header.header .topbar .active-client .input-group-text { color: var(--mh-text-inverse); } header.header .topbar .active-client .btn.btn-active-client span { border-bottom-color: var(--mh-text-inverse-muted); } /* Toolbar icon buttons (cart, mobile menu) sit on the light header, not the topbar — theme.css's own #e5e5e5/#666 here is already a deliberately quiet default-vs-hover pair, not a contrast problem; tokenised at the same weight rather than redesigned. Brought into line with the search box beside it, which is the same visual weight and the same kind of control but was carrying a different neutral for its border and a different grey for its icon — two controls sitting side by side in one header, styled from two different places. Border moves from the raw --mh-stone-300 ramp value to --mh-border-control, the role token the search box (and every other bordered control in the theme) already uses; icon colour moves to --mh-text-subtle to match the magnifier. Both are small increases in contrast, not decreases: the icon was #E3E0D9 on a white header (~1.3:1, below any threshold) and is now 3.29:1, which clears WCAG 2.1 SC 1.4.11's 3:1 bar for a non-text UI component — the same figure the search icon has always rendered at, so this is parity, not a new compromise. Say if you'd rather both went darker (--mh-text-muted is 6.5:1); that's a weight change, not a consistency one, so it isn't made here. Radius: both this and .search below were still on Bootstrap's stock 0.25rem. The radius reconciliation never reached them — these are hand-written header-chrome rules at (0,3,1)/(0,2,1) that out-specify the general .btn/.form-control token rules, so the controls kept 4px while everything else on the page moved to 10px. Same token, stated on the selectors that actually win. */ header.header .toolbar .nav-link { border-color: var(--mh-border-control); color: var(--mh-text-subtle); border-radius: var(--mh-radius-md); } header.header .toolbar .nav-link:hover { color: var(--mh-text-muted); } /* Knowledgebase search box. */ header.header .search { border-color: var(--mh-border-control); border-radius: var(--mh-radius-md); } header.header .search .btn { color: var(--mh-text-subtle); } /* Exposed by the header moving off white: both children inside .search carry a white fill — the input from Bootstrap's own .form-control {background-color:#fff}, the magnifier from .btn-default's --mh-surface — and until now that was invisible because it matched the header exactly. On paper it reads as a white pill, with square corners poking past the wrapper's --mh-radius-md curve at all four corners: the same clipping shape already fixed for .list-group and the invoice panel. Made transparent rather than clipped. overflow:hidden on .search would work for the corners but would also cut off the input's own green focus glow (--mh-shadow-focus, painted outside its box), which is a worse trade. Transparent removes the rectangle instead of hiding its edges, and it matches the control standing next to it: the cart button is already transparent-with-a-border, so the two header controls now read as one system. The wrapper keeps the border and the :focus-within green below, so the field is still clearly a field and focus is still clearly signalled. Same selector pair the parent uses for its own border reset (theme.css:9635), (0,3,1) — clears stock .form-control (0,1,0) and our .btn-default rule (0,2,0) outright. */ header.header .search .btn, header.header .search .form-control { background-color: transparent; } /* :focus-within border was grey (#a5a5a5), independent of the green focus ring Pass A already puts on the inner .form-control (FORMS above) — two different colours doing the same job. Matched to --mh-primary so the wrapper border and the input's own focus glow read as one system instead of clashing. */ header.header .search:focus-within { border-color: var(--mh-primary); } /* Main nav links. */ header.header .navbar a { color: var(--mh-text-body); } /* ---- Footer — theme.css:9702-9712. Every page. Dark surface, same token pair as the topbar above and the same AA result: 16.1:1. -------- */ footer.footer { background-color: var(--mh-surface-inverse); color: var(--mh-text-inverse); } footer.footer .nav-link { color: var(--mh-text-inverse); } /* "Contact Us" removed — sales enquiries go to the main site's form and client-area users have ticketing, so the footer link is a third door to neither. Hardcoded in footer.tpl:34-38, not a menu item, so there is no admin setting to switch it off; done in CSS to stay inside hard constraint 1 rather than forking the template for one

. Keyed on the href rather than on position — it happens to be first-child today, but that's a fact about the current config (the sibling TOS item is behind {if $acceptTOS}, currently off), and a positional selector would silently start hiding the wrong link if that ever changes. Hides the

, not just the , so no empty list item is left in the flex row. Nothing else is left behind either: checked the rendered page, this is currently the only item in that

, and an emptied .nav collapses to zero height — it sets margin-bottom: 0 and padding-left: 0, and the mb-7 class beside it isn't defined in any stylesheet we load, so there's no residual gap to clean up. Note this hides the link, it does not retire the route: contact.php still resolves, and is still linked from error/page-not-found.tpl and two store/dynamic partials (the latter inside the excluded store area). Say the word if those should go too. */ footer.footer .nav-item:has(> a[href$="/contact.php"]) { display: none; } /* .btn background was rgba(255,255,255,.1) exactly — --mh-border-inverse is that identical value, already defined for dark-surface use. */ footer.footer .btn { background-color: var(--mh-border-inverse); color: var(--mh-text-inverse); } /* ---- Login page: minimal chrome, centred card ---------------------- */ /* Scoped on body:has(.login-form), which is exact. Verified by grepping every .tpl in the parent theme: `.login-form` and `#login` appear in login.tpl and nowhere else — not in two-factor-challenge.tpl, not in oauth/login-twofactorauth.tpl, and not in any of the four password-reset-*.tpl. Those pages keep the normal header, breadcrumb and footer, which is the right outcome: someone midway through a password reset or a 2FA challenge should still have navigation. There is no page identifier to key off otherwise — renders as class="primary-bg-color" on every page including this one — so :has() is doing real work here rather than being a shortcut. Deliberately NOT hidden: WHMCS's own dev-license notice, which sits inside .primary-content on staging. It is a system message about the install's licensing state, not our chrome, and suppressing it would hide something that is meant to be seen. It won't render in production. */ body:has(.login-form) header.header, body:has(.login-form) .master-breadcrumb, body:has(.login-form) footer.footer { display: none; } /* #main-body is the section wrapping the whole content area, so it is what can actually fill the viewport once the chrome above and below is gone. min-height rather than height, and padding rather than a fixed box: with min-height, a card taller than the viewport makes the section grow and centring simply stops applying, instead of the top of the card being clipped out of reach — the usual failure mode of centring with a fixed height. */ body:has(.login-form) #main-body { display: flex; flex-direction: column; align-items: center; justify-content: center; min-height: 100vh; padding-top: var(--mh-space-32); padding-bottom: var(--mh-space-32); } /* The logo went with the header, so it is reintroduced above the card — same content: url() approach as the header mark and the invoice, and the same theme-relative path. No width is set: the intrinsic 190x61 is the asset's own, and repeating it here would be a second number to keep in step with the file. Non-clickable and with no alt text, which was agreed — it is decorative here rather than the site's home link, and the page it would link to is the one you are already on. Hung off #main-body, not off .login-form. The first attempt put it on the form with `display:block; margin:0 auto` and it rendered hard against the left edge instead of centring: auto margins only centre a block-level REPLACED box, and engines do not consistently treat a pseudo-element carrying content:url() as one — treat it as a block box with an inline image inside and the box centres while the image stays at its left. Making it a flex item of the column above sidesteps that entirely: align-items:center places it by the flex algorithm, which has no such ambiguity, and it lands above .container because a ::before is the container's first child. */ body:has(.login-form) #main-body::before { content: url('../img/logo.svg'); display: block; margin-bottom: var(--mh-space-32); } /* ---- Semantic list-group items — theme.css:5019-5074. Bootstrap sits these at edge level rather than tint, and that is kept for three roles (ink on edge: 6.27 / 5.25 / 5.84). Warning is the exception: ink on warning-edge is 4.00, a fail, so warning uses -tint (5.14). :hover has no colour step. Bootstrap darkens to a fourth shade (e.g. #b1dfbb at 5023) that sits between -edge and -ink and has no token; rather than leave the stock green showing, hover holds the base fill. Logged in the README. .active inverts to an ink fill, which is how Bootstrap treats it too. */ .list-group-item-success, .list-group-item-success.list-group-item-action:hover, .list-group-item-success.list-group-item-action:focus { color: var(--mh-success-ink); background-color: var(--mh-success-edge); } .list-group-item-warning, .list-group-item-warning.list-group-item-action:hover, .list-group-item-warning.list-group-item-action:focus { color: var(--mh-warning-ink); background-color: var(--mh-warning-tint); } .list-group-item-danger, .list-group-item-danger.list-group-item-action:hover, .list-group-item-danger.list-group-item-action:focus { color: var(--mh-danger-ink); background-color: var(--mh-danger-edge); } .list-group-item-info, .list-group-item-info.list-group-item-action:hover, .list-group-item-info.list-group-item-action:focus { color: var(--mh-info-ink); background-color: var(--mh-info-edge); } .list-group-item-success.list-group-item-action.active { color: var(--mh-text-inverse); background-color: var(--mh-success-active); border-color: var(--mh-success-active); } .list-group-item-warning.list-group-item-action.active { color: var(--mh-text-inverse); background-color: var(--mh-warning-ink); border-color: var(--mh-warning-ink); } .list-group-item-danger.list-group-item-action.active { color: var(--mh-text-inverse); background-color: var(--mh-danger-ink); border-color: var(--mh-danger-ink); } .list-group-item-info.list-group-item-action.active { color: var(--mh-text-inverse); background-color: var(--mh-info-ink); border-color: var(--mh-info-ink); } /* Header notification popover — theme.css:10883-10941 (Pass B row 29, core-rendered). #ddd -> border-strong; the #555 link text -> text-body; the #f6f6f6 hover fill -> surface-hover, the token's own intended role. The severity icons (#5cb85c/#ecc317/#ec2d45) are semantic — notification severity — and stay untouched, same as the original Pass B classification. */ .popover-user-notifications { border-color: var(--mh-border-strong); } .popover-user-notifications ul li { border-bottom-color: var(--mh-border-strong); } .popover-user-notifications ul li a { color: var(--mh-text-body); } .popover-user-notifications ul li a:hover { background-color: var(--mh-surface-hover); } /* ========================================================================== 9. CART & CHECKOUT ========================================================================== */ /* Billing/service status badges — theme.css:10203-10295. #336699 here is the neutral/informational slot in a semantic status palette (green #5cb85c success, red #d9534f attention, amber #f0ad4e warning, blue neutral/informational) — not the brand colour. Our primary is green, so mapping this to --mh-primary would make .status-payment-pending read as "success" (near-identical to .status-paid). Mapped to a neutral stone slate instead, matched to the weight of the untouched neutral greys already in this same block (.status-closed / .status-cancelled #87939f, .status-terminated #666). */ .status-payment-pending, .status-delivered { background-color: var(--mh-stone-600); } /* .status-onhold was in the rule above until 4TS. It is a TICKET status as well as an invoice one, so it moved to the tint scheme below; the two invoice statuses keep the Pass A stone-600 solid. */ /* ---- Ticket statuses — theme.css:10211-10258. WHMCS picked these from the admin's point of view, where "Customer-Reply" means you must answer (loud orange) and "Answered" means you are done (muted purple). Both meanings invert in the client area and the palette was never re-picked for it. Reframed by who needs to act, and moved to the tint scheme so ticket badges match the ones 4S converted. answered client acts -> warning tint, the only ticket status that should draw the eye inprogress support acts -> info tint open support acts -> neutral, live customer-reply support acts -> neutral, live onhold nobody -> neutral, dormant closed nobody -> neutral, dormant + flat SELECTOR AUDIT (the 4S regression check): only two rules in any stylesheet we load set `color` on a status/label/badge selector above (0,1,0) — .div-service-status .label (theme.css:10743, 0,2,0) and .sidebar .list-group-item .badge (10432, 0,3,0). Neither is a ticket badge container: the first is the products dashboard, which renders .label-{modifier} and never .status-*, and the second is bare .badge. So the only colour these rules have to beat is .label { color:#fff } at theme.css:9492, which is (0,1,0) — a plain .status-* selector ties it and wins on source order. Plain selectors are used deliberately rather than compound .label.status-*, because clientareaproductdetails .tpl:467 renders .status-* without .status, and a compound form would miss it. Ink is set on every rule regardless, which is what 4S got wrong. TRAP 1: .status-open shares theme.css:10211 with .status-active and .status-completed, which are service and invoice statuses where green is correct. Only .status-open is named here; equal specificity plus later source order takes it out of that rule without touching the other two. TRAP 2: .status-onhold shared our own Pass A rule with .status-payment-pending and .status-delivered. Split above. THREE NEUTRALS: not available from the token set, reported rather than approximated. In the usable tint band the ramp steps are dE 1.4 (stone-150 to stone-200), 4.3 and 4.7 — indistinguishable to marginal at badge size. Only stone-100 vs stone-300 clears dE 9, and stone-100 is dE 2.6 from the white card behind it, so it barely reads as a badge at all. Two neutral levels are separated by INK instead, which the ramp does support cleanly: text-body and text-muted are dE 14.1 apart and both clear AA on the shared fill (9.32 and 5.57). Closed takes a third step structurally rather than chromatically — same fill and ink as onhold, but no border — so it sits flattest without inventing a colour. */ .status-answered { color: var(--mh-warning-ink); background-color: var(--mh-warning-tint); border: 1px solid var(--mh-warning-edge); } .status-inprogress { color: var(--mh-info-ink); background-color: var(--mh-info-tint); border: 1px solid var(--mh-info-edge); } .status-open, .status-customer-reply { color: var(--mh-text-body); background-color: var(--mh-bg-sunken); border: 1px solid var(--mh-stone-300); } .status-onhold { color: var(--mh-text-muted); background-color: var(--mh-bg-sunken); border: 1px solid var(--mh-stone-300); } .status-closed { color: var(--mh-text-muted); background-color: var(--mh-bg-sunken); border: 1px solid transparent; } /* Quote-page status pill reuses invoice-status classes with a different meaning per page. viewquote.tpl:43 renders "Delivered" as (invoice.css:9322, red) and "On Hold" as (invoice.css:9330, dark blue). Both are neutral quote stages, not money states, and both directly correspond to .status-delivered / .status-onhold just above — already stone-600 on the quotes list page — so this brings the individual quote view in line with that. Scoped to .col-sm-5, the quote page's own status wrapper (viewquote.tpl:41) — viewinvoice.tpl's equivalent wrapper is .invoice-col (viewinvoice.tpl:43), a different class, so the invoice page's own "Unpaid" (correctly red, invoice.css:9322) and "Refunded" are untouched by this rule. "Lost" and "Dead" reuse .cancelled/.collections the same way, but theme.css's own .status-lost/.status-dead render #000 on the quotes list page, not stone-600 — flattening them here would itself contradict "consistent with the theme.css status palette" as often as it would satisfy it. Left alone pending a decision; see README. */ .invoice-container .col-sm-5 .invoice-status .unpaid, .invoice-container .col-sm-5 .invoice-status .refunded { color: var(--mh-stone-600); } /* Refunded / Collections — the invoice page's OWN direct use of these two statuses (not the quote-page reuse above), found during 4-I and left open at the time: invoice.css:9330/9338 render Refunded as dark blue (#224488) and Collections as bright yellow (#ffcc00), neither matching what theme.css's own status palette says these mean — .status-refunded is amber (theme.css:10276, #f0ad4e) and .status-collections is dark slate (10272, #2c3e50). Same reasoning as the Delivered fix: bring the invoice page in line with the palette rather than inventing a third answer. Invoice statuses stay SOLID here, not tints — unlike 4TS's ticket reframing, which was a deliberate change of convention specific to tickets (whose colours were picked from the admin's point of view and needed reframing by who acts). Nothing about Refunded/Collections asks for that; this is a straight value correction within the existing invoice-status convention, which has stayed solid throughout (Unpaid, Paid, Draft, Cancelled all remain solid text with no fill). List-page fills use -ink, not the raw hue: white text (inherited via .label) on raw --mh-warning is 3.77, under AA; --mh-warning-ink reaches 5.92. --mh-stone-900 needs no ink variant, already 16.91 with white. Invoice-page text (no fill of its own, same as every other invoice-status class) takes the matching ink: --mh-warning-ink at 5.62 on paper, --mh-text (= stone-900) at 16.06. Scoped to .invoice-col, viewinvoice.tpl's own status wrapper — NOT .invoice-container alone — so quote's already-fixed "On Hold" (above) keeps winning there via its own higher-specificity .col-sm-5 rule, and so quote's "Dead" (which also reuses .collections, and is still the open Lost/Dead question flagged above) is not touched by this rule at all. That question stays exactly as open as it was. */ .status-refunded { background-color: var(--mh-warning-ink); } .status-collections { background-color: var(--mh-stone-900); } .invoice-container .invoice-col .invoice-status .refunded { color: var(--mh-warning-ink); } .invoice-container .invoice-col .invoice-status .collections { color: var(--mh-text); } /* ---- Domain pricing page — domain-pricing.tpl, includes/domain-search.tpl. Header bars ("New Price" / "Transfer" / "Renewal") are TWO overlapping rules, not one, and that overlap is what hid a third stock colour. theme.css:12752 sets border-bottom: 6px solid #97b5d2 and background-color: #efefef on every header cell (.col-xs-2/.col-sm-2/ .col-xs-4/.col-sm-4). theme.css:12767, higher specificity and later in the file, then overrides border-color — all four sides, this same bottom edge included — and background-color, but only on odd-position cells. So odd cells were already on #336699/#f5f5f5 (Pass A mapped the border half; the background half was still stock) while even cells were sitting on #efefef AND a lighter navy, #97b5d2, that never turned up in any colour-value sweep because the odd-cell rule masks it. #97b5d2 is the same family as #336699, just lighter — mapped to --mh-primary-edge. This is the mechanism to watch for elsewhere: a later, higher-specificity partial override (border-color, not border-bottom-color) can hide a sibling rule's colour behind it on the selectors it doesn't reach. theme.css:12747-12770. */ .domain-pricing .tld-pricing-header .col-xs-2, .domain-pricing .tld-pricing-header .col-sm-2, .domain-pricing .tld-pricing-header .col-xs-4, .domain-pricing .tld-pricing-header .col-sm-4 { background-color: var(--mh-bg-sunken); border-bottom-color: var(--mh-primary-edge); } .domain-pricing .tld-pricing-header div:nth-child(odd) { background-color: var(--mh-bg-sunken); border-color: var(--mh-primary); } /* Highlighted TLD row — theme.css:12743, #f3f9fd, a cool blue wash on warm paper. Same problem as .table-striped in 4S, same fix. */ .domain-pricing .tld-row.highlighted { background-color: var(--mh-stone-100); } /* Sale-group ribbons ("HOT" / "SALE" / "NEW") — theme.css:12787-12803. .tld-sale-group sets color:#fff directly (12789); measured against that literal value, not --mh-text-inverse, per the CLAUDE.md rule this page's ticket-badge work established. All three fill with -ink rather than the plain solid: white on the raw --mh-warning is 3.77 and on --mh-success is 3.42, both under AA. -ink passes for every role, danger's included (its -ink equals its solid, so hot is unchanged in value and just tokenised). Applying -ink uniformly means this reads as one rule, not an exception carved out for two roles that failed. Font-size stays at the parent's 10px, below the --mh-text-2xs floor 4T set for badges elsewhere. This is a corner ribbon on an already-space-constrained price tile, not a standalone badge, and raising it risks the wrap 4T measured on the neighbouring price-year elements. Deliberate exception, not a miss. .tld-sale-group also sets text-transform:uppercase (confirmed in the 4T uppercase inventory) — tracking-badge, not tracking-caps, which tokens.css documents for table heads and eyebrows; this is a badge. */ .tld-sale-group { letter-spacing: var(--mh-tracking-badge); } .tld-sale-group-hot { background-color: var(--mh-danger-ink); } .tld-sale-group-sale { background-color: var(--mh-warning-ink); } .tld-sale-group-new { background-color: var(--mh-success-ink); } /* Homepage domain search — theme.css:10469-10490. */ .home-domain-search .tld-logos { color: var(--mh-text-muted); } .home-domain-search .input-group-wrapper { background-color: var(--mh-surface); } /* Homepage domain search button — parent is .home-domain-search .input-group-wrapper .advanced-input .btn-success at theme.css:10501-10503, specificity (0,4,0) — four classes (.home-domain-search, .input-group-wrapper, .advanced-input, .btn-success). It sets #218739, WHMCS's own Bootstrap success green, not our brand green — the button currently renders green so it reads as correct at a glance, but it's the wrong green. Match the parent's specificity here. Redundant since .btn-success was aliased to .btn-primary (BUTTONS above) — it now sets what the button would inherit anyway. Kept because it still has to out-specify the parent's (0,4,0) rule, which would otherwise reassert #218739. */ .home-domain-search .input-group-wrapper .advanced-input .btn-success { background-color: var(--mh-primary); border-color: var(--mh-primary); } /* Featured TLD tiles — theme.css:12608-12643. Only the shell and the base .price fill/text; the 16 .price.{tld} identity colours are excluded, same category as the payment and social marks in CLAUDE.md's exclusion table. */ .featured-tld { background-color: var(--mh-surface); } .featured-tld .price { background-color: var(--mh-bg-sunken); color: var(--mh-text-body); } /* Upgrade page product panel — theme.css:11832, 11884. #2b5580 here isn't one of Bootstrap's formula-derived shades (it's a hand-picked panel colour, not generated from #336699 by any consistent ratio), so this maps to the nearest existing rung on the primary ladder rather than inventing a matching tint. */ .upgrade .products .product .header, .upgrade .products .product .btn { background-color: var(--mh-primary-active); } /* Remaining .upgrade neutrals — theme.css:11779-11860 (Pass B row 24). .current/.recommended (#ffbc00/#25ac2f) and .fa-check are semantic — current vs. recommended plan — and stay untouched, per the original Pass B classification. #aaa on the plain feature-list text was already failing AA before this pass (2.32:1) — --mh-text-subtle would have too (3.29), so this uses --mh-text-muted (6.52), which both tokenises and clears the pre-existing failure. */ .upgrade .product-to-be-upgraded { background-color: var(--mh-bg-sunken); } .upgrade .products .product { background-color: var(--mh-surface); } .upgrade .products .product ul { border-left-color: var(--mh-border); border-right-color: var(--mh-border); } .upgrade .products .product .footer { border-color: var(--mh-border); } .upgrade .products .product ul li { color: var(--mh-text-muted); border-bottom-color: var(--mh-border); } .upgrade .products .product ul li span { color: var(--mh-text-body); } /* Store order container — theme.css:11216-11255 (Pass B row 25). .domain-validation.ok (green) is semantic and already handled; this is the neutral base state only. */ .store-order-container .store-domain-tabs li a { background-color: var(--mh-bg-sunken); border-bottom-color: var(--mh-border-strong); } .store-order-container .store-domain-tabs li.active a { background-color: var(--mh-surface); } .store-order-container .store-domain-tab-content { border-color: var(--mh-border-strong); } .store-order-container .domain-validation { color: var(--mh-text-muted); } /* Credit card panel — theme.css:12250-12270 (Pass B row 30). #ccc as a background (the card-number strip) takes a solid stone rung, not a border alpha — --mh-stone-400 is the closest weight match. */ div.credit-card { background-color: var(--mh-bg-sunken); border-color: var(--mh-border-strong); } div.credit-card div.card-number { background-color: var(--mh-stone-400); } /* ---- The checkout — cart.php, domainchecker.php, the whole order flow. Session 4C found this page loads templates/orderforms/standard_cart/css/all.min.css at position 16 of 17, after custom.css at position 9 — confirmed on the cart.php network tab. Everywhere else in this file, equal specificity is enough because custom.css loads last (the verified .btn-primary case in CLAUDE.md). ON THIS PAGE THAT INVERTS: we are the EARLIER file, so an equal-specificity tie now goes to standard_cart's rule, not ours. MATCHING the #order-standard_cart ID is therefore not sufficient on its own where the parent rule already carries that ID — every such rule below EXCEEDS it, by repeating the class that follows the ID (`.form-control.form-control`), a deliberate, conventional specificity boost, not a typo. Where the parent rule carries NO ID at all (the domain-pricing block), prefixing #order-standard_cart is sufficient on its own, since the ID tier alone then exceeds the parent's class-only specificity regardless of load order. Selectors and values pulled from the live file over SSH (deploy-staging.sh credentials, read-only — standing permission, CLAUDE.md), 2026-09-10; full inventory in README.md. */ /* Focus ring. Parent (standard_cart's own rule, not theme.css) is #order-standard_cart .form-control:focus{border-color:#ddd; box-shadow:none} at (1,2,0). This removes the focus indicator entirely on every text input in checkout — a WCAG 2.4.7 Focus Visible failure, pre-existing, and unrelated to our work; see README. Restored at (1,3,0) via class repetition. */ #order-standard_cart .form-control.form-control:focus { box-shadow: var(--mh-shadow-focus); } /* Base field — #order-standard_cart .field,#order-standard_cart .form-control{border:1px solid #ddd;color:#626262; background-color:#fff;border-radius:3px} at (1,1,0), exceeded here at (1,2,0). Height, padding, font-size and line-height are NOT set by this parent rule (checked directly — the only cart-side rules that touch those are input-group-lg/-sm/-captcha variants, all separately scoped), so the 4B control-height tokens already apply uncontested on this page and are not re-declared here. Only the four properties the parent actually sets need overriding: border, text colour, fill, radius. Radius takes --mh-radius-md (10px), the value its own token comment in tokens.css already names for "inputs, selects" — an existing decision, not a new one made here. This creates a temporary inconsistency: the general, non-cart .form-control radius is still stock 4px (0.25rem), because 4B explicitly deferred that decision ("Radius is not touched here — that is the forms row's call"). Once the forms row sets a general radius, reconcile this rule to match rather than leaving the cart as the only place already on 10px. RECONCILED, but the reconciliation itself needed a follow-up: this rule sets border-radius uniformly on all four corners, which is fine for a bare field but wrong for one sitting inside an .input-group — the interior seam needs to stay square. That never showed up before because every .form-control here got the same uniform value regardless of position; it only became visible once a real, correctly zeroed neighbour (an .input-group-text or .btn) sat right next to it. Confirmed live on configureproductdomain.tpl's "www." prefix (register/transfer/owndomain domain rows — not in ../twenty-one-reference/, standard_cart's own template, pulled over SSH) and checkout.tpl's CVV help-button field — this ID rule is (1,2,0), which outranks Bootstrap's own interior-corner zeroing (.input-group > .form-control:not(:first-child)/:not(:last-child), (0,3,0), theme.css:3135-3143) unconditionally: an ID beats any number of classes regardless of count, so the general "let Bootstrap trim the interior corner" pattern used everywhere else in this file can't work here — it needs its own, higher-specificity statement of the true shape, same principle as the -sm/-lg button fix above. */ #order-standard_cart .field.field, #order-standard_cart .form-control.form-control { border-color: var(--mh-border-control); color: var(--mh-text-body); background-color: var(--mh-surface); border-radius: var(--mh-radius-md); } /* Interior seam, stated directly rather than left to Bootstrap's zeroing (which can't win here — see above). One rule per side: a form-control that isn't the input-group's first child has its LEFT corners squared (something else, the prepend, is the true left edge); one that isn't the last child has its RIGHT corners squared. Where neither condition applies (a lone field, no group) nothing here matches and the uniform --mh-radius-md above stands untouched. */ #order-standard_cart .input-group > .form-control:not(:first-child) { border-top-left-radius: 0; border-bottom-left-radius: 0; } #order-standard_cart .input-group > .form-control:not(:last-child) { border-top-right-radius: 0; border-bottom-right-radius: 0; } /* Domain-pricing block, re-applied under the ID prefix. Confirmed (Session 4C) that standard_cart/all.min.css duplicates the 4P rules verbatim, #369 (3-digit #336699) included, and that domainregister.tpl does render this markup — so without the ID prefix, the cart's own later-loading copy silently wins the tie and our 4P work reverts here. None of the parent rules below carry an ID, so #order-standard_cart alone is sufficient to exceed them; no class repetition needed. Same token mapping as 4P, restated for the exact selectors this page collides on. */ #order-standard_cart .domain-pricing .tld-pricing-header .col-xs-2, #order-standard_cart .domain-pricing .tld-pricing-header .col-sm-2, #order-standard_cart .domain-pricing .tld-pricing-header .col-xs-4, #order-standard_cart .domain-pricing .tld-pricing-header .col-sm-4 { background-color: var(--mh-bg-sunken); border-bottom-color: var(--mh-primary-edge); } #order-standard_cart .domain-pricing .tld-pricing-header div:nth-child(odd) { background-color: var(--mh-bg-sunken); border-color: var(--mh-primary); } #order-standard_cart .domain-pricing .tld-row.highlighted { background-color: var(--mh-stone-100); } /* Hero — third attempt. First (4X-1) painted only the inner element and left the outer gradient showing through. Second (4X-3) painted the outer element --mh-surface-inverse instead — correct as far as it went, but at panel scale a full ink-dark fill reads as a black slab; that token suits thin bands (footer, topbar), not a large panel, and removing it was the user's call after looking at both attempts. Root cause, not just a colour pick: the panel is sized for the globe illustration it no longer has. Two elements nest — domainregister.tpl:19-20, div.domain-checker-container (OUTER) > div.domain-checker-bg.clearfix (INNER) > the search form — and the illustration-sized space is NOT where it looks like it should be. Stock values, read before changing anything: .domain-checker-container{margin:20px 0;padding:0; background-color:#ffce44;border-radius:10px; background:-webkit-gradient(...)/-webkit-/-moz-/-ms-/-o-linear- gradient(top,#ffd960,#ffb201)} — PADDING IS ZERO. All of this element's stock spacing is the 20px margin; it contributes no internal height. .domain-checker-bg{margin:0;padding:80px 0; background-image:url(../img/globe.png)} (top-level), overridden to padding:40px 0 inside @media(max-width:992px). ALL the illustration-sized space is here, on the INNER element, not the outer one — the user's instruction named the container as the thing to depad, but the container was never carrying any. Removed the panel fill entirely per the user's "try this first": both elements transparent, no image, no colour. Padding cut from the INNER element (where it actually lives) to --mh-space-32 (32px, tokens.css's own "card padding (roomy)") desktop and --mh-space-24 (24px, "card padding (dense)") at the same ≤992px breakpoint the stock rule uses — not proportional to the 80/40 split, but both are existing tokens for exactly this kind of role, which reads more intentional than chasing an exact ratio. Combined with the container's unchanged 20px margin: total vertical gap around the search box drops from 100px (80+20) to 52px (32+20) desktop, 60px (40+20) to 44px (24+20) at ≤992px — a reduction, not a removal; some breathing room stays, since dropping straight to zero would sit the box flush against the paragraph above and the results area below with nothing to separate them. border-radius:10px on the container is neutralised (set to 0): with no fill, a rounded corner paints nothing, so leaving the stock value in place would be inert rather than meaningful. margin:20px 0 is LEFT ALONE (not overridden) — unlike radius, margin is layout spacing between this block and its siblings (the h1 above, the results area below) and keeps doing that with no fill at all, so it still does something and stays. Neither parent selector carries #order-standard_cart, so the ID prefix alone exceeds both (0,1,0) parents — no class repeat needed, consistent with 4X-1/4X-2/4X-3. FALLBACK, not applied — only if the search box reads as unanchored with no field behind it once this ships: give .domain-checker-bg background-color: var(--mh-bg-sunken) and a border on the search box itself (.input-group-box, already background: var(--mh-surface)) so it separates from a near-white field rather than blending into it. Padding should still come down either way; the illustration sizing isn't specific to which background choice wins. */ #order-standard_cart .domain-checker-container { background-color: transparent; background-image: none; border-radius: 0; } #order-standard_cart .domain-checker-bg { background-image: none; padding: var(--mh-space-32) 0; } @media (max-width: 992px) { #order-standard_cart .domain-checker-bg { padding: var(--mh-space-24) 0; } } /* ---- Checkout — WHMCS's own semantic classes. 4S mapped Bootstrap's semantic roles by targeting Bootstrap's own class names; these carry the same kind of state under WHMCS's own names, so that sweep never saw them. All in standard_cart/all.min.css (pulled again read-only under the standing SSH permission, confirmed unchanged since 4C), on domainregister.tpl and configureproductdomain.tpl. STATE MAPPING — checked against base.js's actual toggle logic and the template markup, not inferred from the class names: .domain-checker-available domain.isAvailable true -> success .domain-checker-unavailable domain taken, OR preferred TLD not sold (preferredTLDNotAvailable) -> danger .domain-checker-invalid malformed input / domain.error -> danger "Invalid" and "unavailable" turned out NOT to be the two different severities their names suggest (the brief's own warning, confirmed): WHMCS's stock CSS already colours both identically (#cd322d/#d9534f), and configureproductdomain.tpl:243 goes further — its own "invalid domain" headline is marked up with class="domain-checker-unavailable", not domain-checker-invalid. WHMCS doesn't maintain the distinction itself, so this doesn't invent one: both fold onto danger. No warning-role candidate exists among these three; every state is a clean yes/no, not a caution. .transfer-eligible / .transfer-not-eligible confirm the same two roles directly: configureproductdomain.tpl:233 marks its "eligible" headline class="domain-checker-available", and :237 marks its "not-eligible" headline class="domain-checker-unavailable" — WHMCS's own markup equates transfer eligibility with domain availability, so no separate mapping decision was needed here. SOLID OR TINT — decided per component, not as one blanket answer, because the three items don't share a visual structure today: Item 1 is bare coloured TEXT with no fill of its own (checked — neither the ID-scoped nor the global rule sets a background). Adding a badge fill where none exists would be a bigger change than "recolour it"; ink-only keeps the existing structure. Item 2 already IS an alert-style box (.transfer-eligible's stock #dff0d8/#d6e9c6/#3c763d is a literal Bootstrap 3 .alert-success clone) — tint, matching the structure it already has and the 4S alert precedent. Item 3 replicates 4P's already-settled solid -ink ribbons per the brief — not re-decided here. Where solid vs tint might have mattered most — a coloured or dark field forcing solid, the .mh-badge-solid case — doesn't arise: item 1 sits on the plain page background (#primaryLookupResult carries no background rule of its own, confirmed), and item 2's boxes are the field, not sitting on one. */ /* Availability text — item 1. Both the ID-scoped and the global (no-ID) copies of each rule exist in the parent file; both mapped so no residual stray copy is left stock. Both need the exceed treatment, not a match: the load-order inversion isn't specific to ID-scoped parents — ANY equal-specificity rule in this cart file, ID or not, loads after custom.css and wins a tie. The global rule is exceeded the same way, one tier down: (0,1,0) -> (0,2,0) via class repeat. */ #order-standard_cart .domain-checker-available.domain-checker-available { color: var(--mh-success-ink); } #order-standard_cart .domain-checker-invalid.domain-checker-invalid, #order-standard_cart .domain-checker-unavailable.domain-checker-unavailable { color: var(--mh-danger-ink); } .domain-checker-available.domain-checker-available { color: var(--mh-success-ink); } .domain-checker-invalid.domain-checker-invalid, .domain-checker-unavailable.domain-checker-unavailable { color: var(--mh-danger-ink); } /* Transfer eligibility boxes — item 2. .transfer-not-eligible's OWN background/text are neutral, not danger — confirmed from the markup: only its headline carries .domain-checker-unavailable (mapped above, inherits nothing extra needed here); the box's own three plain paragraphs use its own #666, unclassed. Setting color on the container cascades to them without overriding the headline's own explicit colour — a direct declaration always beats an inherited one regardless of specificity, so the danger-ink headline rule above is untouched by this. */ #order-standard_cart .transfer-eligible.transfer-eligible { background-color: var(--mh-success-tint); border-color: var(--mh-success-edge); color: var(--mh-success-ink); } #order-standard_cart .transfer-not-eligible.transfer-not-eligible { background-color: var(--mh-bg-sunken); color: var(--mh-text-muted); } /* Mirrored sale-group ribbons — item 3. Duplicates of 4P's .tld-sale-group-* under different names (.spotlight-tld-* on the inline suggestion tiles, .promo.hot/.sale/.new in the suggested- domains list) — same stock hex, same treatment: each role's -ink rung as a SOLID fill, uniformly, not just the two that fail white on their raw solid (warning 3.77, success 3.42). Both rule sets set color:#fff literally on themselves (not inherited from something .label-like), so the ratios below are measured against that literal value. Neither parent selector carries #order-standard_cart, so the ID prefix alone exceeds them — no class-repeat needed, unlike items 1 and 2 above. */ #order-standard_cart .spotlight-tld-hot, #order-standard_cart .suggested-domains .promo.hot { background-color: var(--mh-danger-ink); } #order-standard_cart .spotlight-tld-sale, #order-standard_cart .suggested-domains .promo.sale { background-color: var(--mh-warning-ink); } #order-standard_cart .spotlight-tld-new, #order-standard_cart .suggested-domains .promo.new { background-color: var(--mh-success-ink); } /* .spotlight-tld .invalid/.unavailable — correctly left outside 4X-2's named scope (neither is one of the six semantic classes that session covered). Already neutral (#eee/#ddd/#bbb), so token-only, not a contrast fix: the stock pairing is already 1.65:1, well under AA, but this is a disabled/unavailable-tile indicator, which WCAG doesn't require to meet contrast — a greyed-out affordance is supposed to read as de-emphasised. Mapped to the closest stone rungs at the same relative weights rather than pushed toward passing, which would make a "this TLD isn't available" tile look identical to a live one. #order-standard_cart alone exceeds the parent's (0,2,0), no class repeat needed — same as every other no-ID parent on this page. */ #order-standard_cart .spotlight-tld .invalid, #order-standard_cart .spotlight-tld .unavailable { background-color: var(--mh-stone-200); border-color: var(--mh-stone-300); color: var(--mh-stone-400); } /* Search box alignment — confirmed genuinely centred, not drifting (the .col-xs-10/.col-xs-offset-1/.col-md-offset-2 classes on the column are dead Bootstrap 3 syntax, defined nowhere; the live BS4 pair, .col-10/.offset-1 base and .col-md-8/.offset-md-2 at >=768px, is symmetric — 1+10+1=12, 2+8+2=12). Changed anyway: every other element on this page (h1, the "find new domain" line, "Browse extensions by category") is a direct child of .cart-body with no column wrapper — full width, left-aligned by default — so a centred narrower box is the one outlier in an otherwise uniformly left-aligned, full-width grid. Tried first, per the user's own preference: keep the width (.col-md-8/.col-10 untouched), drop only the offset. theme.css:767-769 (.offset-1, margin-left:8.3333333333%) and :1109-1111 (.offset-md-2, margin-left:16.6666666667%, inside @media(min-width:768px)) — neither redefined anywhere in standard_cart's own CSS, so this is the ordinary (non-inverted) case: theme.css loads before custom.css. Scoped to .domain-checker-bg rather than matched to the full class fingerprint, so it stays correct if a future WHMCS update drops one of the dead BS3 classes — and because BOTH the search-box row and the CAPTCHA row (when enabled) carry this identical class list, scoping by container correctly left-aligns both together rather than fixing one and leaving the other centred. Left-aligning surfaced a second issue, reported back and fixed here: the box's left edge now matched the heading, but its right edge matched nothing — the pricing table below runs full width, and col-md-8/col-10 stopped 33%/17% short of it. Checked what else could be constraining width before assuming the column classes were the whole story: neither .domain-checker-container nor .domain-checker-bg carries a max-width anywhere, and their padding/margin (see the hero comment above) is vertical-only — zero horizontal, at every breakpoint including the 992px one. The pricing table's own wrapper, .domain-pricing > .bg-white, is equally unconstrained: .domain-pricing has no base rule at all in either stylesheet, and .bg-white (theme.css:5938) is a plain `background-color:#fff !important` utility with no box-model properties. Both the hero and the table sit as direct, unpadded children of .cart-body, so nothing wraps either one more tightly than the other — the gap was never a container issue, purely the col-md-8/col-10 width classes on the form's own column. */ #order-standard_cart .domain-checker-bg .offset-1, #order-standard_cart .domain-checker-bg .offset-md-2 { margin-left: 0; } /* Bootstrap's grid columns aren't sized by `width` — the shared base rule (theme.css:596-601) already sets width:100% on every .col-* class uniformly; the actual constraint is `flex` and `max-width` on the SPECIFIC size class. .col-10 (theme.css:692-695) is flex:0 0 83.3333333333%/max-width:83.3333333333%; .col-md-8 (theme.css:1039-1042, >=768px) is 66.6666666667% for both. Matched to what .col-12/.col-md-12 themselves set (100%/100%) rather than just zeroing max-width, so this reads as "become full width" and not as an unusual one-off value. Same container scoping as the offset fix above, for the same reason: the CAPTCHA row shares this exact class list, so it goes full width along with the search box rather than being left behind at the old 66.67%. */ #order-standard_cart .domain-checker-bg .col-10, #order-standard_cart .domain-checker-bg .col-md-8 { flex: 0 0 100%; max-width: 100%; } /* AI domain search: Search button sitting inside the prompt box, where the same control on the cart's own domain step puts it alongside. Stock, not ours — standard_cart's sheet carries `.domain-checker-container.domain-checker-advanced #btnCheckAvailability {position:absolute;right:20px;top:74px}`, and since Bootstrap gives .input-group position:relative, that pins the button into the .input-group-box panel. The textarea beside it is 120px tall, so a 74px top offset lands the button inside it at any width — this reads as "inside the textarea" in stock too, the widening above only moved it horizontally. Both pages run the same feature through different markup: the cart's domain step (configureproductdomain.tpl:48) puts the textarea and the button in separate grid columns, which is why it already looks right, while domainregister.tpl:25-38 makes them siblings inside one .input-group and positions the button out of flow. templates/ orderforms/ is out of scope for forking (CLAUDE.md), so this is corrected in CSS by putting the button back in the flow and letting the textarea share the line with it. Scoped on the compound .domain-checker-container.domain-checker- advanced deliberately: BOTH pages carry .domain-checker-advanced (checked — configureproductdomain.tpl adds it too when AI search is on), and only domainregister.tpl also carries .domain-checker- container, so this reaches the broken page and cannot disturb the one already rendering correctly. Matched to the cart domain step's behaviour at BOTH widths, which is the part two earlier attempts missed. That page gets its layout from the grid — the textarea sits in .col-sm-8 and the button in .col-sm-2 with .btn-block (configureproductdomain.tpl:78-80) — so Bootstrap's sm breakpoint does the real work: above 576px the button sits beside the textarea, below it the column goes full width and btn-block makes the button a full-width block underneath. Reproduced here on the same 576px breakpoint rather than a number of our own, so the two pages change shape at the same point. Mobile first, per CLAUDE.md: the stacked arrangement is the base rule and the side-by-side one is the min-width override. The desktop half needs the textarea to CLAIM the first line, not just grow into it. A plain `flex: 1 1 auto` was the first attempt and was wrong: .input-group is flex-wrap:wrap, so the browser fills a line with every item whose BASE size fits before distributing free space — textarea, button, both .multiselect dropdowns and the Safe Search label all fit at their base sizes, so all five landed on one line and the textarea merely grew into the remainder. A flex-basis of nearly the full width leaves room for the button alone, and the option controls wrap beneath. 160px is the one hand-set figure and it is a floor, not a measurement: enough for the button plus the gap. The textarea keeps flex-grow, so slack returns to it rather than showing as a hole, and a wider button shrinks the textarea instead of breaking the line. width:auto + white-space:nowrap on the desktop button because stock pins it to 100px, too narrow for "Search" plus its icon — that was stacking the label above the sparkle. Stock height:46px is left alone: it is what stops .input-group's default align-items:stretch from dragging the button to the textarea's full 120px, and it leaves it top-aligned with the textarea as on the other page. (2,2,0) on each, clearing the stock (1,2,0) button rule and the (1,1,1) textarea width rule; the ID prefix also keeps us ahead of standard_cart loading after custom.css. */ #order-standard_cart .domain-checker-container.domain-checker-advanced #message { width: 100%; flex: 0 0 100%; } #order-standard_cart .domain-checker-container.domain-checker-advanced #btnCheckAvailability { position: static; width: 100%; margin-top: var(--mh-space-12); white-space: nowrap; } @media (min-width: 576px) { #order-standard_cart .domain-checker-container.domain-checker-advanced #message { width: auto; flex: 1 1 calc(100% - 160px); } #order-standard_cart .domain-checker-container.domain-checker-advanced #btnCheckAvailability { width: auto; margin-top: 0; margin-left: var(--mh-space-12); } } /* "Explore packages now" hosting upsell — stock WHMCS bug, not ours. domainregister.tpl's two .domain-promo-box cards are a designed pair (confirmed: both collapse to col-md-6 when $domainTransferEnabled is true) doing the identical job, cross-selling the client into another product — but WHMCS hardcodes text-warning/btn-warning on the hosting card's headline and CTA while the sibling transfer card uses text-primary/btn-primary for the same role. Neither card signals an actual warning state; this reads as a copy-paste slip in WHMCS's own markup, not an intentional distinction. 4S's global .text-warning/ .btn-warning mapping is correct and stays untouched — genuine warning contexts elsewhere depend on it — so this can only be a card-scoped fix, not a remap. Scoped by icon, not by any distinguishing class or ID, because neither exists: both cards are bare .domain-promo-box. fa-server (hosting) vs fa-globe (transfer) is the one structural difference in the markup — the same :has()-based technique 4S used to distinguish two otherwise-identical .label contexts by a sibling's class. :has() shipped in every evergreen engine well before this project started (Safari 15.4, Mar 2022; Chrome/Edge 105, Aug 2022; Firefox 121, Dec 2023 — the last holdout, itself now nearly two years old), so current browser support is not a live concern; no prior "browser baseline" note exists in this repo to check against — this is that note. Rest/hover/focus only: the CTA is a plain

cart.php?a=view

cart.php?a=add&domain=...

The stock `.sidebar .list-group{font-size:.9em}` (theme.css:10425) is keyed on .sidebar, so it fires on the storefront pages and not on the cart.php ones — the same nav component, two sizes, decided by a class that is present or absent for no reason we control. That split predates the base change above (it was 12.6px vs 14px before, same shape, just smaller and less obvious); raising the base made both ends bigger and the difference easier to see, which is how it surfaced. Pages affected: Renew Services, View Available Addons, Register Domain, Transfer Domain, View Cart. Keyed on .cart-sidebar instead, which is present on every one of them, and carrying the stock rule's own .9em rather than an absolute size — so it resolves against whatever --mh-text-base is (13.5px today) and both paths stay in step if that ever moves. (0,2,0), the same specificity as the stock rule; no repetition used to force a win because none is needed — where the stock rule also fires, both set the identical value, so the tie is immaterial, and where it doesn't, this is the only rule in play. Scoped to .list-group, not to .cart-sidebar as a whole: the panel headings have their own size (theme.css/standard_cart both set .cart-sidebar h3 to 16px) and are not part of this. The .secondary-cart-sidebar column on cart.php?a=view has no .list-group at all — checked — so it's untouched either way. */ .cart-sidebar .list-group { font-size: 0.9em; } /* ========================================================================== 10. UTILITIES ========================================================================== */ /* Bootstrap utility classes ship with !important by design — matching it is required to win at all, not an escalation for a specificity problem (CLAUDE.md hard constraint 6). theme.css:5858-5865, 5986-5987, 9011-9016. */ .bg-primary { background-color: var(--mh-primary) !important; } a.bg-primary:hover, a.bg-primary:focus, button.bg-primary:hover, button.bg-primary:focus { background-color: var(--mh-primary-active) !important; } .border-primary { border-color: var(--mh-primary) !important; } .text-primary { color: var(--mh-primary) !important; } a.text-primary:hover, a.text-primary:focus { color: var(--mh-link-hover) !important; } /* ---- Semantic utilities — theme.css:5878-5925 (.bg-*), 5994-6010 (.border-*), 9027-9077 (.text-*). All three families ship !important by design, so matching it is required to win at all rather than an escalation for a specificity problem (CLAUDE.md constraint 6) — same precedent as .bg-primary above. .text-* uses -ink, not the solid: the solid fails AA as a foreground for success (3.42 on white) and warning (3.77). Applied uniformly across all four roles rather than only the two that fail, so the utility behaves predictably — a deliberate deviation from solid-to-solid, logged in the README. Hover takes -active throughout. .bg-* mirrors the .btn-* base fills so --mh-text-inverse stays legible on them. .border-* takes the plain solid: a border carries no text, so no ratio applies, and the solid is the role's identity colour. */ .text-success { color: var(--mh-success-ink) !important; } .text-warning { color: var(--mh-warning-ink) !important; } .text-danger { color: var(--mh-danger-ink) !important; } .text-info { color: var(--mh-info-ink) !important; } a.text-success:hover, a.text-success:focus { color: var(--mh-success-active) !important; } a.text-warning:hover, a.text-warning:focus { color: var(--mh-warning-active) !important; } a.text-danger:hover, a.text-danger:focus { color: var(--mh-danger-active) !important; } a.text-info:hover, a.text-info:focus { color: var(--mh-info-active) !important; } .bg-success { background-color: var(--mh-success-active) !important; } .bg-warning { background-color: var(--mh-warning-ink) !important; } .bg-danger { background-color: var(--mh-danger) !important; } .bg-info { background-color: var(--mh-info) !important; } a.bg-success:hover, a.bg-success:focus, button.bg-success:hover, button.bg-success:focus { background-color: var(--mh-success-ink) !important; } a.bg-warning:hover, a.bg-warning:focus, button.bg-warning:hover, button.bg-warning:focus { background-color: var(--mh-warning-active) !important; } a.bg-danger:hover, a.bg-danger:focus, button.bg-danger:hover, button.bg-danger:focus { background-color: var(--mh-danger-hover) !important; } a.bg-info:hover, a.bg-info:focus, button.bg-info:hover, button.bg-info:focus { background-color: var(--mh-info-hover) !important; } .border-success { border-color: var(--mh-success) !important; } .border-warning { border-color: var(--mh-warning) !important; } .border-danger { border-color: var(--mh-danger) !important; } .border-info { border-color: var(--mh-info) !important; } /* .text-muted — theme.css:9079, #6c757d. A cool grey on 37 elements across 31 templates, and brand/tokens.css warns explicitly that cool greys look dirty against the warm paper background. 6.19:1 on paper, 6.52:1 on white. Parent carries !important, so this must too. */ .text-muted { color: var(--mh-text-muted) !important; }