/*
	List — cards still stack, one per row (a plain flex column, matching
	Benefits' own mobile-first single-column default), but each individual
	card is now its own 1fr/3fr grid — image in the narrow column, header +
	text in the wide one — rather than Grid/Carousel's stacked image-above-
	text card. Scoped to .options-list .card specifically; Grid and
	Carousel keep the shared stacked .card layout unmodified.
*/
.options-list {
	display: flex;
	flex-direction: column;
	gap: var(--options-card-gap); /* 60px */
}

.options-list .card {
	display: grid;
	grid-template-columns: 1fr 3fr;
	column-gap: var(--space-5); /* 24px, between the image column and the content column */
	align-items: start;
}

.options-list .card__media {
	grid-column: 1;
}

.options-list .card__body {
	grid-column: 2;
}

/* .flex-section--options .options-list .card__body (3 classes), not just
   .options-list .card__body (2) — needs to outrank the shared
   .flex-section--options .card__body rule below on SPECIFICITY, not source
   order, since that rule's own 48px padding-block-start is Grid/Carousel's
   image-above-text gap and is meaningless once image and text sit side by
   side instead. */
.flex-section--options .options-list .card__body {
	padding-block-start: 0;
}

/* A card with no image (the field is optional) has no .card__media sibling
   to sit beside — .card__body spans the full row instead of auto-placing
   into the narrow 1fr column alone. */
.options-list .card:not(:has(.card__media)) .card__body {
	grid-column: 1 / -1;
}

/*
	Grid — auto-fit off one fixed minimum card width, same idea .card-grid
	already uses (layout.css), rather than an editor-facing column count.
	There used to be one (a Columns select, 2/3/4, picking a TARGET width
	via a per-count minmax() basis) — removed by request: it only ever
	controlled card WIDTH, not how many cards could exist, so picking "3"
	never actually stopped a 4th card from being added, it just wrapped to
	a second row at that same width — confusing, since it looked like a cap
	but wasn't one.

	15.3rem is tuned so exactly 5 cards fit across the container's own max
	content width — (84.5rem - 4 gaps * var(--space-6)) / 5 — with a 6th
	card simply wrapping to a new row, same auto-fit mechanism, no field
	needed to make that happen. 84.5rem is --container-max (tokens.css)
	minus its two --container-gutter sides.
*/
.options-grid {
	display: grid;
	/* Split, not the gap shorthand — row-gap is its own requested value
	   (--options-card-gap, 60px, shared with .options-list's own gap
	   between stacked cards), taller than the 32px between cards in the
	   same row, which stays the shared var(--space-6). */
	column-gap: var(--space-6);
	row-gap: var(--options-card-gap);
	grid-template-columns: repeat(auto-fit, minmax(min(15.3rem, 100%), 1fr));
}

/*
	No card background in any layout (list/grid/carousel all share the same
	.card markup, blocks/options/options.php) — overrides .card's own
	background-color: var(--color-surface) (components.css), scoped to this
	block specifically since .card is shared with several other blocks
	(Products, Insights/Products Highlight, post-card.php) that still want
	their own surface tint. .card__media's own background (letterboxing
	behind a narrower/no image) is untouched — that's a different thing
	structurally, same reasoning Resources' own media background was left
	alone (blocks/resources/resources.css).

	border-radius zeroed here too, on purpose: .card's own border-radius +
	overflow: hidden (components.css) round all four of ITS corners, but
	with no background or border left on the card itself, that rounding on
	the body's own two corners had nothing to visibly show it against — it
	clips content to a curve nobody can see. Rounding now lives on
	.card__media specifically instead (below), which already has its own
	overflow: hidden and a real background/image to actually show it.
*/
.flex-section--options .card {
	background-color: transparent;
	border-radius: 0;
}

/*
	No hover lift — overrides .card's own :hover (components.css), which
	otherwise translates the whole card up 2px and adds a shadow. Scoped to
	this block since .card is shared with Products/the Highlight blocks/
	post-card.php, which still want it.
*/
.flex-section--options .card:hover {
	transform: none;
	box-shadow: none;
}

/*
	Border radius moved here from .card (see above) — .card__media already
	clips its own image via overflow: hidden (components.css), so adding
	the radius directly to it rounds all four of the image's own corners
	independent of the now-unrounded, invisible card body beneath it.
*/
.flex-section--options .card__media {
	border-radius: var(--radius-lg);
}

/*
	48px between the image and the text content below it — .card__media and
	.card__body sit flush against each other with no gap of their own
	(components.css), so the only existing space was .card__body's own
	uniform var(--space-5) (24px) padding on all four sides. The other three
	sides are zeroed out entirely: with no card background left to give
	breathing room against (see the no-background rule above), that padding
	was leftover from when there was one — content now runs flush with the
	card's own left/right/bottom edges, its spacing from OTHER cards coming
	entirely from the grid/list/carousel's own gap instead.
*/
.flex-section--options .card__body {
	padding: 0;
	padding-block-start: 3rem; /* 48px — the one side that's a deliberate gap, not leftover */
}

/*
	24px between the card's own header and text — .card__body's own flex
	`gap` (components.css) is var(--space-3), 12px, shared across every
	.card body's children theme-wide. This adds the remaining 12px on top,
	scoped to when a title is immediately followed by this block's own
	WYSIWYG text, the same "top up the shared gap" pattern already used for
	.benefit__header + .benefit__text (blocks/benefits/benefits.css) and
	.resource-card__title + .resource-card__text (blocks/resources/
	resources.css).
*/
.flex-section--options .card__title + .prose {
	margin-block-start: var(--space-3); /* +12px on the existing 12px gap = 24px total */
}

/*
	Header colour matches Benefits'/Resources' own card headers
	(var(--dark-card-fg), tokens.css) — explicit, not inherited, for the
	same reason those two needed it: layout.css's `.bg-default h1..h6`
	rule targets the bare <h3> element directly, and an explicit rule on an
	element always beats an inherited value regardless of specificity, so
	this only shows up as a bug on a Default-background section without an
	override here too. Font size is its own token (--options-card-header-
	font-size, 28px) — .card__title already carries .heading-style-h4
	(options.php), whose own size this overrides.
*/
.flex-section--options .card__title {
	color: var(--dark-card-fg);
	font-size: var(--options-card-header-font-size); /* 28px */
}

/*
	On a light background — Muted/Tint, the same pair layout.css's own
	shared heading-colour rule covers alongside Default (Accent excluded
	there after a live AODA contrast failure; Dark obviously isn't "light")
	— the card has no background of its own (the no-card-background rule
	above) and sits directly on the section's own light surface, where
	var(--dark-card-fg) (a pale, near-white mint) reads as almost invisible.
	Dark BG's own token (var(--color-dark-bg)) instead, by request — the
	same "use Dark BG's colour as a strong-contrast foreground here" choice
	already made for the Resources block's Connect card title and the CTA
	block's own Muted header. 2 classes here (.flex-section--options.bg-*
	.card__title) still outrank the 2-class rule above regardless (equal
	specificity, later source wins), so this still wins regardless of
	source order.

	Default is deliberately NOT included here (see the white-text rule
	below instead) — on this install Default currently resolves to a dark
	background with a white foreground (tokens.css), not its usual light
	role, so forcing dark-green text here would be functionally invisible
	against it (verified: #263d40 against #1d2e30 computes to 1.23:1).
	Tint is still nominally light-only by design, but is ALSO currently set
	dark on this install (#294c51) — no live Options block uses Tint today,
	so nothing actually renders broken, but this rule needs revisiting
	first if one ever is added on Tint while it stays this dark.
*/
.flex-section--options.bg-muted .card__title,
.flex-section--options.bg-tint .card__title {
	color: var(--color-dark-bg);
}

/*
	Dark and Default, by request — both resolve to a dark section
	background with a white foreground (--color-dark-fg/--color-default-fg,
	tokens.css, both #ffffff and no longer Style-Guide-editable at all,
	see that file's own docblock), so var(--section-fg) (the same custom
	property every .bg-* class sets, layout.css) reads as literal white for
	both without hardcoding that assumption directly. Dark previously had
	no override at all here and fell through to the base rule's own pale
	near-white mint (var(--dark-card-fg)) above; this is a dedicated
	override for it now, not a change to that shared token (which Benefits'
	and Resources' own card headers still use as-is).
*/
.flex-section--options.bg-dark .card__title,
.flex-section--options.bg-default .card__title {
	color: var(--section-fg);
}

/*
	Custom prev/next artwork, split into two independently-styleable layers
	instead of one flat background-image (the original arrow-hex-prev.svg /
	arrow-hex-next.svg, still in assets/images/ but no longer referenced
	here) — a background-image is opaque to CSS: there's no way to select
	"just the hexagon" inside an externally-referenced SVG file the way you
	could with inline markup. So the hexagon and the arrow glyph are now two
	separate derived SVGs, layered via ::before/::after, each with its own
	independently controllable opacity:
	  - arrow-hex-bg.svg — just the hexagon polygon (the ORIGINAL files'
	    own <g transform="translate(-3 -3)"> group, which was already
	    identical between prev/next — the hex shape never differed, only
	    the arrow direction did — so one shared file covers both; its own
	    original light gray/white gradient fill was later replaced with a
	    flat #1ED1BB, matching button-hex.svg's own solid colour). This is
	    what the full-opacity-by-default, 80%-on-hover rule below targets.
	  - arrow-hex-prev-glyph.svg / arrow-hex-next-glyph.svg — just the dark
	    arrow <path> from each original file, same viewBox/transform, so it
	    still lands in the exact same spot it did in the combined graphic.
	    Always full opacity — the hover request was for the hex only.
	Splide's own generated inline <svg> (the small default chevron it draws
	from options.arrowPath) is still hidden — neither layer here is that.

	--carousel-arrow-size is redefined here (was the shared 2.75rem circle)
	to these SVGs' own native 96px width — .splide__arrow's shared width/
	height rule (carousel.css) picks it up automatically, and so does this
	block's own positioning math below, which is already written in terms
	of this custom property. height is NOT tied to the same variable,
	though: these icons are 96:83, not square, so height: auto + aspect-
	ratio here (rather than the shared rule's height: var(--carousel-arrow-
	size)) is what keeps them from being squashed into a square box.
*/
.options-carousel {
	--carousel-arrow-size: 6rem; /* 96px, these icons' own native width */
}

.options-carousel .splide__arrow {
	position: relative; /* anchors the two absolutely-positioned layers below */
	width: var(--carousel-arrow-size);
	height: auto;
	aspect-ratio: 96 / 83;
	border: none;
	border-radius: 0;
	background-color: transparent;

	& > svg {
		display: none;
	}

	&:hover:not(:disabled) {
		background-color: transparent;
		border-color: transparent;
	}

	&::before,
	&::after {
		content: "";
		position: absolute;
		inset: 0;
		background-size: contain;
		background-repeat: no-repeat;
		background-position: center;
	}

	/* The hexagon — the one layer this was all for. Full opacity by
	   default, 80% on hover — not brightening on hover, dimming, the same
	   opacity-only hover convention every other themed link/icon in this
	   theme now uses (footer links, social icons, the mega menu's own
	   cards, the section menu). transitioning like every other themed
	   control's own hover state (var(--transition), components.css's own
	   .splide__arrow already transitions background-color/border-color
	   the same way). Colour is a flat #1ED1BB baked into arrow-hex-bg.svg
	   itself now (assets/images/), matching button-hex.svg's own solid
	   fill — was a light gray/white gradient before, by request. */
	&::before {
		background-image: url("../../assets/images/arrow-hex-bg.svg");
		opacity: 1;
		transition: opacity var(--transition);
	}

	&:hover:not(:disabled)::before {
		opacity: 0.8;
	}
}

/*
	Swapped from the obvious pairing (prev/prev-glyph, next/next-glyph) —
	the two source SVGs (assets/images/arrow-hex-prev.svg / -next.svg,
	still there for reference) turned out to have their own arrows pointing
	the opposite of what their filenames suggest, so the "obvious" mapping
	rendered backwards: the prev button pointing right, next pointing left.
	This is purely a glyph swap — .splide__arrow--prev/--next still control
	direction exactly as before (Splide's own click handlers are wired to
	those class names, untouched here); only which IMAGE renders on which
	side changed.
*/
.options-carousel .splide__arrow--prev::after {
	background-image: url("../../assets/images/arrow-hex-next-glyph.svg");
}

.options-carousel .splide__arrow--next::after {
	background-image: url("../../assets/images/arrow-hex-prev-glyph.svg");
}

/*
	Wide viewports only: the track fills the FULL .container width (instead
	of the shared carousel layout's own side columns for the arrows — see
	assets/css/carousel.css), so the cards line up edge-to-edge with every
	other block's content, and the prev/next arrows move outside that width
	into the page's own margin instead of squeezing the cards narrower.

	Same mechanism, same breakpoint, and same reasoning as Gallery's own
	carousel exception (blocks/gallery/gallery.css) — see that file's own
	docblock for the full explanation of why column-gap needs zeroing here
	specifically (it doesn't collapse to 0 on its own the way an empty grid
	track does) and why no grid-template-columns override is needed (Splide's
	own .splide__arrows wrapper already promotes the two buttons to direct
	grid items, so pulling them out of flow via position: absolute is enough
	for the middle track to absorb the freed width on its own).

	Not applied below this breakpoint, including the sub-30em stacked-arrows
	fallback in carousel.css, for the same reason Gallery's own version isn't
	either — there usually isn't enough room outside .container at typical
	widths for an overflowing arrow not to crowd the cards or cause real
	horizontal page scroll.

	Positioning here is deliberately different from Gallery's own version
	(flush against the track's outer edge, vertically centred): these two
	requested a 32px OVERLAP into the images horizontally, and a fixed
	absolute vertical position instead of centring on the whole card's
	height (image + text). Prev/next sides went through a swap-then-revert
	earlier in this same request — they're back on their conventional
	sides (prev left, next right) as of this version. The vertical anchor
	itself went through several geometry-derived versions (centred on the
	card, hung below the image, hung above the image, pulled up from the
	image's own bottom edge) before landing on this fixed value.

	z-index: 1 on both — without it, they were painting BEHIND the image
	wherever the two overlap (a real, reported bug, not hypothetical):
	.options-carousel establishes its own stacking context (position:
	relative, right above), and .splide__track — a normal, non-positioned
	grid item sitting at z-index:auto right beside them in that SAME
	context — was winning the paint order against these two despite them
	being position: absolute, since neither had an actual z-index of its
	own to be compared. An explicit z-index here is what makes them
	compare and win against that auto default.

	Horizontal: left/right is no longer "-(size + gap)" (Gallery's own
	flush-outside formula) — with --carousel-arrow-gap dropped from the
	equation entirely, "-(size - 32px)" instead means the icon's own far
	edge lands exactly 32px INSIDE the track/image, not outside it.

	Vertical: a fixed, requested 200px (12.5rem) from .options-carousel's
	own top edge — no transform: translateY(-50%) centring this time, by
	request; top: 200px IS the icon's own top edge, not a centring anchor.
	Deliberately NOT derived from image/card geometry the way earlier
	versions of this rule were (this block's own per-view/gap/--container-
	max math) — a plain fixed value was requested directly instead, so
	unlike those earlier versions, this one has no dependency on any of
	that geometry staying the same.
*/
@media (min-width: 96em) {
	.options-carousel {
		position: relative;
		column-gap: 0;
	}

	.options-carousel .splide__arrow--prev,
	.options-carousel .splide__arrow--next {
		position: absolute;
		z-index: 1;
		top: 12.5rem; /* 200px, fixed from .options-carousel's own top edge */
	}

	.options-carousel .splide__arrow--prev {
		left: calc(-1 * (var(--carousel-arrow-size) - 2rem)); /* 32px overlap into the image */
	}

	.options-carousel .splide__arrow--next {
		right: calc(-1 * (var(--carousel-arrow-size) - 2rem)); /* 32px overlap into the image */
	}
}

/*
	The progress line that replaces Splide's own dots (see options.php's
	docblock) — dropped into the exact grid slot .splide__pagination used to
	occupy (carousel.css: grid-column: 1 / -1, grid-row: 2, same
	margin-block-start), so it sits in the same place and spans the same
	full carousel width dots did, with no layout changes needed elsewhere.

	Two stacked 1px layers, not one: .options-progress is the always-full-
	width TRACK (30% opacity), .options-progress__bar is the shorter
	FILLED segment on top (full opacity), sized by the --options-progress-
	percent custom property options.php sets inline per instance. Both read
	the same --options-progress-color, so they're always the same hue —
	only their opacity/width differ.

	Colour swaps by section background, matching the two-state split
	requested: Dark BG's own token (light text on this theme's one true
	dark surface) on a genuinely dark section, Muted's token (this site's
	only other section-level neutral) everywhere else — Default/Muted/
	Tint/Accent all read as "light" here since every one of them pairs
	with dark section text (see tokens.css's own colour-pair comments),
	unlike Dark, the only background with light text. A single --bg-dark
	override is enough to cover that whole light-background group, since
	it's the fallback and every OTHER background stays on it.
*/
.options-progress {
	--options-progress-color: var(--color-dark-bg);
	position: relative;
	grid-column: 1 / -1;
	grid-row: 2;
	height: 1px;
	margin-block-start: var(--space-5); /* matches .splide__pagination's own gap, carousel.css */
	background-color: color-mix(in srgb, var(--options-progress-color) 30%, transparent);
}

.flex-section--options.bg-dark .options-progress {
	--options-progress-color: var(--color-muted-bg);
}

.options-progress__bar {
	position: absolute;
	inset-block: 0;
	inset-inline-start: 0;
	width: var(--options-progress-percent, 100%);
	background-color: var(--options-progress-color);
}