/* Benecaster checkout form.
 * Uses the theme's shared .bc-form / .bc-btn contract; only checkout-specific
 * layout lives here so the theme keeps ownership of the visual identity.
 */

.bc-checkout__form {
	max-width: 32rem;
}
.bc-checkout__interval {
	border: 0;
	padding: 0;
	margin: 0 0 1rem 0;
}
.bc-checkout__interval label {
	margin-right: 1rem;
}
#bc-checkout-payment-element {
	margin: 0.5rem 0;
	min-height: 2.5rem;
}
#bc-checkout-coupon-result[data-state="ok"] {
	color: #065f46;
}
#bc-checkout-coupon-result[data-state="error"] {
	color: #991b1b;
}
.bc-checkout__payment {
	margin-top: 1rem;
}
#bc-checkout-error[data-state="error"] {
	color: #991b1b;
}

/* Setup services share the add-on rows' look: same shape, same included state
 * (Studio includes Migration + Setup). */
.bc-checkout__addons,
.bc-checkout__services {
	border: 0;
	padding: 0;
	margin: 0 0 1rem 0;
}
.bc-checkout__addon,
.bc-checkout__service {
	display: block;
	margin-bottom: 0.35rem;
}
.bc-checkout__addon .bc-form__hint,
.bc-checkout__service .bc-form__hint {
	margin-left: 0.4rem;
}
/* A product the selected plan already grants. Dimmed and unselectable, but
 * still listed and still named -- hiding it would make the plan look like it
 * lacks the feature. */
.bc-checkout__addon--included,
.bc-checkout__service--included {
	opacity: 0.75;
}
.bc-checkout__addon-included,
.bc-checkout__service-included {
	font-weight: 600;
}

/* An add-on with no software behind it yet: shown, disabled, and saying so.
 *
 * Same dimming as the plan-included state, on purpose -- both mean "you cannot
 * tick this", and a second visual language for a second reason would make the
 * fieldset read as three kinds of row rather than one kind with two notes. The
 * sentence beside it is what distinguishes them. */
.bc-checkout__addon--unreleased {
	opacity: 0.75;
}
.bc-checkout__addon-unreleased {
	font-weight: 600;
}

/* Order summary.
 * Sits beside the form on wide screens and above it on narrow ones, so the
 * price is the first thing read on a phone rather than something below the
 * fold under the card field.
 */
.bc-checkout__summary {
	max-width: 32rem;
	margin: 1.5rem 0 0 0;
	padding: 1rem 1.25rem;
	border: 1px solid rgba( 0, 0, 0, 0.12 );
	border-radius: 0.5rem;
}
.bc-checkout__summary-title {
	margin: 0 0 0.75rem 0;
	font-size: 1rem;
}
.bc-checkout__lines {
	list-style: none;
	margin: 0;
	padding: 0;
}
.bc-checkout__line {
	display: flex;
	justify-content: space-between;
	gap: 1rem;
	padding: 0.3rem 0;
}
.bc-checkout__line--discount .bc-checkout__line-amount {
	color: #065f46;
}
.bc-checkout__line-amount {
	white-space: nowrap;
}
.bc-checkout__total {
	display: flex;
	justify-content: space-between;
	gap: 1rem;
	margin: 0.75rem 0 0 0;
	padding-top: 0.75rem;
	border-top: 1px solid rgba( 0, 0, 0, 0.12 );
	font-size: 1.05rem;
}
.bc-checkout__total--separate {
	font-size: 1rem;
	opacity: 0.85;
}
.bc-checkout__saving {
	display: inline-block;
	margin-left: 0.5rem;
	padding: 0.1rem 0.45rem;
	border-radius: 0.25rem;
	background: #065f46;
	color: #fff;
	font-size: 0.8rem;
}

@media ( min-width: 60rem ) {
	.bc-checkout {
		display: grid;
		grid-template-columns: minmax( 0, 32rem ) minmax( 0, 24rem );
		gap: 2rem;
		align-items: start;
	}
	.bc-checkout__summary {
		margin-top: 0;
		position: sticky;
		top: 2rem;
	}
}

/* Separately-billed lines sit under their own total, so they need a little
 * air to read as a second group rather than a continuation of the first. */
.bc-checkout__lines--separate {
	margin-top: 1rem;
	padding-top: 0.75rem;
	border-top: 1px solid rgba( 0, 0, 0, 0.12 );
}
.bc-checkout__lines--separate + .bc-checkout__total {
	margin-top: 0.25rem;
	padding-top: 0.25rem;
	border-top: 0;
}

/* The tax line belongs to the total below it, not to the plan lines above it:
 * it is the difference between the subtotal and what the card is charged. The
 * top rule pairs it with the total's own, so the two read as one block. */
.bc-checkout__lines--tax {
	margin-top: 0.75rem;
	padding-top: 0.75rem;
	border-top: 1px solid rgba( 0, 0, 0, 0.12 );
}
.bc-checkout__lines--tax + .bc-checkout__total {
	margin-top: 0.25rem;
	padding-top: 0.25rem;
	border-top: 0;
}
/* Dimmed while a figure is being fetched for an address that just changed --
 * the placeholder must not read as a settled amount. */
.bc-checkout__total[aria-busy="true"] {
	opacity: 0.7;
}

/* The signed-in Launch holder's route to /my-account/. Spacing only: the look
 * comes from the theme's .bc-form__banner, which this shares with the
 * "no plans available" banner it sits above. */
.bc-checkout__launch-notice {
	margin-bottom: 1.5rem;
}
.bc-checkout__launch-notice p {
	margin: 0 0 0.5rem 0;
}
.bc-checkout__launch-notice p:last-child {
	margin-bottom: 0;
}

/* The existing customer's route to the add-on panel on /my-account/. Same
 * two-paragraph shape and the same spacing-only treatment as the Launch notice
 * above -- the look is the theme's .bc-form__banner in both cases.
 *
 * Selector shared rather than a second block: the two notices are mutually
 * exclusive by construction (the page suppresses this one for a Launch holder,
 * who already has the other), so they can never both need spacing at once, and
 * one rule is one thing to keep in step. */
.bc-checkout__addon-notice,
.bc-checkout__service-notice {
	margin-bottom: 1.5rem;
}
.bc-checkout__addon-notice p,
.bc-checkout__service-notice p {
	margin: 0 0 0.5rem 0;
}
.bc-checkout__addon-notice p:last-child,
.bc-checkout__service-notice p:last-child {
	margin-bottom: 0;
}

/* ⚠⚠ **RESTORES `hidden` ON THE FOUR BOXES THIS PAGE PAINTS EMPTY AND FILLS
 * LATER, AND WITHOUT IT ONE OF THEM BLOCKS THE SALE.** The theme's
 * `.bc-page .bc-form__field { display: flex }` is an author rule, so it beats
 * the UA sheet's `[hidden] { display: none }` outright — every fieldset that
 * carries both the class and the attribute renders regardless. On `/checkout/`
 * that is `#bc-checkout-intent`, `#bc-checkout-pitch`,
 * `#bc-checkout-addon-license` and `#bc-checkout-platform`: all four appeared
 * on first paint, empty, before the one lookup at the step boundary had
 * written a word into them.
 *
 * ⚠⚠ **THE SALE WAS NOT BLOCKED, AND THIS COMMENT USED TO SAY IT WAS.** It read
 * that `checkout.js` "refuses to submit while that fieldset is visible and
 * unanswered", making it "a lost sale". `checkout.js` gates submission on the
 * `hidden` **attribute** (`! intentBox.hidden`), which was correctly set the
 * whole time — so Continue always worked. **The attribute and the screen
 * disagreed, which is the entire defect**, and a passing submit is not evidence
 * the boxes are hidden. What the buyer met was an empty, apparently-mandatory
 * control above the card field, reported twice by the operator: *"two radio
 * buttons but no labels or purpose"*. Bad enough on a payment page, and not a
 * wall — do not reinstate the stronger claim.
 *
 * ⚠ **`!important` is deliberate, not laziness.** `.bc-checkout [hidden]` and
 * `.bc-page .bc-form__field` have identical specificity, so which one wins
 * would come down to stylesheet order between the theme and this plugin —
 * something neither side controls and which changes silently. `hidden` means
 * *not rendered in any presentation*, so there is no legitimate rule for this
 * to override.
 *
 * ⚠ **Any new box on this page that is painted empty and filled by JS is
 * covered by this automatically**, which is the reason it is written as one
 * attribute rule rather than four id rules.
 *
 * ⚠⚠ **EVERY OTHER FRONT-END PAGE OF THIS PLUGIN NOW CARRIES THE SAME LINE, AND
 * `tests/Architecture/HiddenAttributeRestoredTest.php` FAILS THE BUILD IF ONE
 * DOES NOT.** This note used to say `/launch-signup/` and `/my-account/` were
 * "clear today only because their toggled elements carry other classes", which
 * was true and was left as a warning nobody could act on — there is no runtime
 * signal for this defect at all, so a warning in a comment is the weakest form
 * the rule can take. **Do not delete this rule if the theme is ever fixed**: it
 * is what stops the plugin-side rules being dropped as redundant, which would
 * put the whole thing back the moment a theme is changed or replaced.
 */
.bc-checkout [hidden] {
	display: none !important;
}

/* "Card details" heads the card step; it is not a field label.
 *
 * Styled as a section heading because Stripe's own "Card number" label sits
 * directly beneath it, inside Stripe's iframe, and when both used the field
 * label look the customer read two labels for one box. Stripe's side follows
 * assets/js/stripe-appearance.js and cannot be told apart from ours, so the
 * difference is made here: larger, bolder, with a rule under it.
 *
 * currentColor rather than a fixed colour, because the theme's page is dark
 * and a hard-coded grey rule would vanish on it. color-mix() softens the rule
 * where supported; the plain currentColor line before it is the fallback. */
.bc-checkout__card-heading {
	font-size: 1.125rem;
	font-weight: 700;
	line-height: 1.3;
	margin: 0 0 1rem 0;
	padding-bottom: 0.5rem;
	border-bottom: 1px solid currentColor;
	border-bottom-color: color-mix( in srgb, currentColor 30%, transparent );
}
