/*
 * wakefly/stats-kpi -- the one scoped stylesheet this block needs.
 *
 * Loaded through block.json's `style`/`editorStyle`, so it is enqueued only on a page that
 * renders the block and it is unaffected by the SCRIPT_DEBUG style.css/style.min.css split
 * in functions.php.
 *
 * Colour and the label's two type sizes are theme.json presets, read through the utility
 * classes core already generates from them (`.has-secondary-color`,
 * `.has-body-text-color`, `.has-large-font-size`) rather than restated as literals here --
 * a token before a declaration, per CLAUDE.md's build preference order. The value's own
 * font size is the one exception, and the comment on it says why.
 */

/*
 * BORDER-BOX, SCOPED TO THIS BLOCK. Neither WordPress core nor this theme sets a global
 * box-sizing reset, and core's own `* { box-sizing: border-box }` ships inside the block
 * library stylesheet, which is only enqueued for blocks core knows are on the page -- this
 * block's markup is written by hand, so none of it applies.
 */
.wp-block-wakefly-stats-kpi,
.wp-block-wakefly-stats-kpi *,
.wp-block-wakefly-stats-kpi *::before,
.wp-block-wakefly-stats-kpi *::after {
	box-sizing: border-box;
}

/*
 * THE ROOT. MEASURED AT ALL FOUR VIEWPORTS (unit structure, root box): 1296x175 at 1440,
 * 936x160 at 1024, 696x166 at 768, 366x151 at 390 -- the same four padding numbers at every
 * one, which is why the asymmetry is written here rather than as a responsive rule.
 *
 * padding-inline 3.125rem is _stats-kpi.scss's own `padding: 3.125rem`; padding-block
 * 1.5rem is the shared `py-4` utility overriding that axis only, which is why the two
 * padding values differ rather than the block simply carrying one number. Background white
 * is the utility class on the wrapper (has-white-background-color has-background) rather
 * than a declaration here, because the surrounding page is not white and this is a real,
 * measured paint rather than an inherited default.
 *
 * display/align-items: the source's flex row, holding the two arrow buttons and the
 * slides row on one line, vertically centred.
 */
.wp-block-wakefly-stats-kpi {
	display: flex;
	align-items: center;
	padding-block: 1.5rem;
	padding-inline: 3.125rem;
}

/* -------------------------------------------------------------------------- the intro */

/*
 * NOT INSTANTIATED ON THE CAPTURED INSTANCE -- no box for this element exists in the
 * reference, so nothing here is measured. This is the field's own default rich-text
 * spacing and nothing more, so a filled-in Intro does not collide with the row below it.
 */
.wp-block-wakefly-stats-kpi__intro {
	width: 100%;
	margin-block-end: 1rem;
}

/* -------------------------------------------------------------------------- the arrows */

/*
 * `.stats-kpi-prev, .stats-kpi-next` (_stats-kpi.scss lines 15-26, per the unit's own
 * `chrome`): no background, no border, 0.375rem/0.5625rem padding -- MEASURED 6px and 9px
 * -- cursor pointer, colour $nav-text (this theme's `body-text` slug). Box 34x28 at 1440 is
 * an OUTCOME of this padding around the 16x16 glyph inside it, not a stated size.
 *
 * NO CLICK HANDLER, NO data-wp-on, NO viewScriptModule anywhere in this block. The unit's
 * own `behaviour` field measures these buttons as dead in the source -- nothing in the
 * source's script tree binds to them at all -- so this reproduces a button that does
 * nothing rather than inventing motion the source never had.
 *
 * `font-size: inherit; line-height: inherit` REPRODUCES THE SOURCE'S OWN RULE, and it is the
 * one thing this rule was missing. _stats-kpi.scss sets neither, so on the source the button
 * takes Bootstrap Reboot's `button { font-family: inherit; font-size: inherit; line-height:
 * inherit; }` and lands on the page's own 16px/24px. Nothing in this theme resets a `<button>`,
 * so without these two the element fell through to Chromium's UA default instead.
 *
 * MEASURED 2026-09-09, `tooling/extract/probe.js` with both sides side by side at 1440x900,
 * `--props=fontSize,lineHeight,width,height,padding`, source
 * /sandbox/page-builder-components/stats-kpi against the local instance:
 *
 *              source (button / its svg)      build BEFORE          build AFTER
 *   fontSize   16px                           13.3333px             16px
 *   lineHeight 24px                           normal                24px
 *   box        34x28 / svg 16x16              34x28 / 16x16         34x28 / 16x16
 *
 * IT IS INERT AND IS FIXED ANYWAY. The glyph is `rem`-sized and the padding is `rem`-sized,
 * so neither number moves a box on either side -- the button measures 34x28 and the svg 16x16
 * at all four viewports before and after. What it removes is 24 computed-style rows (2 buttons
 * x 3 nodes x 4 viewports) that differ for a reason no one has to adjudicate.
 *
 * The brief that ordered this fix had the two sides the wrong way round -- it read "chevron
 * 16px on the build against 13.3333px on the reference" -- and named `font-size: 1rem` as the
 * whole of it. The direction of the fix was right; the measurement above is which side was
 * which, and `inherit` rather than `1rem` is what the source actually does.
 */
.wp-block-wakefly-stats-kpi__arrow {
	display: flex;
	align-items: center;
	justify-content: center;
	padding-block: 0.375rem;
	padding-inline: 0.5625rem;
	border: none;
	background-color: transparent;
	color: var(--wp--preset--color--body-text);
	font-size: inherit;
	line-height: inherit;
	cursor: pointer;
}

.wp-block-wakefly-stats-kpi__glyph {
	width: 1rem;
	height: 1rem;
	fill: none;
	stroke: currentColor;
}

/* -------------------------------------------------------------------------- the slides row */

/*
 * div.stats-kpi-slides: MEASURED 1128x127 at 1440, 768x112 at 1024, 528x118 at 768, 198x103
 * at 390 -- in every case the root's content box (padding removed) less the two 34px-wide
 * arrow buttons. `flex: 1` lets it take exactly that remaining space; `overflow: hidden`
 * is the source's own rule and is what the unit's `behaviour` field's clipping note is
 * about -- at 390 the four items no longer fit and the last ones are cut with no way to
 * reach them, because the controls that would scroll to them are the dead buttons above.
 * That is reproduced faithfully rather than corrected, per the field's own note.
 *
 * THERE IS DELIBERATELY NO `justify-content` HERE. A literal `justify-content: space-between`
 * stood on this rule until 2026-09-09 and it was the ONLY place the value came from: this
 * block's markup is written by render.php, whose slides div carries one class and no
 * `wp-container-*` or `is-layout-*` (probed on /?page_id=125, `matched 1`,
 * `@class=wp-block-wakefly-stats-kpi__slides` and nothing else), so no core layout rule is
 * emitted for it and the contract's `layout` attributes reach nothing at render.
 *
 * THE SOURCE HAS NO `justify-content` AT ALL -- `normal` is the initial value, and its equal
 * columns come from the `flex: 1 0 0` on each item below, which is a different mechanism with
 * the same picture. Removing the declaration is what the unit's own `structure` records
 * (the attribute was taken off that node in peer-review round 5, 2026-09-10, having been
 * invented rather than read off the capture).
 *
 * MEASURED BOTH WAYS, 2026-09-09, `tooling/extract/probe.js` on /?page_id=125 at 1440x900,
 * 1024x768, 768x1024 and 390x844:
 *
 *                     before            after
 *   justify-content   space-between     normal
 *   box               1128x127 / 768x112 / 528x118 / 198x103 -- IDENTICAL, all four
 *
 * IT CHANGES NO RENDERED BOX AND IS STILL WORTH DOING: it was four of the eight rows in this
 * unit's comparison, one per viewport, each `corroborated`, ref `normal` against local
 * `space-between`. At 390 the row's content overflows it, so free space is negative and
 * `space-between` degenerates to flex-start there anyway -- different arithmetic, same
 * picture, and the computed property differed at every viewport regardless.
 */
.wp-block-wakefly-stats-kpi__slides {
	display: flex;
	flex: 1;
	flex-wrap: nowrap;
	overflow: hidden;
}

/*
 * ONE ITEM'S OWN BOX. MEASURED at all four viewports: gap 0.625rem (10px), flex-direction
 * column, align-items center. `flex: 1 0 0` divides the row equally between however many
 * items render, matching the source's own `flex: 1 0 0` on each stat -- at 390 the items'
 * content outgrows the space this gives them, which is the clipping above.
 *
 * THERE IS DELIBERATELY NO `justify-content` HERE, AND RE-ADDING ONE IS A VISIBLE
 * REGRESSION. The unit's `structure` writes this item as
 * `layout: {type: flex, orientation: vertical, justifyContent: center}`, and core's own
 * non-horizontal branch (wp-includes/block-supports/layout.php, lines 795-814) emits
 * `align-items` from `justifyContent` and emits `justify-content` ONLY from
 * `verticalAlignment` -- which this contract does not carry. So the contract asks for the
 * `align-items: center` on the line above and for nothing on the block axis.
 *
 * MEASURED, 2026-09-09, at 768x1024 with a hand-written `justify-content: center` on this
 * rule: the two items whose label fits on one line ("10K+", "24/7") had their value's box
 * top at y=315 against y=303 for the two whose label wraps to two lines, i.e. the four
 * figures did not share a baseline. The reference shares one. Removing the declaration put
 * all four at y=303. `flex: 1 0 0` does not make this inert -- it governs the ROW axis,
 * along which this item is a flex ITEM; `justify-content` here acts on the COLUMN axis,
 * along which this item is a flex CONTAINER stretched to its tallest sibling's height.
 */
.wp-block-wakefly-stats-kpi__item {
	display: flex;
	flex: 1 0 0;
	flex-direction: column;
	align-items: center;
	gap: 0.625rem;
}

/* -------------------------------------------------------------------------- the value */

/*
 * p.stats-kpi-value. Colour (`has-secondary-color`) and weight/alignment are constant at
 * every viewport; MEASURED rgb(240,100,0), weight 800, centred. Line-height is not stated
 * here because it is not stated ANYWHERE for this element -- theme.json's own root
 * lineHeight is 1.5 and every one of the four measured line-height/font-size pairs below
 * (90/60, 75/50, 60/40, 45/30) is exactly that ratio, so it is inherited rather than
 * restated.
 *
 * THE FONT SIZE IS FOUR MEASURED NUMBERS, WRITTEN AS LITERALS RATHER THAN A PRESET. Only
 * one of them -- 2.5rem at 768 -- happens to equal this theme's `xx-large` rung; the other
 * three (3.75rem, 3.125rem, 1.875rem) are on neither this theme's fontSizes nor
 * WordPress's own, and adding rungs to carry them is not this package's decision to make
 * (site.yml's settings.typography.fluid is `decided` false with its own named revisit
 * trigger; overwriting that here would re-open a decision already recorded --
 * docs/package-discipline.md §11.5). So all four live here, in the block's own stylesheet,
 * exactly where the source keeps them (_stats-kpi.scss lines 43-61).
 *
 * THE BREAKPOINTS THEMSELVES ARE NOT MEASURED, ONLY THE FOUR VALUES AT THE FOUR CAPTURED
 * VIEWPORTS ARE. The unit's own reference does not name where between 768 and 1024, or
 * between 1024 and 1440, the source's own step actually falls -- unlike the label below,
 * whose contract states its step outright (`media-breakpoint-up(lg)`, i.e. 992px). Absent
 * that, this rule steps at each measured viewport's own width, which reproduces the four
 * sampled points exactly and invents nothing between them. Flagged in the hand-back as an
 * assumption a narrower capture could correct.
 *
 * MARGIN IS ZEROED ON PURPOSE, on this element and the label below. The unit's own
 * `structure` commits to an item box of exactly 90 + 10 (gap) + 27 = 127px at 1440 with no
 * further term in that sum -- a bare `<p>` carries the user-agent stylesheet's own `1em`
 * block margin top and bottom, which at a 60px value line alone adds another 120px never
 * accounted for there. Zeroing it is what makes the two lines actually sit 10px apart
 * instead of the gap disappearing under the browser default.
 */
.wp-block-wakefly-stats-kpi__value {
	margin: 0;
	font-weight: 800;
	text-align: center;
	font-size: 1.875rem;
}

@media (min-width: 768px) {
	.wp-block-wakefly-stats-kpi__value {
		font-size: 2.5rem;
	}
}

@media (min-width: 1024px) {
	.wp-block-wakefly-stats-kpi__value {
		font-size: 3.125rem;
	}
}

@media (min-width: 1440px) {
	.wp-block-wakefly-stats-kpi__value {
		font-size: 3.75rem;
	}
}

/* -------------------------------------------------------------------------- the label */

/*
 * p.stats-kpi-label. Colour (`has-body-text-color`, a class in the markup) and
 * weight/alignment are constant. _stats-kpi.scss steps `.stats-kpi-label` from 1rem to
 * 1.125rem at media-breakpoint-up(lg) -- i.e. 992px -- and both rungs are on this theme's
 * own ladder (`large`/`medium`), so the font-size is written here as the two preset
 * variables rather than as a literal, stepping at 991.98px to match this theme's existing
 * convention for the same Bootstrap breakpoint (hero-carousel/style.css,
 * mega-menu-panel/style.css).
 *
 * NOT WRITTEN AS THE GENERATED `.has-large-font-size` / `.has-medium-font-size` UTILITY
 * CLASSES, and that is a deliberate departure from doing this the same way the colour is
 * done. Core emits every one of those utilities `!important`
 * (`.has-large-font-size{font-size: var(--wp--preset--font-size--large) !important;}`,
 * confirmed in this site's own rendered `global-styles-inline-css`), so no ordinary
 * selector -- of any specificity, in any load order -- can step it back down at a narrower
 * viewport. MEASURED: with the utility class in the markup the label stayed at 18px through
 * 768 and 390 regardless of a same-specificity or higher-specificity override here. Reading
 * the preset variable directly is still a token rather than a literal; it just is not the
 * class core generates from it.
 */
.wp-block-wakefly-stats-kpi__label {
	margin: 0;
	font-weight: 800;
	text-align: center;
	font-size: var(--wp--preset--font-size--large);
}

@media (max-width: 991.98px) {
	.wp-block-wakefly-stats-kpi__label {
		font-size: var(--wp--preset--font-size--medium);
	}
}