/*
 * Checkout page (Phase 3F — docs/CHECKOUT-IMPLEMENTATION.md). Restyles
 * WooCommerce's own Checkout Block using its documented, stable CSS class
 * names — the real rendering system on this site (verified via page-
 * content and live-render inspection). No custom fields, no copied block
 * internals, no JS build pipeline introduced.
 */

/* --- Step sections (Contact information / Shipping address / Shipping
   options / Payment options / order notes / terms) --- */
.wc-block-components-checkout-step {
	padding-block: var(--space-6);
	border-bottom: var(--border-default);
}
.wc-block-components-checkout-step:first-child { padding-top: 0; }

.wc-block-components-checkout-step__title {
	font-family: var(--font-display);
	font-size: var(--text-h4);
	font-weight: var(--font-weight-semibold);
	margin: 0 0 var(--space-4);
}

/* --- Text/email/tel inputs (WooCommerce's own floating-label component —
   a real <label>, not a placeholder; verified via DOM inspection) --- */
.wc-block-components-text-input input,
.wc-blocks-components-select__select {
	border: var(--border-default);
	border-radius: var(--radius-md);
	font-family: var(--font-body);
	font-size: var(--text-base);
	min-height: 48px;
}
.wc-block-components-text-input input:focus,
.wc-blocks-components-select__select:focus {
	outline: none;
	box-shadow: var(--shadow-focus);
	border-color: var(--color-brand-blue);
}
.wc-block-components-text-input label,
.wc-blocks-components-select__label {
	font-family: var(--font-body);
	color: var(--color-text-secondary);
}
/* Required-state asterisk WooCommerce already appends to the label text —
   just given a colour so it isn't the same muted tone as the rest of the
   label. */
.wc-block-components-text-input input:required + label::after,
.wc-block-components-text-input label.is-required::after {
	color: var(--color-error);
}

/* --- Radio controls (shipping method, payment method) --- */
.wc-block-components-radio-control__option {
	/* WooCommerce's own default rule reserves the first 48px of left padding
	   for the native radio input, absolutely positioned within it
	   (confirmed via its compiled CSS: `padding: 16px 16px 16px 48px`).
	   Overriding the shorthand (as an earlier draft did) shrank that
	   reserved space and made the label text render underneath the radio
	   circle — a real, visible bug caught in a screenshot review. Only the
	   non-conflicting properties are set here. */
	border: var(--border-default);
	border-radius: var(--radius-md);
	margin-bottom: var(--space-2);
	transition: border-color var(--duration-base) var(--ease-standard);
}
.wc-block-components-radio-control__option--checked-option-highlighted,
.wc-block-components-radio-control__option:has(input:checked) {
	border-color: var(--color-brand-blue);
	background: color-mix(in srgb, var(--color-brand-blue) 5%, white);
}
.wc-block-components-radio-control__input:checked {
	accent-color: var(--color-brand-blue);
}
.wc-block-components-radio-control__label { font-weight: var(--font-weight-medium); }
.wc-block-components-payment-method-label { display: flex; align-items: center; gap: var(--space-2); }

/* Real, honest gateway description text (e.g. the COD dev-notice) —
   never invented, just styled to read as secondary/explanatory copy. */
.wc-block-components-radio-control__secondary-label {
	color: var(--color-text-secondary);
	font-size: var(--text-sm);
	display: block;
	margin-top: var(--space-1);
}

/* --- Checkboxes (create account, ship-to-different-address, order note
   toggle, terms) --- */
.wc-block-components-checkbox__input:checked + .wc-block-components-checkbox__mark {
	color: var(--color-brand-blue);
}
.wc-block-components-checkbox.has-error .wc-block-components-checkbox__label {
	color: var(--color-error);
}

/* --- Terms acceptance — real, required checkbox (enabled on this Checkout
   page's block content; see docs/CHECKOUT-FIELD-STRATEGY.md §5). Links only
   render once the Terms/Privacy pages are published — a documented launch
   blocker, not something this CSS can fix. --- */
.wc-block-checkout__terms {
	padding-block: var(--space-4);
	font-size: var(--text-sm);
}
.wc-block-checkout__terms a { color: var(--color-brand-blue); }

/* --- Order summary (checkout sidebar) --- */
.wc-block-components-order-summary-item__image img {
	border-radius: var(--radius-sm);
	border: var(--border-default);
}
.wc-block-components-order-summary-item__description {
	font-size: var(--text-sm);
	color: var(--color-text-secondary);
}

/* --- Place Order --- */
.wc-block-components-checkout-place-order-button {
	width: 100%;
	min-height: 52px;
	font-size: var(--text-base);
}

/* --- Guest-checkout / account-creation notice --- */
.wc-block-checkout__guest-checkout-notice,
.wc-block-checkout__create-account {
	font-size: var(--text-sm);
	color: var(--color-text-secondary);
}

/* --- Address form "+ Add apartment, suite, etc." toggle --- */
.wc-block-components-address-form__address_2-toggle {
	color: var(--color-brand-deep);
	font-size: var(--text-sm);
}

/* --- Responsive --- */
@media (max-width: 767px) {
	.wc-block-components-checkout-step { padding-block: var(--space-4); }
}

/* --- Order-received page ---
   Classic WooCommerce template (checkout/thankyou.php + order-received.php)
   — confirmed via live inspection that the Checkout Block's own submission
   still redirects to this classic endpoint (WooCommerce has not converted
   it to a block), so no override was needed; the real, unmodified
   ownership/order-key check in WC_Shortcode_Checkout::order_received()
   already prevents exposing another customer's order — restyled with CSS
   only. */
body.woocommerce-order-received .woocommerce-notice--success {
	background: var(--color-success-bg);
	color: var(--color-success);
	border-radius: var(--radius-md);
	padding: var(--space-4) var(--space-5);
	font-weight: var(--font-weight-semibold);
	margin-bottom: var(--space-6);
}

.woocommerce-order-overview {
	display: flex;
	flex-wrap: wrap;
	gap: var(--space-6);
	list-style: none;
	margin: 0 0 var(--space-8);
	padding: var(--space-5);
	background: var(--color-surface);
	border: var(--border-default);
	border-radius: var(--radius-lg);
}
.woocommerce-order-overview li { font-size: var(--text-sm); color: var(--color-text-secondary); }
.woocommerce-order-overview li strong { display: block; color: var(--color-text-primary); font-size: var(--text-base); margin-top: var(--space-1); }

.woocommerce-order-details__title,
.woocommerce-column__title {
	font-family: var(--font-display);
	font-size: var(--text-h4);
	margin: 0 0 var(--space-4);
}

.woocommerce-table--order-details {
	width: 100%;
	border-collapse: collapse;
	margin-bottom: var(--space-8);
}
.woocommerce-table--order-details th,
.woocommerce-table--order-details td {
	padding: var(--space-3);
	border-bottom: var(--border-default);
	text-align: left;
}
.woocommerce-table--order-details tfoot th { font-weight: var(--font-weight-medium); color: var(--color-text-secondary); }
.woocommerce-table--order-details tfoot tr:last-child th,
.woocommerce-table--order-details tfoot tr:last-child td { font-weight: var(--font-weight-bold); color: var(--color-text-primary); font-size: var(--text-h5); }

/* WooCommerce's own woocommerce-layout.css floats .col-1 left / .col-2
   right at 48% width (confirmed via its compiled CSS). A `display: grid`
   override was tried first and produced a real, reproducible bug: with
   these specific two block children, auto-placement put them in separate
   rows instead of side by side (confirmed via getBoundingClientRect — two
   different row heights were generated instead of one shared row), for a
   reason that didn't resolve even after clearing the leftover float/width.
   Flexbox with explicit flex-basis on each child is unambiguous for
   exactly "two boxes side by side" and doesn't share that failure mode.
   Deliberately NOT scoped to `.woocommerce-customer-details` — the exact
   same `.col2-set`/`.col-1`/`.col-2` markup is reused by WooCommerce for
   the My Account "Addresses" overview (Phase 3G), so this fix applies
   there automatically too. */
/* WooCommerce's own woocommerce-layout.css also puts a clearfix pair,
   `.col2-set::before, .col2-set::after { content:" "; display:table }`, on
   this exact element (its own float-based layout no longer needs it once
   we're flex, but it's still there). Once .col2-set is display:flex, that
   `display:table` blockifies to `display:block` for a flex item instead of
   being suppressed, silently adding two extra (empty but real) flex items
   before/after col-1/col-2. At 768px specifically, the ::before item's few
   pixels were enough to push col-2 to a second line despite col-1 + col-2 +
   gap otherwise fitting the container by the numbers (confirmed via
   getComputedStyle(set, '::before') showing display:table, and via
   getBoundingClientRect showing the pair stacked instead of side by side
   only at this width). This is very likely also the real cause of the
   grid-auto-placement bug the original comment above describes hitting with
   `display: grid` — same root cause, different symptom. Removing the
   pseudo-elements outright (flex/grid layout makes the clearfix redundant
   anyway) fixes both. */
/* !important: WC's own selector is `.woocommerce .col2-set::before` (two
   classes + pseudo-element), which beats a plain `.col2-set::before` (one
   class) on specificity — same recurring conflict as every other WC-hardcoded
   rule fixed elsewhere in this project, just on a pseudo-element this time. */
.col2-set::before,
.col2-set::after {
	content: none !important;
	display: none !important;
}
.col2-set {
	display: flex;
	flex-wrap: wrap;
	gap: var(--space-6);
}
.col2-set .col-1,
.col2-set .col-2 {
	float: none;
	width: auto;
	flex: 1 1 100%;
}
@media (min-width: 768px) {
	.col2-set .col-1,
	.col2-set .col-2 {
		/* 48%, not a 50%-minus-half-gap calc(): a calc() here (tried first)
		   measured out fractionally wider than the container once gap was
		   accounted for, wrapping the pair to two lines instead of one —
		   confirmed via getBoundingClientRect showing full-width, stacked
		   boxes despite correct-looking computed flex-basis. A flat 48%
		   (WooCommerce's own original float-based width for these same two
		   columns) leaves enough margin that the gap always fits. */
		flex: 0 1 48%;
		/* min-width: 0 — flex items default to min-width:auto, which floors
		   their size at their own content's intrinsic minimum width rather
		   than 0. At exactly 768px (Phase 3G My Account "Addresses" overview,
		   where each column's content column is narrower than at 1024px+)
		   that intrinsic minimum was still wider than 48%, so the pair wrapped
		   to two lines despite 48%+48%+gap otherwise fitting the container by
		   the numbers (confirmed via getBoundingClientRect at 768px viewport:
		   730.5px needed vs 736px available, yet still wrapped). Resetting
		   min-width removes that floor. */
		min-width: 0;
	}
}
.woocommerce-column address {
	font-style: normal;
	line-height: var(--leading-relaxed);
	color: var(--color-text-secondary);
	background: var(--color-surface);
	border: var(--border-default);
	border-radius: var(--radius-md);
	padding: var(--space-4);
}

@media (prefers-reduced-motion: reduce) {
	.wc-block-components-radio-control__option,
	.wc-block-cart__submit-button,
	.wc-block-components-checkout-place-order-button {
		transition: none !important;
	}
}