/**
 * CLASSIC-VISUAL-V1R — customer-only visual extension layer.
 *
 * This stylesheet is an extension layer for normal web customers only, on
 * /order-online/ and the real Classic checkout. It loads after
 * wolt-light.css (see the `sb-template-wolt-light` dependency in
 * takeawayboost_enqueue_shop_styles()) and must never target kiosk mode —
 * every selector below is scoped behind a source-verified, non-kiosk
 * controlled-page body class:
 *   body.tb-page-controlled-order-online:not(.tb-kiosk-page)
 *   body.tb-page-controlled-checkout:not(.tb-kiosk-page)
 *
 * Only measured, non-structural improvements belong in this file — rules
 * that were checked live against the actual computed styles already
 * rendering on these routes and shown to change something a customer can
 * perceive. It intentionally does not restate values that already render
 * correctly (that would be duplicate, not foundation), and it does not
 * declare a font-family: no Inter font resource is loaded anywhere in this
 * plugin or theme (no @font-face, no font request), so the existing,
 * already-correct system font stack is left to keep winning on its own.
 *
 * Future visual phases may extend this file incrementally, following the
 * same rule: add only what live measurement proves is missing or broken.
 */

/* ---- Tokens actually consumed below (scoped to the routes that use them) ---- */
body.tb-page-controlled-order-online:not(.tb-kiosk-page) {
    --tbcf-focus-color: #1b9bd8;
}

/* ---- Category navigation: keyboard focus was previously a near-invisible
   box-shadow. Measured live via genuine sequential Tab navigation, repeated
   across multiple sessions: this rule reliably wins and renders the intended
   solid outline — a confirmed, reproducible improvement. ---- */
body.tb-page-controlled-order-online:not(.tb-kiosk-page) .sb-order-menu-nav a:focus-visible {
    outline: 2px solid var(--tbcf-focus-color);
    outline-offset: 2px;
}

/* A matching rule for the product-card triggers (.sb-product-drawer-trigger,
   shared by the card image/title/CTA links) was evaluated and prototyped, but
   removed: real sequential-Tab measurement showed its computed outline-color
   and outline-width did not match this rule's authored values even though the
   custom property resolved correctly and no other author rule matched — an
   unexplained, non-reproducible result that fails this file's "only measured,
   reliable effect" bar. It is not reintroduced without a clean explanation. */

/* ---- Checkout disabled/read-only field cursor. Measured live: no existing
   rule set a disabled-state cursor for .input-text, so the browser default
   ("text") persisted even when a field was disabled or read-only. The
   equivalent color change was tested and does not win against an existing
   rule, so it is not included here. Checkout's normal focus treatment
   (amber border/box-shadow ring in wolt-light.css) and the Place Order
   button's focus/disabled states were both measured and are already
   handled well there — nothing further is added for either in this file. */
body.tb-page-controlled-checkout:not(.tb-kiosk-page) .woocommerce-checkout .input-text:disabled,
body.tb-page-controlled-checkout:not(.tb-kiosk-page) .woocommerce-checkout .input-text[readonly] {
    cursor: not-allowed;
}

/**
 * CLASSIC-VISUAL-V2 — desktop/laptop ordering-page and product-card polish.
 *
 * Scoped to the same verified, non-kiosk order-online route, additionally
 * gated to the desktop/laptop range only. Live measurement across
 * 1440/1280/1024/900/861/860/800/769/768/761/760px showed the ordering grid
 * renders its two-column desktop layout from 769px upward (only per-card
 * image sizing differs slightly around 860px), while 768px and below is a
 * genuinely different single-column layout — so min-width:769px correctly
 * captures "desktop/laptop" and leaves 768px and below untouched, matching
 * the same boundary already proven safe for the native product drawer in
 * Phase H1R.
 */
@media (min-width: 769px) {
    /* Ordering-page shell rhythm: measured live, the gap between the category
       nav and each menu-section heading was 54px (the nav's own 24px
       margin-bottom plus the section's 30px margin-top stacking) — nearly
       2.5x the 22px gap between the hero card and the nav, and the 14px gap
       between a section heading and its own grid. Reducing only the
       section's margin-top brings every section transition to ~32px, much
       closer to the rest of the shell's rhythm. margin-bottom (which also
       governs the gap below each section) and scroll-margin-top (the
       sticky-scroll offset) are both left untouched. Needs !important: the
       existing declaration (wolt-light.css, ".sb-order-menu-section
       { margin-block: 30px !important }") is !important, so a normal-weight
       override cannot win regardless of specificity — confirmed live
       (without !important the value stayed 30px). */
    body.tb-page-controlled-order-online:not(.tb-kiosk-page) .sb-order-menu-section {
        margin-top: 8px !important;
    }

    /* Category chips: measured live, each chip had 7px 16px padding inside a
       36px-min-height pill with only an 8px gap between chips, leaving the
       chip row visibly narrower than its container (895px of chips inside a
       1074px-wide bar). Widening padding and gap gives the row a more
       comfortable, premium feel without changing chip order, the underlying
       links, container width, or scroll behavior; min-height stays untouched
       so the pill height is unaffected. Needs !important for the same
       reason: the existing gap/padding declarations (wolt-light.css,
       ".sb-order-menu-nav { gap: 8px !important }" and ".sb-order-menu-nav a
       { padding: 7px 16px !important }") are !important — confirmed live
       that neither changes without !important. */
    body.tb-page-controlled-order-online:not(.tb-kiosk-page) .sb-order-menu-nav {
        gap: 10px !important;
    }

    body.tb-page-controlled-order-online:not(.tb-kiosk-page) .sb-order-menu-nav a {
        padding: 9px 20px !important;
    }
}

/**
 * CLASSIC-VISUAL-V3 — mobile/tablet ordering-page and category-navigation polish.
 *
 * Scoped to the same verified, non-kiosk order-online route, gated to the
 * complementary mobile/tablet range (max-width: 768px), the exact inverse
 * boundary of the V2 desktop block above. Live measurement at
 * 768/761/760/600/480/390/360px showed every value below is identical across
 * the whole range (only per-card image/font sizing differs slightly under
 * 600px, which V3 does not touch), so a single shared block — not extra
 * sub-breakpoints — correctly covers both "tablet" and "mobile".
 */
@media (max-width: 768px) {
    /* Ordering-page shell rhythm: the same double-margin pattern V2 fixed on
       desktop exists on mobile too, with its own baseline values. Measured
       live, the category nav's own margin-bottom (18px) stacks with the
       section's margin-top (30px), for a 48px nav-to-heading gap — roughly
       4-5x every other measured rhythm unit on this route (the section
       heading's own 10px margin-bottom, the 10px heading-to-grid gap, the
       12px product-grid gap). Reducing only the section's margin-top to
       10px matches that existing 10px unit and brings the nav-to-heading
       gap down to 28px; margin-bottom (which also governs the gap below
       each section, together with the sections container's own gap) is left
       untouched, matching the V2 precedent. Needs !important: confirmed
       live, the existing declaration (wolt-light.css, ".sb-order-menu-section
       { margin: 30px 0 !important }") is !important and unguarded — the same
       source rule V2 already overrides for desktop — so a normal-weight
       override cannot win at any mobile/tablet width (confirmed live:
       without !important the value stayed 30px). */
    body.tb-page-controlled-order-online:not(.tb-kiosk-page) .sb-order-menu-section {
        margin-top: 10px !important;
    }

    /* Category navigation scroll affordance: the chip row is horizontally
       scrollable (overflow-x: auto, confirmed live) but carried no visual
       cue that more categories exist off-screen — measured live, up to
       516px of the 858px-wide chip row is hidden beyond the viewport at
       360px width, with zero indication a user can scroll to reach it. This
       adds a standard, functional, CSS-only edge-fade cue: two gradient
       "cover" layers (background-attachment: local) scroll together with
       the chip content and exactly hide the two gradient "shadow" layers
       (background-attachment: scroll, fixed to the visible edges) whenever
       that edge is already fully scrolled into view. Verified live by
       driving nav.scrollLeft directly: the right-edge fade is visible at
       the start and middle of the row and disappears exactly at the true
       end; the left-edge fade is absent at the start and appears once
       scrolled away from it. It never intercepts pointer events (a
       background paints behind content, chips remain fully clickable) and
       adds no layout width (confirmed: zero page-level horizontal overflow
       before and after). The two solid-white cover layers match the nav's
       own already-white computed background-color exactly, so no
       background-color is restated — only background-image and its
       required companion sub-properties (repeat/position/size/attachment,
       needed to compose and position the four layers) are set. Needs
       !important on all five: the existing declaration (wolt-light.css,
       ".sb-order-menu-nav { background: var(--sb-surface) !important; ... }")
       is a `background` shorthand, and a shorthand's !important applies to
       every sub-property it resets — including background-image,
       -repeat, -position, -size and -attachment, all reset to their
       initial values with !important as a side effect of that one
       declaration. Confirmed live: without !important on all five, the
       computed background-image stayed "none". */
    body.tb-page-controlled-order-online:not(.tb-kiosk-page) .sb-order-menu-nav {
        background-image:
            linear-gradient(to right, #ffffff 60%, rgba(255, 255, 255, 0) 100%),
            linear-gradient(to left, #ffffff 60%, rgba(255, 255, 255, 0) 100%),
            linear-gradient(to right, rgba(15, 23, 42, 0.16), rgba(15, 23, 42, 0)),
            linear-gradient(to left, rgba(15, 23, 42, 0.16), rgba(15, 23, 42, 0)) !important;
        background-repeat: no-repeat !important;
        background-position: left center, right center, left center, right center !important;
        background-size: 22px 100%, 22px 100%, 10px 100%, 10px 100% !important;
        background-attachment: local, local, scroll, scroll !important;
    }
}

/**
 * CLASSIC-VISUAL-V4 — customer product drawer and add-ons polish.
 *
 * Scoped to the same verified, non-kiosk order-online route. Source
 * inspection (assets/js/sb-flow.js, openNativeProductDrawerOrFallback())
 * confirms the native drawer (.sb-native-product and its descendants,
 * rendered client-side from an AJAX response) is what customers actually
 * use on every normal Order Online product; the iframe fallback
 * (.sb-single-product / .sb-product-drawer__frame) only activates on a
 * fetch failure or missing product id, which does not occur in this
 * environment, so it could not be reached for live validation. Every V4
 * selector below targets only .sb-native-product/.sb-native-addon-*
 * classes, which the iframe fallback's markup never contains, so V4 cannot
 * affect it regardless.
 *
 * wolt-light.css already gives the drawer a full, customer-scoped desktop
 * polish pass (min-width:769px: 16px header/section radii, a 3-column
 * grid option layout, a warm-cream selected-option fill, 26x26px
 * inputs, etc.). No equivalent customer-scoped block exists for
 * mobile/tablet (max-width:768px) anywhere in wolt-light.css — confirmed
 * by grep: every customer-scoped ".sb-native-*" rule in that file sits
 * inside the one min-width:769px block. Below 769px, customers fall back
 * to the same generic/shared rules kiosk also uses, which is measurably
 * plainer in exactly the ways V4 addresses below.
 */

/* Add-on option focus-visible: measured live via genuine sequential Tab
   navigation, no rule anywhere in wolt-light.css gives
   .sb-native-addon-option__input its own focus-visible treatment (only
   the qty input, the optional-group toggle button, and the Add to Cart
   button have one) — the radio/checkbox falls back to the browser's
   plain ~1px default outline on a small control, an easy-to-miss cue for
   keyboard users choosing between add-on options. This applies equally
   at every width (not a mobile-only gap), so it is a shared rule, not
   gated to a breakpoint. It reuses the existing --tbcf-focus-color token
   from the V1R category-focus fix rather than declaring a new one, and
   targets the whole option row via :has() (a pattern already used by
   this exact selector in wolt-light.css) so the entire clickable card
   gets a visible ring, not just the small native control. No !important
   is used: no existing rule sets outline on this selector, so it wins on
   normal cascade order alone (confirmed live). */
body.tb-page-controlled-order-online:not(.tb-kiosk-page) .sb-product-drawer.is-open .sb-native-addon-option:has(.sb-native-addon-option__input:focus-visible) {
    outline: 2px solid var(--tbcf-focus-color);
    outline-offset: 2px;
}

@media (max-width: 768px) {
    /* Selected add-on option clarity: measured live on both a required
       radio group (Bearnaise Dip) and an optional checkbox group. At
       769px+, wolt-light.css fills a selected/checked option with a warm
       cream background (#fff7cc) alongside its border and shadow change,
       making the chosen option unmistakable at a glance. Below 769px, the
       equivalent rule (wolt-light.css, unguarded ".sb-native-addon-option
       :hover, :has(input:checked) { border-color...; box-shadow...; }")
       never touches background, so a selected option on mobile/tablet
       stays plain white — confirmed live (before: rgb(255,255,255) on
       both hover and checked; after this rule: rgb(255,247,204), matching
       desktop exactly). This is especially significant for the required
       radio groups every multi-step combo product uses, where a customer
       needs unambiguous confirmation of which option is chosen. Needs
       !important: the competing wolt-light.css rule that also matches
       this exact selector is itself !important (confirmed live: without
       !important here, the background stayed white). */
    body.tb-page-controlled-order-online:not(.tb-kiosk-page) .sb-product-drawer.is-open .sb-native-addon-option:has(.sb-native-addon-option__input:checked) {
        background: #fff7cc !important;
    }

    /* Add-on option input size: measured live, the native radio/checkbox
       control renders at only 13x13px on mobile/tablet (the plain,
       unstyled browser default — no width/height rule exists for
       .sb-native-addon-option__input anywhere in wolt-light.css at this
       range), versus 26x26px at 769px+ where wolt-light.css's desktop
       polish block does size it explicitly. A 13px control is
       measurably harder to see and tap precisely than its 26px desktop
       counterpart. 20px is used rather than copying the 26px desktop
       value: mobile/tablet option rows are narrower and this size keeps
       a comfortable margin below the row's existing 44px min-height
       without requiring any gap/padding change. No !important is used:
       no existing rule sets width/height on this selector at any width,
       so this wins on normal cascade order alone (confirmed live). */
    body.tb-page-controlled-order-online:not(.tb-kiosk-page) .sb-product-drawer.is-open .sb-native-addon-option__input {
        width: 20px;
        height: 20px;
    }
}

/**
 * CLASSIC-VISUAL-V5 — customer cart drawer polish.
 *
 * Scoped to the same verified, non-kiosk order-online route. Source
 * inspection (assets/js/sb-flow.js, renderCartDrawer()) confirms the cart
 * drawer (.sb-cart-drawer and its descendants) is rendered entirely
 * client-side from an AJAX response — not WooCommerce cart fragments, and
 * not shared markup with the product drawer or checkout.
 *
 * wolt-light.css already gives the cart drawer a full, customer-scoped
 * desktop polish pass (min-width:769px: 46px quantity buttons, a styled
 * 42px remove button, a neutral "Continue ordering" button distinct from
 * the yellow checkout button, a styled add-on/variation summary box,
 * etc.). No equivalent customer-scoped block exists for mobile/tablet
 * (max-width:768px) anywhere in wolt-light.css — confirmed by grep: every
 * customer-scoped ".sb-cart-drawer__*" rule in that file sits inside the
 * one min-width:769px block. Below 769px, customers fall back to the same
 * generic/shared rules kiosk also uses at other viewport ranges, which is
 * measurably plainer in exactly the ways V5 addresses below. Kiosk itself
 * has its own separate, already-well-sized cart treatment elsewhere in
 * wolt-light.css (untouched by this phase).
 */
@media (max-width: 768px) {
    /* Quantity button touch target: measured live, the native quantity
       buttons render at only 22-24px on mobile/tablet (wolt-light.css,
       unguarded ".sb-cart-drawer__qty button { width: 22px; height: 22px;
       min-height: 22px !important }" and a later duplicate at 24px),
       versus 46x46px at 769px+ where wolt-light.css's desktop polish
       sizes them explicitly. A ~22px control is measurably below any
       reasonable tap-target size. 38px is used rather than copying the
       46px desktop value: the mobile/tablet qty pill sits inline with the
       remove button in a narrower row, and 38px already more than
       doubles the tappable area without crowding it. Needs !important:
       the existing width/height/min-height declarations are !important
       (confirmed live: without !important the size stayed 22-24px). */
    body.tb-page-controlled-order-online:not(.tb-kiosk-page) .sb-cart-drawer.is-open .sb-cart-drawer__qty button {
        width: 38px !important;
        height: 38px !important;
        min-height: 38px !important;
    }

    /* Remove-control clarity and touch target: measured live, the mobile/
       tablet remove control (wolt-light.css, unguarded ".sb-cart-drawer
       __remove { padding: 0 !important; background: transparent
       !important }") renders as bare red text with a near-zero hit area
       (padding "0px 2px", min-height 30px measured live) — easy to miss
       and hard to tap precisely, unlike desktop's clearly-bounded 42px
       pink button. Reuses the exact background color (#fff1f2) already
       approved and used for this same control at 769px+ in wolt-light.css
       — no new color is introduced. Needs !important: the existing
       background/padding declarations are !important (confirmed live:
       without !important both stayed at their prior values). */
    body.tb-page-controlled-order-online:not(.tb-kiosk-page) .sb-cart-drawer.is-open .sb-cart-drawer__remove {
        background: #fff1f2 !important;
        min-height: 36px !important;
        padding: 8px 10px !important;
    }

    /* Checkout CTA hierarchy: measured live, an unguarded wolt-light.css
       rule ("body .sb-cart-drawer.is-open .sb-cart-drawer__secondary,
       .sb-cart-drawer__checkout { background: #ffcc00 !important; ... }")
       gives the secondary "Continue ordering" button the exact same
       yellow fill as the primary "Go to checkout" button at every width
       it isn't more specifically overridden — and at 769px+ a
       higher-specificity customer rule does override it (to a neutral
       white/bordered look), but no equivalent override exists below
       769px, so mobile/tablet customers see two identically-colored
       buttons with no visual hierarchy between "continue browsing" and
       "pay now". This reuses that exact desktop treatment's background/
       border colors (#ffffff / rgba(15,23,42,0.12)) rather than
       introducing new ones. The checkout button itself is untouched, so
       it remains the sole yellow action. Needs !important: the competing
       unguarded rule is itself !important (confirmed live: without
       !important the background stayed yellow). No color declaration is
       included: the same unguarded rule already sets
       "color: #111827 !important", identical to the desktop value, so
       restating it here would produce no computed-style change (measured
       live: color stays rgb(17, 24, 39) with or without it). */
    body.tb-page-controlled-order-online:not(.tb-kiosk-page) .sb-cart-drawer.is-open .sb-cart-drawer__secondary {
        background: #ffffff !important;
        border: 2px solid rgba(15, 23, 42, 0.12) !important;
    }

    /* Add-on/variation summary readability: measured live, the mobile/
       tablet ".sb-cart-drawer__meta" box (which holds each item's
       selected add-ons/variation text) has no background, border or
       padding at all — just plain inline text — while 769px+ gets a
       distinct, readable card treatment. Reuses the exact desktop values
       (background #f8fafc, border rgba(15,23,42,0.08), radius 12px,
       padding 8px 10px) rather than introducing new colors. No
       !important is used: no existing rule sets background/border/
       padding on this selector at this range (only color/font-size/
       line-height/margin are set elsewhere), so this wins on normal
       cascade order alone (confirmed live). */
    body.tb-page-controlled-order-online:not(.tb-kiosk-page) .sb-cart-drawer.is-open .sb-cart-drawer__meta {
        background: #f8fafc;
        border: 1px solid rgba(15, 23, 42, 0.08);
        border-radius: 12px;
        padding: 8px 10px;
    }
}

/**
 * CLASSIC-VISUAL-V7 — desktop customer checkout and scheduling polish.
 *
 * Scoped to the verified, non-kiosk normal customer checkout route
 * (body.tb-page-controlled-checkout:not(.tb-kiosk-page)), confirmed live:
 * loading /checkout/ with one item in cart renders exactly this body
 * class set (plus tb-pickup-selected/tb-asap-selected etc.), with no
 * tb-kiosk-page class present. Desktop-only: every declaration below is
 * inside @media (min-width: 769px), the same boundary already proven
 * safe in V2/H1R, so 768px and below is provably untouched.
 *
 * V6 confirmed the pickup/delivery/ASAP/preorder/date/time widget
 * (#sb-ordering) exists only inside this checkout form (rendered by
 * class-sb-ordering.php's render_checkout_fields()), never on Order
 * Online — so this phase is where that widget can finally be reached.
 *
 * Source inspection (wolt-light.css) shows checkout already carries an
 * extensive, mature customer-scoped desktop design (a two-column
 * #sb-ordering/customer-details/order-review layout, card surfaces,
 * a working selected-state gradient + hover/focus-visible lift on the
 * pickup/delivery and ASAP/preorder radio labels, a working selected-
 * state highlight on payment methods, a fully-styled invalid-field
 * state, and a dedicated Place Order hover/focus-visible rule) — so
 * only two genuinely measured gaps were found, not a wholesale rebuild:
 * the preorder date/time fields render 6px shorter than every other
 * checkout field, and the payment-method radio has no focus-visible
 * treatment at all (unlike every other interactive control on this
 * page, which already has one).
 */

@media (min-width: 769px) {
    /* The --tbcf-focus-color token from V1R is scoped to the order-online
       body class only, so it does not inherit onto the checkout route.
       Re-declaring the same value under the checkout scope (kept inside
       this same min-width:769px block, since its only consumer is here)
       reuses the established token name/color rather than hard-coding the
       color a second time. */
    body.tb-page-controlled-checkout:not(.tb-kiosk-page) {
        --tbcf-focus-color: #1b9bd8;
    }

    /* Preorder date/time field height consistency: measured live, #sb_order_date
       (a native <input type="date">) and #sb_order_time_slot (a native <select>)
       both render at 42px, while every other checkout field sharing the exact
       same styling rule (name/phone/email/notes) renders at 48px with 12px 16px
       padding — the same wolt-light.css rule group sets background/border/
       radius/font-size identically for all of them, but a separate, more
       specific declaration keeps only these two 6px shorter. This is a
       measurable inconsistency in a priority area (date/time presentation).
       The date input and time select are left otherwise identical to each
       other and to the other fields; only height/padding are aligned. Needs
       !important: the existing min-height/padding declarations for this
       selector are !important (confirmed live: without !important the
       height stayed 42px). */
    body.tb-page-controlled-checkout:not(.tb-kiosk-page) form.checkout #sb-ordering #sb_order_date,
    body.tb-page-controlled-checkout:not(.tb-kiosk-page) form.checkout #sb-ordering #sb_order_time_slot {
        min-height: 48px !important;
        padding: 12px 16px !important;
    }

    /* Payment-method focus-visible: measured live via genuine sequential Tab
       navigation, no rule anywhere in wolt-light.css gives the payment-method
       radio (or its row) a focus-visible treatment — tabbing to an
       unselected gateway shows only the browser's plain ~1px default outline
       on the small native radio, while every other interactive control on
       this page (text fields, textarea, consent checkboxes, the pickup/
       delivery and ASAP/preorder radios, and the Place Order button) already
       has one. Reuses the existing --tbcf-focus-color token from the V1R
       category-focus fix rather than declaring a new one, and targets the
       whole payment row via :has() (the same pattern wolt-light.css already
       uses for this exact row's selected-state highlight) so the entire
       clickable row gets a visible ring, not just the small native control.
       No !important is used: no existing rule sets outline on this
       selector, so it wins on normal cascade order alone (confirmed live). */
    body.tb-page-controlled-checkout:not(.tb-kiosk-page) form.checkout .tb-premium-checkout__payment-card #payment ul.payment_methods > li:has(input[type="radio"]:focus-visible) {
        outline: 2px solid var(--tbcf-focus-color);
        outline-offset: 2px;
    }
}

/**
 * CLASSIC-VISUAL-V8 — mobile and tablet customer checkout polish.
 *
 * Scoped to the same verified, non-kiosk normal customer checkout route as
 * V7 (body.tb-page-controlled-checkout:not(.tb-kiosk-page)), mobile/tablet-
 * only: every declaration below is inside @media (max-width: 768px), so
 * 769px and above (V7's desktop scope) is provably untouched.
 *
 * Live investigation across all seven required widths (768/700/600/480/
 * 430/390/360) found the mobile checkout is, like desktop, already a
 * mature design: card padding/radius, section rhythm, field family
 * (46px height, focus ring), pickup/delivery and ASAP/preorder label
 * focus-visible (a global, non-media-gated wolt-light.css rule already
 * covers these correctly on mobile), totals hierarchy, and consent
 * spacing all measured as already adequate — no changes were made there.
 *
 * Two genuine, confirmed gaps were found and fixed:
 *
 * 1. Payment-method row focus-visible — mirrors the exact V7 desktop
 *    finding, just never carried to mobile: tabbing to a payment method
 *    (confirmed via a real, sequential keyboard Tab walk from the top of
 *    the document, not a programmatic .focus() call) leaves the row's
 *    box-shadow at its resting-card value; no rule anywhere in
 *    wolt-light.css sets outline/box-shadow on this selector for
 *    :focus-visible. Reuses the same --tbcf-focus-color token and :has()
 *    pattern as V7, re-declared here since custom properties do not
 *    cross the min-width:769px scope V7 defined it under.
 *
 * 2. Customer-field invalid-state never renders — confirmed via CSSOM
 *    enumeration of every currently-active rule matching #billing_phone,
 *    #billing_first_name and #billing_email after a real empty-field blur
 *    (which does correctly add the .tb-checkout-field-invalid/
 *    .tb-field-invalid classes): wolt-light.css's own intended red
 *    border/background for these classes is always beaten by an earlier,
 *    unrelated bulk field-styling rule
 *    (`#customer_details input[type="tel"]`, etc.) that happens to carry
 *    one more class in its selector, so among competing !important
 *    declarations it wins on specificity even though it was never meant
 *    to govern the invalid state. This affects every required customer
 *    field, not just phone/email. Needs !important: the competing
 *    declaration is !important, and normal cascade order cannot win
 *    against its higher specificity, so this rule matches the same
 *    #customer_details container plus one extra already-present class
 *    (form.woocommerce-checkout) to be specific enough, and marks each
 *    property !important to match. Confirmed live: without the extra
 *    class the border stayed neutral even with !important; with it,
 *    the intended red border/pink background/red ring all render
 *    correctly, and a currently-valid field is confirmed unaffected.
 */

@media (max-width: 768px) {
    /* The --tbcf-focus-color token is scoped per media block (see V7); this
       is the same value, re-declared for the mobile/tablet checkout scope
       since its only consumer here is the payment-method focus rule below. */
    body.tb-page-controlled-checkout:not(.tb-kiosk-page) {
        --tbcf-focus-color: #1b9bd8;
    }

    /* Payment-method focus-visible: see note 1 above. No !important is used:
       no existing rule sets outline on this selector, so it wins on normal
       cascade order alone (confirmed live via a genuine sequential Tab). */
    body.tb-page-controlled-checkout:not(.tb-kiosk-page) form.checkout .tb-premium-checkout__payment-card #payment ul.payment_methods > li:has(input[type="radio"]:focus-visible) {
        outline: 2px solid var(--tbcf-focus-color);
        outline-offset: 2px;
    }

    /* Customer-field invalid-state restoration: see note 2 above. Needs
       !important on every property: the competing bulk field rule in
       wolt-light.css is !important, and the extra class here
       (form.woocommerce-checkout, already present on the real form) is
       required only to match its specificity — confirmed live this fails
       without both the extra class and !important together. */
    body.tb-page-controlled-checkout:not(.tb-kiosk-page) form.checkout.woocommerce-checkout #customer_details input.tb-checkout-field-invalid,
    body.tb-page-controlled-checkout:not(.tb-kiosk-page) form.checkout.woocommerce-checkout #customer_details select.tb-checkout-field-invalid,
    body.tb-page-controlled-checkout:not(.tb-kiosk-page) form.checkout.woocommerce-checkout #customer_details textarea.tb-checkout-field-invalid {
        border-color: #dc2626 !important;
        background: #fff5f5 !important;
        box-shadow: 0 0 0 3px rgba(220, 38, 38, .12) !important;
    }
}

/**
 * CLASSIC-VISUAL-V9 — customer localization and accessibility closeout.
 *
 * V8 confirmed the checkout invalid-field specificity defect exists at
 * desktop widths too (769px+), reserved for this phase. Live reconfirmed
 * at 769/1024/1440px: #billing_first_name/_phone/_email all keep the
 * neutral rgba(17,24,39,.11) border/rgb(248,250,252) background after a
 * real empty-field blur, for the exact same reason as V8's mobile finding
 * (wolt-light.css's own #customer_details bulk field rule narrowly
 * outranks its own intended invalid-state rule). The V8 fix pattern
 * (the extra .woocommerce-checkout class for specificity) was re-tested
 * live at 1440px and confirmed to work identically at desktop widths, so
 * it is reused verbatim here, only inside min-width:769px instead of
 * V8's max-width:768px. The V7 and V8 sections above are untouched.
 */

@media (min-width: 769px) {
    /* Desktop invalid-field restoration: mirrors V8's mobile fix exactly,
       same three !important declarations for the same reason (the
       competing #customer_details bulk field rule in wolt-light.css is
       !important and unscoped by any media query, so it applies at every
       width; the extra .woocommerce-checkout class is required only to
       match its specificity — confirmed live at 769/1024/1440px). */
    body.tb-page-controlled-checkout:not(.tb-kiosk-page) form.checkout.woocommerce-checkout #customer_details input.tb-checkout-field-invalid,
    body.tb-page-controlled-checkout:not(.tb-kiosk-page) form.checkout.woocommerce-checkout #customer_details select.tb-checkout-field-invalid,
    body.tb-page-controlled-checkout:not(.tb-kiosk-page) form.checkout.woocommerce-checkout #customer_details textarea.tb-checkout-field-invalid {
        border-color: #dc2626 !important;
        background: #fff5f5 !important;
        box-shadow: 0 0 0 3px rgba(220, 38, 38, .12) !important;
    }
}