/**
 * core/image — the three information-band icons in the footer.
 *
 * Loaded by xperience_starter_enqueue_core_block_styles() in functions.php through
 * wp_enqueue_block_style( 'core/image', … ), the same mechanism and for the same reasons as
 * core-group.css beside it.
 *
 * THE ONE RULE: core's own wp-includes/css/dist/block-library/style.css sets
 * `.wp-block-image img { height: auto; max-width: 100%; vertical-align: bottom; }` and
 * nothing else on `display` — so `<img>` keeps the UA default of `inline`, checked against
 * this install's own stylesheet rather than assumed. Measured on the source (unit-fidelity
 * check, footer, 1440x900): these three icons compute `display: block`, matching Bootstrap's
 * own `img { vertical-align: middle }`-adjacent reset most themes carry and this one does
 * not. `display: inline` on a replaced element does not change the icon's own box (`width`/
 * `height` are set inline on the `<img>` itself either way), so this is a display-mode
 * correction only, not a size fix.
 *
 * SCOPED to the footer's information-band columns specifically (`.wp-block-column.footer-
 * content`, the same className hook core-column.css already uses for this exact column) so
 * the rule cannot reach a core/image instance anywhere else on the site — the header's
 * account icons and avatar images have not been measured against this rule and must not
 * inherit it by accident.
 *
 * @package WordPress
 * @subpackage Xperience_Starter
 * @since Xperience Starter 1.0
 */

.wp-block-column.footer-content .wp-block-image img {
	display: block;
}

/*
 * THE `flex-shrink: 0` RULE THAT STOOD HERE IS GONE, AND THE ICON IS PINNED BY A BLOCK
 * ATTRIBUTE INSTEAD. Removed 2026-09-10. patterns/footer.php now writes
 * `"style":{"layout":{"selfStretch":"fixedNoShrink","flexSize":"40px"}}` on each of the
 * three information-band images, and core emits `flex-basis:40px; flex-shrink:0` for it
 * from wp_get_child_layout_style_rules() (wp-includes/block-supports/layout.php:109-160).
 * CLAUDE.md's build preference order is why: the attribute is a rung above a stylesheet
 * rule, and each step down is more code to own forever.
 *
 * THE SENTENCE THAT JUSTIFIED THE RULE WAS FALSE IN BOTH ITS CLAUSES. It read:
 * "`flex-shrink` HAS NO BLOCK ATTRIBUTE TO LIVE IN, checked rather than assumed:
 * wp-includes/blocks/image/block.json on this install declares no layout support ... and
 * core writes a flex-item declaration for a child of a flex layout only through
 * `style.layout.selfStretch`, which is core/group's and sets `flex-grow`, not
 * `flex-shrink`. So there is no rung above CSS for it." Measured on this install
 * 2026-09-10 by calling the function directly: `{selfStretch:"fixedNoShrink",
 * flexSize:"40px"}` returns `flex-basis:40px · flex-shrink:0 · box-sizing:border-box`,
 * and `wp_render_layout_support_flag()` reads `style.layout` off the PARSED BLOCK
 * (layout.php:979, :997-1004), so it is NOT gated on the child block's own `supports` —
 * core/image's `supports.layout` is NULL here and the class lands on its <figure> anyway.
 * The false half was that core/group is the only block it works on; what is true is only
 * that the EDITOR offers the control just for a flex/grid parent declaring
 * `allowSizingOnChildren`. Hand-written markup — which a pattern file is — is honoured
 * either way. reference/sources/block-attributes.md §Siblings carries the measurements.
 *
 * TWO TRAPS, SO NOBODY REACHES FOR THE OBVIOUS SPELLING. Core maps `max`->`fixed` and
 * `fixed`->`fixedNoShrink` (layout.php:126-131), so `"fixed"` — the word anyone reaches
 * for — is the value that STILL SHRINKS; only `"fixedNoShrink"` pins. And the
 * `box-sizing: border-box` core puts in the rule never reaches the stylesheet:
 * safecss_filter_attr() drops it because `box-sizing` is absent from kses's allowlist
 * while flex-basis/-grow/-shrink are in it. Measured here: the compiled CSS is
 * `{flex-basis:40px;flex-shrink:0}`. So a `flexSize` is a CONTENT-BOX width. It is exact
 * for these icons because the <figure> carries no padding and no border; a child that did
 * would measure wider than the number written.
 *
 * WHAT THE MOVE MUST NOT CHANGE, and was re-measured on both sides of it: the icons are
 * 40x40 at 1440x900, 1024x768, 768x1024 and 390x844, and the first column's body group is
 * 102x414 at 390x844 — the contract's own derivation of the source's `40 + 16 + 102 = 158`
 * column, whose two figures the CSS rule had landed on without targeting them.
 */

/*
 * THE image-link CAPTION OVERLAY. Scoped to `wf-image-link`, the className patterns/image-link.php
 * writes on its own <figure>, so nothing here reaches another core/image on the site -- an
 * unscoped `.wp-block-image figcaption` rule would be a decision about the theme rather than
 * about this unit, and that is wp-theme-scaffold's.
 *
 * WHAT THE SOURCE DOES. units/image-link.yml's structure note records `.image-inner-caption` as
 * `position: absolute; bottom: 0` inside the SAME `.image-inner` box the image occupies, with
 * `padding $spacer`, `background-color $background-tint-color`, `font-size $font-size-lg`,
 * `color $white` (components/_image.scss). Those four are SCSS variable names and no capture of
 * THIS unit resolved them to pixels.
 *
 * WHERE THE RESOLVED NUMBERS COME FROM, NAMED RATHER THAN GUESSED. They were measured on the
 * sibling unit that renders the identical `.image-inner` / `.image-inner-caption` markup from
 * the same stylesheet -- image-link-carousel, whose own blocks/image-link-carousel/style.css
 * carries them: "500x62 at the media box's bottom edge, position absolute, background
 * rgba(33,37,41,0.6), colour rgb(255,255,255), 16px padding on all four sides, 20px/30px weight
 * 700". So $spacer = 16px (this theme's spacing 40), $background-tint-color = rgba(33,37,41,0.6)
 * = this theme's `dark` #212529 at 60% (no palette slug can carry the alpha, so the rgba() is
 * knowingly raw), $font-size-lg = 20px (this theme's x-large) and $white = #fff. THIS IS A
 * CROSS-UNIT INFERENCE, not a measurement of this unit's own capture: it is sound because both
 * widgets emit the same class from the same SCSS rule, and it is stated here so a later pass
 * can refute it against this unit's own reference rather than rediscover it.
 *
 * core/image draws its caption BELOW the picture, so the figure measured 500x542 before this
 * rule and 500x500 after it -- the source's own box.
 *
 * NO WIDTH IS DECLARED HERE AND THAT IS CHECKED, NOT ASSUMED. core's `.wp-block-image.is-resized`
 * is `display: table`, so the figure shrink-wraps the <img> whose own 500px width is a block
 * attribute in the pattern. A `width: 500px` rule stood here for one measurement and was removed:
 * with it and without it the figure measures 500x500 at 1440/1024/768 and 366x366 at 390, so it
 * was a second copy of a number the pattern already owns.
 */
.wp-block-image.wf-image-link {
	position: relative;
}

.wp-block-image.wf-image-link > figcaption.wp-element-caption {
	position: absolute;
	inset-inline: 0;
	inset-block-end: 0;
	margin: 0;
	padding: var(--wp--preset--spacing--40);
	background-color: rgba(33, 37, 41, 0.6);
	color: var(--wp--preset--color--white);
	font-size: var(--wp--preset--font-size--x-large);
	font-weight: 700;
	line-height: 1.5;
	text-align: start;
}