/*
	FAQ accordion — native <details>/<summary>, so expand/collapse, keyboard
	support and the correct screen-reader semantics come from the browser,
	not hand-rolled JS. The indicator is a plus/minus pair (assets/icons/
	plus.svg, minus.svg), not a single rotating icon — both render into the
	same grid cell (.faq-item__icon, below) and [open] toggles which one is
	visible, since a plain rotate/transform can't turn a "+" into a "−" (a
	minus is already a 180deg-symmetric shape, so there's no rotation that
	distinguishes open from closed the way it does for an arrow).
*/

.faq-list {
	display: flex;
	flex-direction: column;
}

/* Minimal (Item Style's default — no .faq-list--boxed): no background or
   padding, a muted divider between items instead. */
.faq-list:not(.faq-list--boxed) .faq-item {
	border-bottom: 1px solid var(--color-border);

	&:first-child {
		border-top: 1px solid var(--color-border);
	}
}

/*
	Boxed: a literal white background and padding per item — not
	--color-default-bg (the page background, currently a light gray), so it
	stays white regardless of the section's own Background field. A 1px gap
	replaces the divider: a solid white item touching its neighbour would
	otherwise read as one continuous box. A literal 1px, not a --space-*
	token — a hairline seam, same "not on the spacing scale" treatment
	every other 1px border width in this theme gets.
*/
.faq-list--boxed {
	gap: 1px;
}

.faq-list--boxed .faq-item {
	padding-inline: var(--space-5); /* 24px */
	background-color: var(--color-white);
	color: var(--color-white-fg);
}

.faq-item__question {
	display: flex;
	align-items: center;
	justify-content: space-between;
	gap: var(--space-4);
	padding-block: var(--space-5); /* 24px */
	font-size: var(--faqs-question-size); /* 17px */
	font-weight: var(--font-weight-medium);
	cursor: pointer;

	/* The native marker (default triangle, or a bullet in some browsers) is
	   replaced by the plus/minus icon below, not left in place alongside it. */
	list-style: none;

	&::-webkit-details-marker {
		display: none;
	}
}

/*
	Both icons are grid items sharing the same cell (grid-area: 1 / 1) —
	display alone toggles which one shows, rather than positioning one
	absolutely over the other. The wrapping spans (not the <svg>s
	themselves) are what's placed in the grid, since sd_icon()'s raw <svg>
	output has no class hook of its own to target directly; each svg then
	just stretches to fill its own span (grid's default stretch alignment).
*/
.faq-item__icon {
	display: grid;
	flex: none;
	width: 1.25rem; /* 20px */
	height: 1.25rem; /* 20px */

	& svg {
		width: 100%;
		height: 100%;
	}
}

.faq-item__icon-plus,
.faq-item__icon-minus {
	grid-area: 1 / 1;
}

.faq-item__icon-minus {
	display: none;
}

.faq-item[open] .faq-item__icon-plus {
	display: none;
}

.faq-item[open] .faq-item__icon-minus {
	display: block;
}

.faq-item__answer {
	padding-block-end: var(--space-5);

	/*
		font-size on the container alone doesn't reach the answer text: it's
		wrapped in <p> tags (WYSIWYG output), so this has to override the
		<p>/<li> themselves, not just this wrapper. Real element selectors
		(& p, & li), not :where(p, li) — :where() contributes zero
		specificity, which lost outright to .prose's own `.prose p` /
		`.prose li` rule (typography.css) regardless of source order, since
		this answer div carries both .faq-item__answer and .prose. Matching
		.prose's own (class + element) specificity here is what lets source
		order (this file loads after typography.css) actually decide it.
	*/
	& p,
	& li {
		font-size: var(--faqs-answer-size); /* 15px */
	}
}