/* ============================================================================
   VioVerse — Stripe Elements payment modal
   ----------------------------------------------------------------------------
   Wraps Stripe's Elements iframes (Express Checkout + Payment Element) inside
   a VioVerse-styled modal. Stripe styles its own iframe internals via the
   Elements `appearance` API; this file styles only the surrounding modal
   chrome (backdrop, card, header, submit button, error region).

   Phase 45 Step 3 status: structural only. Visual refinement (final spacing,
   typography, exact card width) lands in Step 5 after measurement sign-off.
   ============================================================================ */

.payment-elements-modal {
  position: fixed;
  inset: 0;
  /* Sticky `.nav` is z-index 100; sibling `.mode-modal` / `.acr-modal`
     overlays use 500. Match that convention so the modal backdrop covers
     the navbar instead of letting the cream nav bar punch through the
     dim layer above the Stripe card. */
  z-index: 500;
  background: var(--backdrop-scrim);
  display: none;
  pointer-events: none;
  /* iOS scroll: when Stripe's PaymentElement adds the optional "Save my
     info for faster checkout" Link-enrollment section, the iframe grows
     past iPhone viewport. The card needs its own overflow context, and
     centering must use `margin: auto` (below) instead of `align-items:
     center` — centered overflowing flex children clip both top and
     bottom on iOS Safari without a way to scroll back to either edge. */
  overflow-y: auto;
  -webkit-overflow-scrolling: touch;
  padding: 16px;
  box-sizing: border-box;
}

/* Pill scrollbar for the modal overlay itself */
.payment-elements-modal::-webkit-scrollbar { width: 12px; }
.payment-elements-modal::-webkit-scrollbar-track { background: transparent; margin: 4px 0; }
.payment-elements-modal::-webkit-scrollbar-button { display: none; }
.payment-elements-modal::-webkit-scrollbar-thumb {
  background: #E0E3E7;
  background-clip: padding-box;
  border: 5px solid transparent;
  border-radius: 99px;
}
.payment-elements-modal::-webkit-scrollbar-thumb:hover,
.payment-elements-modal::-webkit-scrollbar-thumb:active {
  border-width: 2px;
  background-color: #D5D8DC;
}
@supports not selector(::-webkit-scrollbar) {
  .payment-elements-modal {
    scrollbar-width: thin;
    scrollbar-color: #E0E3E7 transparent;
  }
}

.payment-elements-modal.visible {
  display: flex;
  pointer-events: auto;
}

.payment-elements-card {
  position: relative;
  background: #fbf8f1;
  border-radius: 14px;
  padding: 28px 24px 24px;
  max-width: 480px;
  width: 100%;
  /* `margin: auto` in a flex parent centers when content fits and
     resolves to 0 when overflowing — letting the modal's overflow-y
     own the scroll instead of trapping the bottom below viewport. */
  margin: auto;
  box-shadow:
    0 2px 6px rgba(10, 14, 20, 0.066),
    0 30px 80px rgba(10, 14, 20, 0.22),
    0 0 0 1px rgba(30, 42, 53, 0.06);
  font-family: 'Plus Jakarta Sans', system-ui, sans-serif;
  -webkit-font-smoothing: antialiased; /* FS-D5: normalized to match .home */
  color: #1E2A35;
  box-sizing: border-box;
}

.payment-elements-card h3 {
  font-family: 'Plus Jakarta Sans', system-ui, sans-serif;
  font-weight: 700;
  font-size: 22px;
  letter-spacing: -0.02em;
  margin: 0 0 16px;
}

.payment-elements-card .price-strong {
  color: #f26419;
}

/* FS-2 (2026-08-02): renders a 26px "×" glyph, so it was visibly Arial
   against the Plus Jakarta Sans card around it. Buttons do not inherit
   the family; `font-family: inherit` is what carries it in. */
.payment-elements-close {
  position: absolute;
  top: 12px;
  right: 14px;
  background: none;
  border: none;
  font-family: inherit;
  font-size: 26px;
  line-height: 1;
  cursor: pointer;
  color: rgba(30, 42, 53, 0.55);
  padding: 4px 8px;
}
.payment-elements-close:hover { color: #1E2A35; }

#express-checkout-mount {
  margin-bottom: 16px;
  /* Empty when Express Checkout has nothing to render (no wallets eligible);
     collapse the gap so the divider/Payment Element sit flush. */
  min-height: 0;
}
#express-checkout-mount:empty { margin-bottom: 0; }

.payment-elements-divider {
  display: flex;
  align-items: center;
  gap: 12px;
  margin: 12px 0 16px;
  font-size: 12px;
  font-weight: 600;
  color: rgba(30, 42, 53, 0.55);
  text-transform: uppercase;
  letter-spacing: 0.08em;
}
.payment-elements-divider::before,
.payment-elements-divider::after {
  content: '';
  flex: 1 1 auto;
  height: 1px;
  background: rgba(30, 42, 53, 0.12);
}
/* Hide divider in card_only variant (no wallets above to separate from). */
.payment-elements-card.variant-card-only .payment-elements-divider {
  display: none;
}

#payment-element-mount {
  margin-bottom: 16px;
}

.payment-elements-submit {
  background: #1D2430;
  color: #fbf8f1;
  border: none;
  border-radius: 999px;
  padding: 14px 24px;
  font-weight: 600;
  font-family: 'Plus Jakarta Sans', system-ui, sans-serif;
  font-size: 15px;
  width: 100%;
  cursor: pointer;
  transition: opacity 0.15s ease;
}
.payment-elements-submit:hover { opacity: 0.92; }
.payment-elements-submit:disabled {
  opacity: 0.55;
  cursor: not-allowed;
}

.payment-elements-error {
  color: #D6584C;
  font-size: 13px;
  margin-top: 10px;
  min-height: 18px;
  font-weight: 500;
}

/* Followup #2 (commit e62065f, 2026-04-26) hid this button when Link's
   saved-card takeover was detected, on the assumption that Stripe rendered
   its own "Use this card" submit pill inside the Link iframe. Tonight's
   empirical verification (2026-04-26) disconfirmed that assumption: the
   Link picker is a selection UI, not a confirmation UI. Selecting a card
   in the picker does not fire stripe.confirmPayment(). With our Pay button
   hidden, users had no submit affordance — payment was unfireable in the
   Link saved-card takeover state. Diagnostic data: console silent on
   Visa-row click, network shows no /confirm call from Stripe's iframe,
   modal height ~184px (within 6px of the BACKLOG line 971 measurement).

   Always-visible Pay button. If Stripe ever re-introduces an embedded
   submit pill, the cosmetic regression of "two visible submits" returns
   but payment continues to work via our button. Cosmetic cost is bounded;
   payment-flow correctness is preserved. */
/*
.payment-elements-modal.link-takeover-active #payment-element-submit {
  display: none;
}
*/

.payment-elements-loading {
  display: flex;
  align-items: center;
  justify-content: center;
  min-height: 200px;
  color: rgba(30, 42, 53, 0.55);
  font-size: 14px;
}

/* Iframe loading-state polish (Step 6 Issue A).
   Stripe's iframes paint asynchronously after `stripe.elements.create()`
   returns — Express Checkout, then the Payment Element's tab strip, then
   the card-entry rows each finish their own paint pass over a few
   hundred ms. Without this rule, customers saw the iframes pop in at
   different sizes during that window.

   payment-elements.js sets `data-payment-ready="1"` on the modal in the
   Payment Element's `ready` callback (which empirically only fires after
   Express Checkout has also stabilized). Until then, hide both iframe
   mount points with opacity:0 so the loading placeholder owns the visual.
   `display: none` is intentionally avoided — Stripe's iframes need to
   stay in the layout to compute their own dimensions, per Stripe's
   `mount` contract.

   The 80ms transition delay holds the loading state long enough to read
   instead of flashing past on a fast network. */
#express-checkout-mount,
#payment-element-mount {
  transition: opacity 200ms ease 80ms;
}
.payment-elements-modal:not([data-payment-ready="1"]) #express-checkout-mount,
.payment-elements-modal:not([data-payment-ready="1"]) #payment-element-mount {
  opacity: 0;
}

/* Mobile sizing — let the card fill available width with side breathing room. */
@media (max-width: 480px) {
  .payment-elements-modal {
    padding: 12px;
  }
  .payment-elements-card {
    padding: 24px 18px 20px;
    border-radius: 14px;
  }
  .payment-elements-card h3 {
    font-size: 19px;
    margin-bottom: 14px;
  }
}