/**
 * core/tabs — the "Stateful colours" block style variation.
 *
 * Scoped to `.wp-block-tabs.is-style-stateful`, so a tabs block that has not selected the variation
 * — and every other block on the page — is untouched.
 *
 * NO HARDCODED COLOURS. Each state reads a custom property that
 * `includes/tabs-block-styles.php` declares per block instance from the owner's chosen palette
 * slug (`var(--wp--preset--color--<slug>)`). The fallback after the comma is what applies when a
 * state is left unset, and it is DERIVED from the block's own `color.text` — itself a theme.json
 * preset picked in core's Color panel — rather than named:
 *
 *   inactive  currentColor at 55%, via color-mix(), so the strip reads as quiet
 *   hover     full currentColor, so pointing at a tab brightens it
 *   active    full currentColor
 *
 * That is what keeps the variation preset-driven on a theme this plugin has never seen: it cannot
 * assume a `primary` or `accent` slug exists, so it derives instead of guessing.
 *
 * SPECIFICITY. Core styles the strip through `:where(.wp-block-tab-list button)` — deliberately
 * zero-specificity — and marks the active tab with
 * `:where(.wp-block-tab-list button)[aria-selected=true]::before`, a 2px `currentColor` underline.
 * Because that indicator uses currentColor, colouring the button recolours the underline for free;
 * nothing here re-declares it. These rules are (0,3,1) at most and clear core's (0,1,0) without
 * `!important`.
 *
 * `aria-selected` is the state's source of truth: core's tab-list binds it with the Interactivity
 * API (`data-wp-bind--aria-selected`, see wp-includes/blocks/tab-list.php), so the look and the
 * behaviour can never disagree, and keyboard activation repaints exactly like a click.
 */

.wp-block-tabs.is-style-stateful .wp-block-tab-list button {
	color: var( --insta-tab-inactive, color-mix( in srgb, currentColor 55%, transparent ) );
	transition: color 0.2s ease;
}

/* `:focus-visible` shares the hover colour so keyboard users get the same affordance as a pointer;
   core's own focus outline is left alone. */
.wp-block-tabs.is-style-stateful .wp-block-tab-list button:hover,
.wp-block-tabs.is-style-stateful .wp-block-tab-list button:focus-visible {
	color: var( --insta-tab-hover, currentColor );
}

/* Last so it wins over :hover — pointing at the tab you are already on must not dim it. */
.wp-block-tabs.is-style-stateful .wp-block-tab-list button[aria-selected="true"] {
	color: var( --insta-tab-active, currentColor );
}

/* No underline on the active tab.
 *
 * Core marks the active tab with `:where(.wp-block-tab-list button)[aria-selected=true]::before` —
 * a 2px currentColor rule along the bottom (wp-includes/blocks/tab-list/style.css). This variation
 * distinguishes the states by COLOUR alone, so the rule is removed with `content: none`, which
 * drops the pseudo-element rather than merely hiding it. Core's selector is (0,1,0); this is
 * (0,3,1), so no `!important` is needed.
 *
 * The indicator is `position: absolute`, so removing it changes no geometry — the tab strip and the
 * panels keep the exact same box.
 */
.wp-block-tabs.is-style-stateful .wp-block-tab-list button[aria-selected="true"]::before {
	content: none;
}

@media ( prefers-reduced-motion: reduce ) {
	.wp-block-tabs.is-style-stateful .wp-block-tab-list button {
		transition: none;
	}
}

/* ─────────────────────────────────────────────────────────────────────────────
 * "Panels before labels" — put the panel ahead of the tab strip visually.
 *
 * ⚠ DO NOT DO THIS BY REORDERING THE BLOCKS. core/tabs' editor enforces the child order
 * `core/tab-list` then `core/tab-panels`, and a document saved the other way round is reconciled
 * on load — destructively. Measured on WP 7.1: a 6-panel block stored panels-first opens in the
 * editor with 2 panels and empty labels, reports `isDirty: false`, and writes that loss to the
 * database on the next save. The markup must stay canonical; only the PAINT order changes here.
 *
 * `order` needs a flex or grid container, which core/tabs' own `layout` attribute supplies — this
 * rule is inert on the default flow layout rather than wrong.
 * ───────────────────────────────────────────────────────────────────────────── */
/*
 * SCOPED ABOVE MOBILE. The flip exists so a horizontal tab set can show its panel on the LEFT and
 * its labels on the RIGHT. Once the block wraps to a single column that intent no longer applies,
 * and the flip becomes actively wrong: the panel sits first and the tab strip lands at the BOTTOM
 * of the section, so a visitor reads the content before discovering the control that changes it.
 * Below the breakpoint the canonical DOM order (list, then panels) is the correct reading order.
 *
 * 767px matches the mobile tier used by `is-style-overlay-from-tablet` in header-overlay.css.
 */
@media (width > 767px) {
	.wp-block-tabs.is-style-panels-first > .wp-block-tab-panels {
		order: 1;
	}

	.wp-block-tabs.is-style-panels-first > .wp-block-tab-list {
		order: 2;
	}
}

/* ─────────────────────────────────────────────────────────────────────────────
 * "Steady panel height" — the section keeps one height whichever tab is open.
 *
 * THE PROBLEM, measured on this install at 768px: the panels' copy wraps to a different number of
 * lines per tab (3 of 6 wrap to two lines), so the panel is 443px for some tabs and 481px for
 * others and everything below the tabs jumps 38px on each click. At 1440 and 390 every panel
 * happens to wrap alike, which is why the fault only shows at some widths.
 *
 * WHY NOT `min-block-size: 2lh` ON THE COPY. Reserving two lines fixes 768 but adds a blank line at
 * 1440, where nothing wraps — trading a jump for permanent dead space, and it needs a per-design
 * guess at how many lines to reserve.
 *
 * INSTEAD, all panels share one grid cell so the container is always as tall as the TALLEST panel,
 * at any width, with no reserved-line count to maintain. The inactive panels keep their `hidden`
 * attribute — so they stay out of the accessibility tree and out of tab order — and `visibility`
 * conceals them, which (unlike `display: none`) still lets them contribute height.
 *
 * The `!important` is unavoidable: core hides panels with
 * `.wp-block-tab-panel[hidden] { display: none !important }` in wp-includes/blocks/tab-panel/style.css,
 * and a non-important declaration cannot beat it at any specificity. `visibility: hidden` restores
 * exactly the concealment that `display: none` was providing.
 * ───────────────────────────────────────────────────────────────────────────── */
.wp-block-tabs.is-style-steady-height .wp-block-tab-panels {
	display: grid;
}

.wp-block-tabs.is-style-steady-height .wp-block-tab-panel {
	grid-area: 1 / 1;
}

.wp-block-tabs.is-style-steady-height .wp-block-tab-panel[hidden] {
	display: block !important;
	visibility: hidden;
}

/* The copy occupies TWO LINES whichever tab is open, so the text block itself is as steady as the
 * box around it — a one-line sentence no longer sits higher than a two-line one.
 *
 * `2lh` is two of the paragraph's OWN line boxes, so it tracks the fluid font size automatically
 * (26px/38px line at desktop, 16px/23.5px at mobile) with no per-breakpoint value to maintain.
 * At 390 the copy already wraps to two lines everywhere, so this reserves exactly what is already
 * there and changes nothing; at 1440 it adds one line's worth of space below the shorter copies,
 * which is the trade the author chose for a uniform text block.
 *
 * Direct child only: a panel holding several paragraphs should not have every one of them padded.
 */
.wp-block-tabs.is-style-steady-height .wp-block-tab-panel > p {
	min-block-size: 2lh;
}