/* Problems we solve detail-page section spacing, measured from the desktop/mobile Figma frames. */
.bpd-problem-hot-take,
.bpd-problem-stats,
.bpd-problem-how,
.bpd-problem-download,
.bpd-problem-receipts,
.bpd-problem-keep-growing,
.bpd-problem-your-move {
	padding-top: var(--wp--preset--spacing--2500);
	padding-bottom: var(--wp--preset--spacing--2500);
}

.bpd-problem-worth {
	padding-top: var(--wp--preset--spacing--2500);
	padding-bottom: var(--wp--preset--spacing--1200);
}

@media (max-width: 781px) {
	.bpd-problem-hot-take,
	.bpd-problem-stats,
	.bpd-problem-how,
	.bpd-problem-download,
	.bpd-problem-receipts,
	.bpd-problem-keep-growing,
	.bpd-problem-your-move {
		padding-top: var(--wp--preset--spacing--1500);
		padding-bottom: var(--wp--preset--spacing--1500);
	}

	.bpd-problem-worth {
		padding-top: var(--wp--preset--spacing--1500);
		padding-bottom: var(--wp--preset--spacing--800);
	}
}

/* --------------------------------------------------------------------------------------------
 * Tabbed panels (Figma 6050:35985 desktop / 6050:39016 mobile).
 *
 * No JS: each tab is an in-page anchor to its panel's id, and `:target` picks the visible panel.
 * The whole hide/show layer sits inside `@supports selector(:has(*))` on purpose — without `:has`
 * there is no way to express "nothing is targeted, show the first panel", so those browsers get
 * every panel stacked, i.e. exactly the pre-tabs page. Final state is the default; the enhancement
 * is what's conditional.
 * ------------------------------------------------------------------------------------------ */

/* Pillar name above the tab row (Figma 6050:35968; GitHub #79 "header added for each child page"
   and #94 "add the pillar name" -- the same element filed twice, desktop and mobile).

   H2, not the H1 Figma's style panel names: the hero above already owns this page's H1, and #87
   asks for content headlines to be H2. Figma's structure lags the build here; its rendered size
   (heading-lg / 32px) is still authoritative and is what the preset gives.

   Padding lives here rather than inline on the block because an inline style would out-specify the
   mobile query below, and overriding that would need !important. Figma's 40px heading-to-tabs gap
   is this block's padding-bottom plus the row's zeroed padding-top. */
.bpd-problem-title {
	padding-top: var(--wp--preset--spacing--2500);
	padding-bottom: var(--wp--preset--spacing--1000);
	padding-inline: var(--wp--preset--spacing--gutter);
}

.bpd-problem-tabs {
	/* Zero, not 2500: .bpd-problem-title immediately above now carries the section's top padding.
	   Every one of the six detail pages renders that title, so there is no page where this would
	   leave the row flush against what precedes it. */
	padding-top: 0;
	padding-bottom: var(--wp--preset--spacing--1500);
}

.bpd-problem-tabs__list {
	gap: var(--wp--preset--spacing--800);
	/* The 1px rule under the row is an inset shadow rather than a border. A border sits OUTSIDE the
	   padding box, so the active tab had to be pulled over it with `margin-bottom: -1px` -- and
	   once overflow-y is hidden (below) clipping happens at the padding box, which shaved exactly
	   that 1px off the 4px underline. Measured: 3 purple rows rendered instead of 4, with the rule
	   showing through the gap. An inset shadow paints inside the padding box, so the active tab's
	   own border covers it with no negative margin and nothing to clip. */
	box-shadow: inset 0 -1px 0 var(--wp--preset--color--blue-300);
	/* The rule under the row spans the tabs themselves, not the content width — so the box shrinks
	   to its contents and re-centres. */
	width: fit-content;
	max-width: 100%;
	margin-inline: auto;
	/* The row is wider than a 375px viewport by design (Figma keeps one row on mobile), so it
	   scrolls sideways rather than wrapping or shrinking the type. */
	overflow-x: auto;
	/* Setting one axis to a non-visible value computes the OTHER axis from `visible` to `auto`, so
	   the row silently became vertically scrollable too. The active tab's `margin-bottom: -1px`
	   (below) pushes its border 1px past the content box, which is enough to trip it: measured
	   clientHeight 39 vs scrollHeight 40, at 1440 as well as 375 -- i.e. even with no horizontal
	   scrolling at all. Left alone that is a stray 1px vertical scroll, and a visible scrollbar
	   wherever the platform draws them. */
	overflow-y: hidden;
}

/* The block sets justifyContent:center, so core emits .is-content-justification-center. Harmless
   while the row fits -- the container is width:fit-content and centres itself via margin-inline:
   auto, so the inner justification does nothing. Once max-width:100% clamps the container and the
   row overflows, though, centring pushes the overflow out BOTH sides and the left half becomes
   unreachable: measured at 375, the active "Our hot take" tab sat at x:-86, off the left edge with
   no way to scroll back to it. Start-alignment is correct in the overflow case and a no-op
   otherwise, so it is not scoped to a media query. Matching both classes (0,2,0) beats core's
   single class without !important. */
.bpd-problem-tabs__list.is-content-justification-center {
	justify-content: flex-start;
}

.bpd-problem-tabs__list p {
	margin: 0;
	white-space: nowrap;
}

.bpd-problem-tabs__list a {
	display: block;
	padding: 0 var(--wp--preset--spacing--100) var(--wp--preset--spacing--300);
	color: inherit;
	text-decoration: none;
	border-bottom: 4px solid transparent;
	/* No `margin-bottom: -1px` here any more -- see the inset shadow on the list above. */
}

@supports selector(:has(*)) {
	.bpd-problem-panel {
		display: none;
		/* Keep the tab row on screen when :target scrolls to the panel. */
		scroll-margin-top: var(--wp--preset--spacing--2500);
	}

	.bpd-problem-panel:target,
	body:not(:has(.bpd-problem-panel:target)) #hot-take {
		display: block;
	}

	body:not(:has(.bpd-problem-panel:target)) .bpd-problem-tabs a[href="#hot-take"],
	.bpd-problem-tabs:has(~ #hot-take:target) a[href="#hot-take"],
	.bpd-problem-tabs:has(~ #by-the-numbers:target) a[href="#by-the-numbers"],
	.bpd-problem-tabs:has(~ #how-we-get-done:target) a[href="#how-we-get-done"],
	.bpd-problem-tabs:has(~ #worth-a-read:target) a[href="#worth-a-read"] {
		/* Selected tab's 4px rule is the accent purple (Figma 6050:35968 -> surface-accent
		   #7038af), not the navy it used to be -- GitHub #79. */
		border-bottom-color: var(--wp--preset--color--surface-accent);
	}
}

@media (max-width: 781px) {
	.bpd-problem-title {
		padding-top: var(--wp--preset--spacing--1500);
	}

	.bpd-problem-tabs {
		padding-bottom: var(--wp--preset--spacing--800);
	}

	/* The row only overflows below this breakpoint, and the scrollbar is painted along the bottom of
	   the padding box — exactly where the active tab's 4px underline sits, so on platforms with
	   overlay scrollbars (Android) it is drawn straight over the purple. Reserve a band beneath the
	   tabs for it.

	   That band would drag the 1px rule down with it and leave the active underline floating clear
	   of the rule, since an inset shadow can only paint at the padding-box edge. A background line
	   can be positioned independently, so the rule stays on the tabs' baseline while the scrollbar
	   gets the space below. background-attachment defaults to `scroll`, which pins the line to the
	   element rather than the scrolled content, so it does not slide away with the tabs. */
	.bpd-problem-tabs__list {
		padding-bottom: var(--wp--preset--spacing--300);
		box-shadow: none;
		background-image: linear-gradient(
			var(--wp--preset--color--blue-300),
			var(--wp--preset--color--blue-300)
		);
		background-repeat: no-repeat;
		background-size: 100% 1px;
		background-position: left calc(100% - var(--wp--preset--spacing--300));
	}
}
