/* ============================================================ BALA Woo / Dokan / Essential-Addons reskin — SEED Redesign step A6. Round one does NOT rebuild WooCommerce or Dokan screens (ADR-0006 decision 2: "Woo/Dokan functional screens keep native pipelines, reskinned via CSS"). This file maps those native surfaces onto the BALA tokens so they stop looking like a different website once the chrome flag is ON, and fixes the mobile defects Rev-2 names. It loads LAST of the three BALA stylesheets. ── EVERY selector is prefixed `body.bala-chrome` ────────────────────────── Two reasons, both load-bearing: 1. It makes the spec's Top Risk #1 mitigation REAL. That risk is "design-system global CSS breaks checkout/dashboard" and the named escape hatch is the `body.bala-chrome` class. An earlier draft of this file only *described* that hatch in a comment while every selector was global — the A6 front-end and QA reviews both caught it. Enqueue-gating alone is not the same protection: a stale CDN/browser copy served to a flag-OFF request, or any later change to the enqueue logic, would have applied all of this unconditionally. 2. It wins the cascade fights this file must win. `css/custom-overrides.css` loads BEFORE this file, is kept verbatim in round one, and contains 53 `!important` declarations plus element+class selectors that would otherwise beat bare-class rules here. Prefixing raises specificity enough to take the plain collisions; the four that use `!important` are handled individually below and each cites the exact colliding rule. ── Verification status of the selectors, stated honestly ───────────────── VERIFIED against the live saved page scrapes (2026-07-24): `.woocommerce`, `.woocommerce-page`, `.woocommerce-form-register` and its `.input-text` fields, `.eael-login-form-wrapper`, and the Woo notice/button/price classes. NOT VERIFIED, retained deliberately: `.eael-register-form-wrapper` — the QA pass found no such class in any saved DOM (the live Register page uses Woo's native register form, which the `.woocommerce-page … .input-text` rules already cover), but it could not rule out an AJAX-injected register tab. Kept as harmless insurance, marked so nobody re-derives the doubt. `.dokan-dashboard` and friends are also unverified — no `/dashboard/` page was ever scraped into this repo. Both go on the B3 checklist rather than being asserted here. ⚠ SEED, not finished. Deliberately conservative: typography, colour, controls, and the mobile fixes — nothing that reflows Woo's layout. The real selector sweep happens at Track B step B3, the first time anyone sees these screens under the new chrome. Expect this file to grow there; that is the plan, not a gap. ⚠ The Stripe card fields (number/expiry/CVC) render in a cross-origin iframe and are unreachable by any host-page CSS — a hard boundary of a CSS-only reskin, not an omission here. ============================================================ */ /* ---------- Typography inheritance ---------- */ /* Woo and Dokan both ship their own font stacks; pull them onto ours. */ body.bala-chrome .woocommerce, body.bala-chrome .woocommerce-page, body.bala-chrome .dokan-dashboard, body.bala-chrome .dokan-store, body.bala-chrome .eael-login-form-wrapper, body.bala-chrome .eael-register-form-wrapper { font-family: "IBM Plex Sans", "Plex Sans Fallback", system-ui, -apple-system, Helvetica, Arial, sans-serif; color: var(--ink); } body.bala-chrome .woocommerce h1, body.bala-chrome .woocommerce h2, body.bala-chrome .woocommerce h3, body.bala-chrome .woocommerce-page h1, body.bala-chrome .woocommerce-page h2, body.bala-chrome .woocommerce-page h3, body.bala-chrome .dokan-dashboard h1, body.bala-chrome .dokan-dashboard h2, body.bala-chrome .dokan-dashboard h3 { font-family: "Newsreader", "Newsreader Fallback", Georgia, "Times New Roman", serif; font-weight: 500; letter-spacing: -0.01em; } /* ---------- Buttons ---------- */ body.bala-chrome .woocommerce a.button, body.bala-chrome .woocommerce button.button, body.bala-chrome .woocommerce input.button, body.bala-chrome .woocommerce #respond input#submit, body.bala-chrome .woocommerce a.button.alt, body.bala-chrome .woocommerce button.button.alt, body.bala-chrome .dokan-btn-theme, body.bala-chrome .dokan-btn-default { background: var(--ink); border: 1px solid var(--ink); border-radius: 999px; color: var(--paper); font-family: "IBM Plex Sans", "Plex Sans Fallback", system-ui, -apple-system, Helvetica, Arial, sans-serif; font-size: 14px; font-weight: 500; letter-spacing: 0.01em; padding: 11px 20px; text-decoration: none; transition: background 0.15s ease, border-color 0.15s ease; } /* COLLISION 1 — `custom-overrides.css:120-127` sets the OLD red (#A9002C) with `!important` on `.dokan-btn-theme:hover` (and two sibling selectors). Without matching `!important` here the button would sit in new navy at rest and flip to the OLD red on hover — a button that changes brand palette between its own states. `!important` is used only where an `!important` must be beaten. */ body.bala-chrome .woocommerce a.button:hover, body.bala-chrome .woocommerce button.button:hover, body.bala-chrome .woocommerce input.button:hover, body.bala-chrome .woocommerce #respond input#submit:hover, body.bala-chrome .woocommerce a.button.alt:hover, body.bala-chrome .woocommerce button.button.alt:hover, body.bala-chrome input[type="submit"].dokan-btn-theme:hover, body.bala-chrome a.dokan-btn-theme:hover, body.bala-chrome .dokan-btn-theme:hover, body.bala-chrome .dokan-btn-default:hover { background-color: var(--red) !important; border-color: var(--red) !important; color: var(--paper); } /* Keep destructive/secondary affordances visually distinct from "go". */ body.bala-chrome .woocommerce a.button.wc-forward, body.bala-chrome .woocommerce .cart .button[name="update_cart"] { background: var(--paper); border-color: var(--line-2); color: var(--ink); } /* COLLISION 5 — ELEMENTOR'S OWN WOO WIDGETS OUTRANK THE RESKIN, AND ONLY ON `background-color`. FINDING 329, measured on staging 2026-07-29. `/cart/` and `/checkout/` are not native WooCommerce markup — they are Elementor's `woocommerce-cart` and `woocommerce-checkout-page` widgets (`data-widget_type` confirms it), and Elementor generates per-widget CSS into `post-.css` from each widget's own style controls. The measured winners on staging were: `.elementor-250 .elementor-element.elementor-element-502e5987 .woocommerce .wc-proceed-to-checkout .checkout-button` (0,6,0) --e-global-color-accent `.elementor-250 … .shop_table .button` (0,5,0) --e-global-color-86b4fcd `.elementor-246 … .woocommerce button.button` (0,4,0) --e-global-color-86b4fcd `--e-global-color-accent` is `#A9002C`, the OLD kit red. `--e-global-color-86b4fcd` is `#02010100` — alpha `00`, i.e. FULLY TRANSPARENT. Our `color` declarations kept winning, so the results were navy on old-red at 1.68:1 ("Proceed to Checkout") and near-white on cream, effectively invisible ("Apply coupon", "Save all for later", and checkout's coupon "Apply"). WCAG 1.4.3 failures on the money path. ⚠ WHY ONLY THE BACKGROUND MOVED, and why this was hard to see: the rules above use the `background` SHORTHAND. A higher-specificity rule setting the `background-color` LONGHAND replaces just that component and leaves `color` untouched — so the DevTools Styles pane shows our declaration NOT struck through while the button still renders the wrong colour. Nothing looks overridden. ⚠ "Update Cart" WAS CORRECT ALL ALONG, BY ONE POINT. `.cart .button[name="update_cart"]` above is (0,5,1) against Elementor's (0,5,0). One extra element in a selector is the whole difference between the single control on this page that worked and the three that did not. ⚠ NO STAGING IDs BELOW, DELIBERATELY. `elementor-250`, `502e5987`, `elementor-246` and `1983834` are THIS install's page and widget ids; live's cart and checkout pages carry different ones. A fix written against them would measure green on staging and do nothing whatever on live — the "works here, silent there" trap. Every selector below uses only Elementor's generic widget classes, and each was confirmed to reach its target with `element.matches()` on staging before being written here. */ /* Cart widget, the table action row: "Apply coupon", "Save all for later". (0,5,2) against Elementor's (0,5,0). */ body.bala-chrome .elementor-element.elementor-widget-woocommerce-cart .shop_table button.button, body.bala-chrome .elementor-element.elementor-widget-woocommerce-cart .shop_table a.button, body.bala-chrome .elementor-element.elementor-widget-woocommerce-cart .shop_table input.button { background: var(--ink); border-color: var(--ink); color: var(--paper); } /* "Update Cart" keeps the secondary treatment it already had — without this the rule above would repaint the one control on the page that was never broken. (0,6,2) via the attribute selector, so it outranks the block above. */ body.bala-chrome .elementor-element.elementor-widget-woocommerce-cart .shop_table button.button[name="update_cart"], body.bala-chrome .elementor-element.elementor-widget-woocommerce-cart .shop_table input.button[name="update_cart"] { background: var(--paper); border-color: var(--line-2); color: var(--ink); } /* Cart widget, "Proceed to Checkout". (0,6,2) against Elementor's (0,6,0). ⚠ FILLED PRIMARY BY DECISION (Brandon, 2026-07-29) — cream on navy, 12.75:1. The generic `a.button.wc-forward` rule above treats all forward-navigation as secondary, which swept the primary money CTA in with "Continue shopping" and "View cart" and left the most important button on the payment path as the quietest thing on the page. Contrast is identical either way (same token pair, inverted), so this is hierarchy, not accessibility. */ body.bala-chrome .elementor-element.elementor-widget-woocommerce-cart .woocommerce .wc-proceed-to-checkout a.checkout-button { background: var(--ink); border-color: var(--ink); color: var(--paper); } /* The same decision on NATIVE Woo markup, so it survives the cart page being rebuilt without the Elementor widget. Equal specificity to `a.button.wc-forward` above (0,4,2) and declared after it, so it wins on order — `.checkout-button` becomes primary while "Continue shopping" and "View cart" keep the secondary treatment that rule intends. */ body.bala-chrome .woocommerce .wc-proceed-to-checkout a.checkout-button { background: var(--ink); border-color: var(--ink); color: var(--paper); } /* Checkout widget, the coupon "Apply" button — same transparent-background defect. (0,5,2) against Elementor's (0,4,0). ⚠ `#place_order` is deliberately NOT touched. It renders white on `#A9002C` at 7.71:1, which PASSES 1.4.3, and its own winner is (2,3,0) — two ids. Repainting it is a palette decision (B3-8 / unit (iii) kit colours), not a contrast fix, and folding it in here would expand a WCAG remedy into the payment button before a cutover. */ body.bala-chrome .elementor-element.elementor-widget-woocommerce-checkout-page .woocommerce button.button, body.bala-chrome .elementor-element.elementor-widget-woocommerce-checkout-page .woocommerce button.woocommerce-button { background: var(--ink); border-color: var(--ink); color: var(--paper); } /* FINDING 338 — TOUCH TARGETS ON THE MONEY PATH. Measured at 360px on staging 2026-07-30: "Proceed to Checkout" 37px, "Apply coupon" 37px, "Update Cart" 43px, against Rev-2's >=44px (and WCAG 2.5.5 AAA, which sets the same number). ⚠ All three are already FULL-WIDTH blocks at mobile via the `max-width: 980px` rule further down — they are wide, not small, so this is purely vertical size and costs no horizontal room. `min-height` rather than more padding: padding would also push the text off-centre on the ``, which Woo renders as a block. The flex centring keeps the label optically centred at any height without disturbing the full-width layout. */ body.bala-chrome .elementor-element.elementor-widget-woocommerce-cart .shop_table button.button, body.bala-chrome .elementor-element.elementor-widget-woocommerce-cart .shop_table a.button, body.bala-chrome .elementor-element.elementor-widget-woocommerce-cart .shop_table input.button, body.bala-chrome .elementor-element.elementor-widget-woocommerce-cart .woocommerce .wc-proceed-to-checkout a.checkout-button, body.bala-chrome .elementor-element.elementor-widget-woocommerce-checkout-page .woocommerce button.button { min-height: 44px; } /* `` cannot be a flex container, so it is excluded here and relies on `min-height` alone — which centres its value natively. */ body.bala-chrome .elementor-element.elementor-widget-woocommerce-cart .shop_table button.button, body.bala-chrome .elementor-element.elementor-widget-woocommerce-cart .shop_table a.button, body.bala-chrome .elementor-element.elementor-widget-woocommerce-cart .woocommerce .wc-proceed-to-checkout a.checkout-button, body.bala-chrome .elementor-element.elementor-widget-woocommerce-checkout-page .woocommerce button.button { display: inline-flex; align-items: center; justify-content: center; } /* ⚠ The `max-width: 980px` block below sets `display: block` on the checkout button to make it full-width. `inline-flex` above would beat it on source order, so the mobile rule is restated here at higher specificity as `flex` — full width AND centred, instead of one or the other. Same class of ordering trap as finding 326; caught by writing it down rather than by a re-test. */ @media (max-width: 980px) { body.bala-chrome .elementor-element.elementor-widget-woocommerce-cart .woocommerce .wc-proceed-to-checkout a.checkout-button, body.bala-chrome .elementor-element.elementor-widget-woocommerce-cart .shop_table button.button, body.bala-chrome .elementor-element.elementor-widget-woocommerce-checkout-page .woocommerce button.button { display: flex; width: 100%; } } /* ⚠ HOVER MUST FOLLOW AT HIGHER SPECIFICITY — finding 326's placement lesson, applied on purpose this time instead of rediscovered. The generic `:hover` block at :103-116 is (0,4,2), and every base rule above now outranks it, so without these six selectors all four controls would silently stop responding to hover. `var(--red)` on `var(--paper)` is 6.20:1, so the hover state passes 1.4.3 too. No `!important`: `custom-overrides.css`'s `!important` blocks are scoped to `#pms_*` forms, `.dokan-btn-theme` and `.onsale`, none of which match a cart or checkout button. Checked before writing rather than assumed — unlike COLLISION 1. */ body.bala-chrome .elementor-element.elementor-widget-woocommerce-cart .shop_table button.button:hover, body.bala-chrome .elementor-element.elementor-widget-woocommerce-cart .shop_table a.button:hover, body.bala-chrome .elementor-element.elementor-widget-woocommerce-cart .shop_table input.button:hover, body.bala-chrome .elementor-element.elementor-widget-woocommerce-cart .shop_table button.button[name="update_cart"]:hover, body.bala-chrome .elementor-element.elementor-widget-woocommerce-cart .woocommerce .wc-proceed-to-checkout a.checkout-button:hover, body.bala-chrome .elementor-element.elementor-widget-woocommerce-checkout-page .woocommerce button.button:hover { background: var(--red); border-color: var(--red); color: var(--paper); } /* ---------- Notices ---------- */ body.bala-chrome .woocommerce-message, body.bala-chrome .woocommerce-info, body.bala-chrome .woocommerce-error, body.bala-chrome .dokan-alert { border-radius: 12px; border: 1px solid var(--line-2); background: var(--cream-2); color: var(--ink); font-size: 14px; } body.bala-chrome .woocommerce-message { border-left: 3px solid var(--gold); } body.bala-chrome .woocommerce-info { border-left: 3px solid var(--ink-soft); } body.bala-chrome .woocommerce-error { border-left: 3px solid var(--red); } /* COLLISION 2 — `custom-overrides.css:438-440` sets the old red (#B22222) with `!important` on `body.e-wc-info-notice .woocommerce-info .button:hover`. */ body.bala-chrome .woocommerce-info .button:hover { color: var(--red) !important; } /* ---------- Form controls ---------- */ /* Applies to checkout, account, vendor dashboard, Woo's native register form, and the EA login widget. */ body.bala-chrome .woocommerce form .form-row input.input-text, body.bala-chrome .woocommerce form .form-row textarea, body.bala-chrome .woocommerce form .form-row select, body.bala-chrome .woocommerce-page form .form-row input.input-text, body.bala-chrome .woocommerce-form-register input.input-text, body.bala-chrome .dokan-form-control, body.bala-chrome .eael-login-form-wrapper input[type="text"], body.bala-chrome .eael-login-form-wrapper input[type="email"], body.bala-chrome .eael-login-form-wrapper input[type="password"], body.bala-chrome .eael-register-form-wrapper input[type="text"], body.bala-chrome .eael-register-form-wrapper input[type="email"], body.bala-chrome .eael-register-form-wrapper input[type="password"] { background: var(--paper); border: 1px solid var(--line-2); border-radius: 10px; color: var(--ink); font-family: inherit; padding: 11px 13px; } /* COLLISION 3 (specificity, not `!important`) — `custom-overrides.css:75` uses `select.dokan-form-control` (0,1,1), which beat the bare `.dokan-form-control` (0,1,0) above, leaving fields moved to new padding in the same form. The `body.bala-chrome` prefix makes this rule (0,2,1) and takes it. Listed explicitly so the intent survives a later refactor. */ body.bala-chrome select.dokan-form-control { padding: 11px 13px; } body.bala-chrome .woocommerce form .form-row input.input-text:focus, body.bala-chrome .woocommerce form .form-row textarea:focus, body.bala-chrome .woocommerce form .form-row select:focus, body.bala-chrome .woocommerce-form-register input.input-text:focus, body.bala-chrome .dokan-form-control:focus, body.bala-chrome .eael-login-form-wrapper input:focus, body.bala-chrome .eael-register-form-wrapper input:focus { border-color: var(--ink); outline: 2px solid rgba(22, 49, 90, 0.15); outline-offset: 1px; } /* ---------- Prices ---------- */ body.bala-chrome .woocommerce .price, body.bala-chrome .woocommerce span.amount, body.bala-chrome .dokan-dashboard .dokan-w4 .amount { color: var(--ink); font-family: "IBM Plex Mono", "Plex Mono Fallback", ui-monospace, Menlo, monospace; font-weight: 500; } body.bala-chrome .woocommerce del span.amount { color: var(--ink-soft); } body.bala-chrome .woocommerce ins span.amount { color: var(--red); text-decoration: none; } /* ---------- Dokan dashboard shell ---------- */ body.bala-chrome .dokan-dashboard .dokan-dashboard-wrap { background: var(--paper); } body.bala-chrome .dokan-dashboard .dokan-dash-sidebar ul.dokan-dashboard-menu > li.active, body.bala-chrome .dokan-dashboard .dokan-dash-sidebar ul.dokan-dashboard-menu > li:hover { background: var(--ink); } body.bala-chrome .dokan-dashboard .dokan-dash-sidebar ul.dokan-dashboard-menu > li.active > a, body.bala-chrome .dokan-dashboard .dokan-dash-sidebar ul.dokan-dashboard-menu > li:hover > a { color: var(--paper); } /* COLLISION 4 — `custom-overrides.css:52-55` sets the old red (#B22222) with `!important` on submenu `li:hover`/`li.current`. Left unmatched, the sidebar would show new navy on top-level items and old red on submenu items at once. */ body.bala-chrome .dokan-dashboard .dokan-dash-sidebar ul.dokan-dashboard-menu li ul.navigation-submenu li:hover, body.bala-chrome .dokan-dashboard .dokan-dash-sidebar ul.dokan-dashboard-menu li ul.navigation-submenu li.current { background-color: var(--ink-2) !important; } /* ============================================================ [REV2] Customer-facing mobile fixes Spec Rev-2 A6 bullet: "customer-facing Woo mobile rules in bala-woo-reskin.css (no h-scroll @360; inputs >=16px — kills iOS focus-zoom)". Scope note (reconciling with Rev-2's "vendor-dashboard mobile → BACKLOG"): the Dokan-touching rules below are baseline mobile hygiene — legible input sizes, tables that scroll inside their own box, thumb-sized rows. They are NOT the deferred "redesign the vendor dashboard for phones" effort, which stays backlog. ============================================================ */ /* iOS zooms the viewport when a focused input's font-size is under 16px, which on checkout reads as the page lurching sideways mid-purchase. This is the single highest-value mobile rule in this file. */ @media (max-width: 980px) { body.bala-chrome .woocommerce input[type="text"], body.bala-chrome .woocommerce input[type="email"], body.bala-chrome .woocommerce input[type="tel"], body.bala-chrome .woocommerce input[type="number"], body.bala-chrome .woocommerce input[type="password"], body.bala-chrome .woocommerce input[type="search"], body.bala-chrome .woocommerce textarea, body.bala-chrome .woocommerce select, body.bala-chrome .woocommerce-page input[type="text"], body.bala-chrome .woocommerce-page input[type="email"], body.bala-chrome .woocommerce-page input[type="tel"], body.bala-chrome .woocommerce-page input[type="password"], body.bala-chrome .dokan-form-control, body.bala-chrome .eael-login-form-wrapper input, body.bala-chrome .eael-register-form-wrapper input, /* Select2 injects its own search field, which the selectors above never match. Confirmed in use by this theme's own vendor surfaces (includes/product/wholesale.php, includes/dokan-setup-wizard-override.php, dokan/settings/store-form.php) and likely on Woo's checkout country/state fields — verify at B3. */ body.bala-chrome .select2-container .select2-search__field, body.bala-chrome .select2-container .select2-selection__rendered { font-size: 16px; } /* Woo's cart/order tables are the classic 360px horizontal-scroll offender. Let the table scroll inside its own container rather than pushing the page sideways — the page must never scroll horizontally. ⚠ HIGHEST-PRIORITY UNVERIFIED CLAIM IN THIS STEP: no cart or checkout page has ever been scraped into this repo, so the effect of `display:block` on a Woo cart table — specifically the `` row that carries Update-cart/coupon, and the `.cart_totals` label/value pairs — is reasoned, not observed. It is a widely-used responsive-table technique and browsers generate the anonymous table boxes that preserve colspan, but this sits on a money path and must be OBSERVED at B3 before Track B exit. */ body.bala-chrome .woocommerce table.shop_table, body.bala-chrome .woocommerce table.cart, body.bala-chrome .woocommerce-orders-table, body.bala-chrome .dokan-table { display: block; max-width: 100%; overflow-x: auto; -webkit-overflow-scrolling: touch; } /* Full-width primary actions read better than centred pills on a phone. */ body.bala-chrome .woocommerce .checkout-button, body.bala-chrome .woocommerce #place_order, body.bala-chrome .woocommerce .wc-proceed-to-checkout .button { display: block; width: 100%; text-align: center; } /* Thumb-sized targets on the quantity stepper and account nav. */ body.bala-chrome .woocommerce .quantity input.qty, body.bala-chrome .woocommerce-MyAccount-navigation a { min-height: 44px; } }