/* ════════════════════════════════════════════════════════════════════
   suprbad-ux.css — Global WooCommerce UX layer
   Opinionated defaults only — no settings-driven values in this file.
   See docs/ARCHITECTURE.md for the ownership split with
   suprbad-frontend-foundation (which owns the shared --sb-* color/font
   tokens since ADR-002) and suprbad-payment-gateway-failover
   (which owns retry-page title TEXT — this file owns title SPACING only,
   and that spacing rule intentionally applies on the retry page too).
   ════════════════════════════════════════════════════════════════════ */

/* ─── Page-title vertical rhythm ─────────────────────────────────────
   Applies to every WooCommerce page-level heading: Cart, Checkout,
   My Account, Order Received, and the order-pay/retry heading (text content
   on that last one stays owned by suprbad-payment-gateway-failover; this
   rule only governs spacing — see Title Ownership Clarification in the
   architecture doc). Selector covers classic (.entry-title), block-theme
   title block markup (.wp-block-post-title), and the WooCommerce Blocks
   Order Confirmation status heading. The Order Confirmation heading is an
   `<h1>` on this install, not an `<h2>` — confirmed via staging DevTools
   2026-06-24 (Round 4): the original `h2` selector never matched, so this
   rule never actually applied any spacing to Order Received, which is why
   that page's title spacing didn't match Cart/Checkout despite the earlier
   fix. Both tags are kept here defensively in case a future template change
   swaps which heading level is used. */

.woocommerce-page .entry-title,
.woocommerce-account .entry-title,
.woocommerce-cart .entry-title,
.woocommerce-checkout .entry-title,
.woocommerce-order-received .entry-title,
.woocommerce-page .wp-block-post-title,
.woocommerce-order-received .wp-block-post-title,
.wc-block-order-confirmation-status h1,
.wc-block-order-confirmation-status h2 {
  margin-top: 2.5em;
  margin-bottom: 1.25em;
  font-family: var(--sb-font-primary, inherit);
}

/* My Account's heading picks up extra top margin from a block-theme spacing
   preset applied as an inline style attribute, which beats external
   stylesheet rules regardless of cascade order/specificity — !important is
   the only way to actually win against an inline style, so it's used here
   narrowly, scoped to this one selector, rather than widened to the whole
   rule above. STAGING VERIFICATION NEEDED to confirm this is the cause. */

.woocommerce-account .wp-block-post-title {
  margin-top: 2.5em !important;
}

/* Order Received heading: explicitly left-aligned, matching Cart/My Account.
   (Same h1-not-h2 correction as the spacing rule above.) Checkout's heading
   is now also forced left-aligned, per Round 4 — see the Checkout-specific
   rule below, scoped narrowly so it can't reach the retry/order-pay page,
   which intentionally stays centered. */

.woocommerce-order-received .entry-title,
.woocommerce-order-received .wp-block-post-title,
.wc-block-order-confirmation-status h1,
.wc-block-order-confirmation-status h2 {
  text-align: left;
}

/* Checkout heading: left-aligned (Round 4), matching Cart/Order Received.
   Scoped with `:not(.suprbad-pgf-retry)` — the same body class
   suprbad-payment-gateway-failover and CheckoutDensity already use to
   distinguish the retry/order-pay state from a normal checkout — rather than
   guessing WooCommerce's internal order-pay endpoint class name. The retry
   page intentionally stays centered as a deliberately distinct, exceptional
   state; this is the safest selector already established in this plugin for
   making that distinction. */

.woocommerce-checkout:not(.suprbad-pgf-retry) .entry-title,
.woocommerce-checkout:not(.suprbad-pgf-retry) .wp-block-post-title {
  text-align: left;
}

/* Checkout heading: horizontal position (Round 5, 2026-06-24). Left-align
   (Round 4) was correct, but the title still didn't share the content
   column's left edge. Root cause: the title lives in its own template
   wrapper (`.site-title-area`, block layout type "constrained"), which
   centers it to the theme's default/narrow content-width token. The
   checkout block's own column is independently centered to a different
   (wider) width. Two elements auto-centered to two different max-widths on
   the same full-width page land at two different left edges by
   construction — the only way to make two auto-centered boxes share a left
   edge at every viewport size is to give them the same max-width, so this
   forces the title to use the theme's wide-content-width token instead of
   its default narrow one.
   BEST-EFFORT, STAGING VERIFICATION NEEDED: the wide-size token is the most
   likely match based on the visual gap observed in the Round 5 screenshot
   (narrow-content-width centering is the standard cause of this exact
   symptom), but it has not been confirmed against the checkout column's own
   Computed-tab max-width. If the edges are still off after this ships, read
   that exact computed value in DevTools and replace the token below with it
   directly rather than re-guessing. */

.woocommerce-checkout:not(.suprbad-pgf-retry) .site-title-area > * {
  max-width: var(--wp--style--global--wide-size, 1200px);
}

/* ─── Checkout email field — blended appearance + discoverability icon ──
   Round 4 gave this field a plain white background to fix "doesn't look
   editable". Round 5 staging feedback explicitly rejected that: the
   blended appearance (matching the visual language of the Shipping/Billing
   address boxes below) was the correct look — the only real problem was
   discoverability, not color contrast. Reverted to the blended background;
   discoverability is now solved with a small pencil icon, not background
   color.

   CSS-only, no JS. The icon is a `::after` pseudo-element on the field's
   real WC Blocks wrapper (`.wc-block-components-text-input`), not a new
   element, so there's no markup to inject. `pointer-events: none` on the
   icon means a click anywhere in its area still falls straight through to
   the real `<input>` beneath it — "click icon to focus the field" needs no
   click handler, it's just where the input already is. `:focus-within` on
   the wrapper fades the icon out while the field has focus and restores it
   on blur, using only the focus state the browser already tracks — no
   JS-side focus/blur listeners. Scoped with `:has(input[type="email"])` so
   only the email field gets the icon; every other checkout text input
   (name, phone, etc.) is untouched.
   Icon position (Round 6, 2026-06-24): vertically centered on the right
   edge of the field. A top-right anchor (matching the "Edit" link position)
   was tried first per the user's first-stated preference, but live testing
   showed vertical-center reads cleaner for this field — per explicit
   follow-up feedback, switched to `top: 50%; transform: translateY(-50%)`. */

#billing_email,
#email[type='email'],
.wc-block-components-text-input input[type='email'],
.wc-block-components-address-form__email input[type='email'] {
  background-color: var(--sb-color-bg, #f7f5f1);
  border: 1px solid var(--sb-color-border, #d4d0ca);
  padding-right: 2.25em;
}

#billing_email:focus,
#email[type='email']:focus,
.wc-block-components-text-input input[type='email']:focus,
.wc-block-components-address-form__email input[type='email']:focus {
  background-color: #fff;
  border-color: var(--sb-color-accent, #1a1a1a);
}

.wc-block-components-text-input:has(input[type='email']),
.wc-block-components-address-form__email:has(input[type='email']) {
  position: relative;
}

.wc-block-components-text-input:has(input[type='email'])::after,
.wc-block-components-address-form__email:has(input[type='email'])::after {
  content: '';
  position: absolute;
  top: 50%;
  right: 0.85em;
  transform: translateY(-50%);
  width: 16px;
  height: 16px;
  pointer-events: none;
  opacity: 0.55;
  transition: opacity 0.15s ease;
  background-repeat: no-repeat;
  background-size: 16px 16px;
  background-image: url("data:image/svg+xml,%3Csvg xmlns='http://www.w3.org/2000/svg' viewBox='0 0 24 24' fill='none' stroke='%237a7772' stroke-width='2' stroke-linecap='round' stroke-linejoin='round'%3E%3Cpath d='M12 20h9'/%3E%3Cpath d='M16.5 3.5a2.121 2.121 0 0 1 3 3L7 19l-4 1 1-4Z'/%3E%3C/svg%3E");
}

.wc-block-components-text-input:has(input[type='email']):focus-within::after,
.wc-block-components-address-form__email:has(input[type='email']):focus-within::after {
  opacity: 0;
}

/* ─── Checkout visual density cleanup ────────────────────────────────
   Removes redundant inner borders/shadows on block-checkout step panels
   while keeping the shipping/billing address boxes (useful structural
   grouping, kept deliberately per the user's stated preference). */

.wc-block-checkout__main .wc-block-components-checkout-step {
  border: none;
  box-shadow: none;
  padding-left: 0;
  padding-right: 0;
}

.wc-block-components-shipping-address-block,
.wc-block-components-billing-address-block,
.wc-block-checkout__shipping-fields,
.wc-block-checkout__billing-fields {
  border: 1px solid var(--sb-color-border, #d4d0ca);
  border-radius: var(--sb-radius-md, 8px); /* F2: shared radius scale */
  padding: 1.5em;
}

/* Round 7, 2026-06-25: the rule above targets the *editable-fields* wrapper.
   Once an address is saved, WC Blocks swaps to its own AddressCard component
   (the collapsed "name / address / Edit link" view in the screenshot) — a
   separate component with its own default border, untouched by the rule
   above, which read visibly darker/heavier than the email field.
   CONFIRMED Round 11, 2026-06-29: DevTools Elements + Computed tab verified
   `.wc-block-components-address-card` is the correct live class, this rule
   is the one applying the border (suprbad-ux.css:205 shown in Styles pane),
   and the computed border (1px solid, color matches --sb-color-border,
   8px radius) renders as intended. */

.wc-block-components-address-card {
  border: 1px solid var(--sb-color-border, #d4d0ca);
  border-radius: var(--sb-radius-md, 8px); /* F2: shared radius scale */
}

/* ─── Global border & spacing scale ──────────────────────────────────
   Lighter, single-weight borders site-wide on cart/checkout panels and
   form rows instead of the mix of heavier default WooCommerce borders. */

.woocommerce-cart-form,
.wc-block-cart__main,
.wc-block-cart-items {
  border-color: var(--sb-color-border, #d4d0ca);
}

.woocommerce form .form-row,
.wc-block-components-text-input {
  margin-bottom: 1.25em;
}

/* ─── Shipping totals row — no all-caps/badge styling ─────────────────
   Copy\CheckoutCopy + assets/js/checkout-copy.js already swap the text
   itself (label forced to "Shipping"; value "Free"/"FREE" swapped to the
   configured word, default "Included") — confirmed correct via staging
   DevTools 2026-06-24, the underlying text content is "Included", not
   "INCLUDED". The visible all-caps was never a text problem: WC core wraps
   the zero-cost value in a `<strong>` and applies
   `.wc-block-components-totals-shipping .wc-block-components-totals-item strong { text-transform: uppercase; }`
   directly to that element. The original rule here targeted the wrapping
   `__value`/`__label` divs, not the `<strong>` itself — `text-transform` is
   inheritable, but a rule that sets the property directly on the `<strong>`
   always wins over an inherited value regardless of specificity elsewhere,
   so the override never had any effect. Fixed by targeting `strong` directly
   with a selector of matching specificity to WC core's, plus `!important`
   since load order between this stylesheet and the Blocks core stylesheet
   isn't guaranteed, so a same-specificity rule could otherwise lose on
   source order alone. */

.wc-block-components-totals-shipping .wc-block-components-totals-item__label strong,
.wc-block-components-totals-shipping .wc-block-components-totals-item__value strong,
.wc-block-components-totals-shipping .wc-block-components-totals-item__label,
.wc-block-components-totals-shipping .wc-block-components-totals-item__value {
  text-transform: none !important;
}

/* ─── Order Received — bottom spacing before footer ──────────────────
   Without this, the page feels cut off: the footer begins immediately
   after the Shipping/Billing address boxes. STAGING VERIFICATION NEEDED on
   the exact Order Confirmation wrapper class for the installed Blocks
   version — both classic and Blocks selectors are covered defensively. */

.woocommerce-order-received .woocommerce-order,
.woocommerce-order-received .wc-block-order-confirmation-address-wrapper,
.woocommerce-order-received .wc-block-order-confirmation-totals-wrapper {
  margin-bottom: 3em;
}

/* ─── Cart — spacing below title (Round 7 best-effort, corrected Round 8) ──
   Round 7 targeted `.wc-block-cart__main` with `margin-top: 1.5em` — a
   guessed WC Blocks class name, structurally the same mistake as the Round 5
   payment-border guess. Round 8 DevTools (full DOM walk of Cart's title and
   content wrapper, cross-checked against the same walk on Checkout) confirmed
   that class never appears anywhere in this install's Cart DOM, so the rule
   was a no-op.
   Root cause, confirmed via the matching Checkout walk: Checkout's content
   wrapper (`main.wp-block-group.site-content.is-layout-flow`) carries an
   inline `padding-top: 50px` — a block-editor spacing setting baked into the
   Checkout page template's Group block — which Cart's actual content wrapper
   (`.entry-content.wp-block-post-content`, a plain Page-template Post
   Content block) does not have at all (Computed tab confirmed 0 padding on
   every side). That 50px is the entire visible gap difference between the
   two pages; it has nothing to do with title margin, which Round 8 also
   confirmed is already identical in em terms on both pages (2.5em/1.25em,
   each relative to its own title's font-size). Fixed by adding the same
   50px to Cart's confirmed actual wrapper instead of the nonexistent Round 7
   selector. */

/* Round 10, 2026-06-29: all three of the wrapper-padding/margin-addition
   values below (Cart, Checkout, Order Received) are the SAME constant by
   design — Round 9 established that the three pages share one vertical
   rhythm (title's own 1.25em margin-bottom + this fixed addition). The user
   then asked to tighten that shared addition by ~25-30px without breaking
   parity, so it dropped from 50px to 22px (a 28px reduction) in all three
   places at once. If this gets tuned again, change all three together —
   that's the whole reason they're called out as one constant here instead
   of three independently-derived numbers. */

.woocommerce-cart .wp-block-post-content {
  padding-top: 22px;
}

/* Checkout's equivalent of the rule above: the 50px (now 22px) here comes
   from an INLINE style already baked into the Checkout page template's
   Group block (`style="padding-top:50px;..."`, confirmed via Round 8
   DevTools), not from this stylesheet — Round 9 left it untouched because it
   already matched. Now that the shared constant is being tuned down,
   overriding it here is unavoidable: inline styles only yield to a
   stylesheet rule with `!important`. Scoped to `:not(.suprbad-pgf-retry)`,
   matching this file's established convention for checkout-only selectors,
   since the retry/order-pay template doesn't use this wrapper at all. */

.woocommerce-checkout:not(.suprbad-pgf-retry) .wp-block-group.site-content.is-layout-flow {
  padding-top: 22px !important;
}

/* ─── Order Received — spacing below title (Round 7, confirmed Round 8) ──
   Round 8 DevTools Computed-tab evidence confirmed this rule produces a
   49px margin-bottom on `.wc-block-order-confirmation-status` (2em relative
   to its own `has-large-font-size` computed font-size), stacking with the
   title's own 1.25em margin-bottom below it — no correction needed, unlike
   the Cart rule above. */

.woocommerce-order-received .wc-block-order-confirmation-status {
  margin-bottom: 2em;
}

/* ─── Order Received — title-to-content gap parity (Round 9, tuned Round 10) ──
   User-reported via side-by-side screenshot, confirmed against the Round 8
   evidence already on file: Cart and Checkout share a gap between title and
   first content row built from the title's own 1.25em margin-bottom plus a
   fixed addition (see the Round 10 note above the Cart rule). Order Received
   has no equivalent wrapper padding to add that constant to: its title and
   its "Thank you for shopping..." paragraph are siblings inside the same
   `.wc-block-order-confirmation-status` block, so the only gap between them
   was the title's own 1.25em margin-bottom — visibly smaller than
   Cart/Checkout's combined gap, exactly matching the reported symptom.
   Fixed by adding the same constant directly to the title's own
   margin-bottom on this page only. Placed after the shared page-title rule
   so source order resolves the tie on the same selector without needing
   `!important`. */

.wc-block-order-confirmation-status h1,
.wc-block-order-confirmation-status h2 {
  margin-bottom: calc(1.25em + 22px);
}

/* ─── Order Received — typography normalization (Round 7, 2026-06-25) ──
   Headings ("Order details", "Shipping address", "Billing address") and
   body text on this page read visibly larger than the equivalent text on
   Cart/Checkout. Checkout inherits a Global Styles font-size override
   scoped to its own block wrapper — confirmed via staging DevTools Round 6:
   `:root :where(.wp-block-woocommerce-checkout) { font-size:
   var(--wp--preset--font-size--small) }`. The Order Confirmation page is
   built from a different set of WC core blocks
   (`wp-block-woocommerce-order-confirmation-*`) that don't automatically
   inherit that override.
   CONFIRMED Round 11, 2026-06-29: class names verified present in this
   install's DOM. However, DevTools also showed the "Order details" /
   "Shipping address" / "Billing address" `<h2>` headings inside these
   wrappers each carry their own inline `style="font-size:24px"` — an inline
   style always wins over an inherited value, so this rule does not actually
   reach those three headings; they render at a fixed 24px regardless of
   this rule. They visually match Cart/Checkout already at that fixed size,
   so no further fix is needed, but this rule's real effect is limited to
   non-heading text inside these wrappers (address lines, totals values),
   not the section headings. */

.wp-block-woocommerce-order-confirmation-status,
.wp-block-woocommerce-order-confirmation-summary,
.wp-block-woocommerce-order-confirmation-shipping-address,
.wp-block-woocommerce-order-confirmation-billing-address,
.wp-block-woocommerce-order-confirmation-totals {
  font-size: var(--wp--preset--font-size--small);
}

/* Order Received H1 size (Round 8, 2026-06-29): the rule above doesn't reach
   the page's own heading — confirmed via DevTools that the "Order received"
   text is an `<h1>` belonging to WooCommerce's order-confirmation block, not
   the `wp-block-post-title` block Cart/Checkout use, and it has its own
   direct font-size that doesn't inherit from the wrapper above. Cart/Checkout
   titles read at 24.5px ("large" preset) because each of those post-title
   blocks was individually set to "large" in the editor; this h1 instead
   falls back to the theme's bare `h1 { font-size: x-large }` global default,
   confirmed via Computed tab at 30.8px — visibly larger, matching the user's
   report. Forced to match. */

.wc-block-order-confirmation-status h1,
.wc-block-order-confirmation-status h2 {
  font-size: var(--wp--preset--font-size--large);
}

/* ─── Product Identity — operational subtitle (D3–D5, 2026-07-19) ─────
   The Product Title rendered as supporting information beneath the
   Display Name. Two variants: the single-product subtitle (its own
   element under the H1) and the inline line variant used inside cart /
   checkout review / order tables / emails (a span forced onto its own
   line). Muted, smaller, single-line-clamped on narrow viewports so a
   long operational title never wraps the cart row (plan §7 mobile
   truncation). No element is emitted at all when a product has no
   Display Name — zero layout shift in the fallback state. */

.sb-identity-subtitle {
  display: block;
  color: var(--sb-color-text-muted, #7a7772);
  font-family: var(--sb-font-primary, inherit);
  font-weight: 400;
  text-transform: none;
}

.sb-identity-subtitle--product {
  margin: -0.5em 0 1em;
  font-size: 0.95rem;
}

.sb-identity-subtitle--line {
  overflow: hidden;
  font-size: 0.8em;
  line-height: 1.4;
  white-space: nowrap;
  text-overflow: ellipsis;
}

/* ─── SB Surface application (U2, 2026-07-19) ─────────────────────────
   The canonical elevated-card treatment (docs/FRONTEND-ARCHITECTURE.md
   § SB Surface): near-white surface + 1px border + --sb-radius-md +
   restrained shadow, derived from the approved retry-panel reference.
   Applied to the frozen surface list — cart totals, checkout order
   summary, notices/success messages, order details tables, My Account
   cards. The address boxes already carried radius; they adopt the full
   recipe here so every card reads as one family. */

.wp-block-woocommerce-cart-totals-block,
.wc-block-components-sidebar .wc-block-components-order-summary,
.wc-block-components-order-summary.is-large,
.woocommerce-checkout .wc-block-components-totals-wrapper:first-of-type,
.woocommerce-table--order-details,
.wc-block-order-confirmation-totals table,
.woocommerce-message,
.woocommerce-info,
.woocommerce-error,
.wc-block-components-notice-banner,
.woocommerce-MyAccount-content .woocommerce-table,
.woocommerce-MyAccount-content .woocommerce-Address,
.wc-block-components-shipping-address-block,
.wc-block-components-billing-address-block,
.wc-block-checkout__shipping-fields,
.wc-block-checkout__billing-fields,
.wc-block-components-address-card {
  background: var(--sb-color-surface, #fff);
  border: 1px solid var(--sb-color-border, #d4d0ca);
  border-radius: var(--sb-radius-md, 8px);
  box-shadow: var(--sb-shadow-surface, 0 1px 2px rgb(26 26 26 / 5%), 0 4px 14px rgb(26 26 26 / 6%));
}

/* Surface interiors: the order tables get breathing room so the card
   doesn't clamp its content against the border. */

.woocommerce-table--order-details,
.wc-block-order-confirmation-totals table,
.woocommerce-MyAccount-content .woocommerce-table {
  padding: 0.75em 1em;
  border-collapse: separate;
  border-spacing: 0;
}

/* ─── Customer Account styling pass (U2, 2026-07-19) ──────────────────
   Spacing / typography / density sweep folded into the same styling
   milestone (plan U2) so My Account CSS is touched once: headings adopt
   the brand face, the navigation gains rhythm, and address cards inherit
   the SB Surface recipe above. Wording stays untouched (no gettext
   changes in this pass — wording changes are settings-driven features,
   OWNERSHIP_BOUNDARIES §6). */

.woocommerce-MyAccount-content h2,
.woocommerce-MyAccount-content h3 {
  font-family: var(--sb-font-primary, inherit);
}

.woocommerce-MyAccount-navigation ul {
  padding: 0;
  list-style: none;
}

.woocommerce-MyAccount-navigation li {
  margin: 0;
  border-bottom: 1px solid var(--sb-color-border, #d4d0ca);
}

.woocommerce-MyAccount-navigation li a {
  display: block;
  padding: 0.65em 0.25em;
  text-decoration: none;
}

.woocommerce-MyAccount-navigation li.is-active a {
  font-weight: 700;
}

.woocommerce-MyAccount-content .woocommerce-Address {
  padding: 1em 1.25em;
}