/**
 * core/columns — the video content row's own two-column shell.
 *
 * Loaded by xperience_starter_enqueue_core_block_styles() in functions.php through
 * wp_enqueue_block_style( 'core/columns', … ), so it reaches a page only when a columns
 * block renders there. Same one-file-per-block convention as core-column.css beside it,
 * and the map in functions.php is the only place the block name is written.
 *
 * WHY THIS FILE EXISTS AT ALL, stated because a rule that only cancels another rule looks
 * like a workaround until the reason is written down. patterns/video-content-row.php places
 * wakefly/video inside a core/column, and that block's own stylesheet hardcodes
 * `padding-block: 1.5rem` — the source's shared `py-4` VerticalPadding class, which the
 * standalone Video widget really does carry and which its own unit measured at 24px. The
 * VideoContentRow widget does NOT carry it: the source puts its 24px on div.content-row-inner
 * instead (the .cshtml's own comment says so), and the video sits flush inside a column that
 * is padded 16px by the RowHeight class. Measured on the source at 1440x900:
 * div.content-row-video is 640x392 — the plate's 360 plus 16 twice, with no 24 anywhere.
 *
 * So the 24px is a property of the PLACEMENT, not of the block, and this rule says which
 * placement drops it. THE ALTERNATIVE WAS TO EDIT blocks/video/style.css, and it is the
 * better long-term home — the padding belongs on a per-instance spacing support that block
 * does not currently declare (`supports.spacing.padding` is false). That is a change to
 * another unit's own artifact and is raised in this package's hand-back rather than made
 * here.
 *
 * @package WordPress
 * @subpackage Xperience_Starter
 * @since Xperience Starter 1.0
 */

.wp-block-columns.video-content-row .wp-block-wakefly-video {
	padding-block: 0;
}

/*
 * THE SOURCE'S BREAKPOINT, NOT CORE'S, AND THE DIFFERENCE IS MEASURED RATHER THAN ARGUED.
 * The source stacks this row at Bootstrap's `md` -- `.content-row-video { width: 50% }` sits
 * inside `media-breakpoint-up(md)`, i.e. 768px -- while core stacks a columns block at
 * `max-width: 781px` (wp-includes/blocks/columns/style.css). 781 >= 768, so the two DISAGREE
 * across the 768-781 band, and 768 is one of this build's four captured viewports.
 *
 * MEASURED BOTH SIDES, 2026-09-09. Source at 768x1024 and 781x1024: div.content-row-inner is
 * 696x271 with flex-direction row -- not stacked. This build before this rule, at 768x1024:
 * 696x544, stacked, because core's rule had already fired. At 390x844 both stack, so the
 * override is bounded at the bottom by min-width: 768px and hands 390 back to core untouched.
 *
 * The unit contract asserts the opposite -- "the two agree at all four captured viewports and
 * would differ between 768 and 781" -- and that is an arithmetic slip in the contract's own
 * prose, reported in this package's hand-back. The measurement above is what this rule is
 * written from.
 */
@media (min-width: 768px) and (max-width: 781px) {

	.wp-block-columns.video-content-row {
		flex-wrap: nowrap !important;
	}

	.wp-block-columns.video-content-row > .wp-block-column {
		flex-basis: 0 !important;
		flex-grow: 1;
	}
}

/*
 * THE FOOTER'S LINK BAND -- div.footer-nav's four-column row.
 *
 * TWO RULES, ONE FOR EACH OF TWO DIFFERENCES THE COMPARISON RECORDED AGAINST THIS BAND, and
 * they are scoped to `footer-nav`, the hook class patterns/footer.php puts on this band's own
 * group, so neither reaches any other core/columns on the site.
 *
 * 1. `justify-content: space-between` IS THE SOURCE'S OWN, AND NO ATTRIBUTE CAN CARRY IT.
 *    Measured on the source (unit structure, the link band's core/columns node): its
 *    div.footer-nav-columns computes `space-between` at all four captured viewports, and the
 *    built .wp-block-columns computed `normal` at all four -- four `corroborated` rows in this
 *    unit's comparison, one per viewport. core/columns declares
 *    `layout: { allowSwitching: false, allowInheriting: false, allowEditing: false }` in
 *    wp-includes/blocks/columns/block.json on this install, so the block exposes no
 *    justification attribute a definition could write and the value has nowhere to live but
 *    here. IT PAINTS NOTHING at the three wide viewports -- four columns and three 24px gaps
 *    fill the row exactly, so there is no free space to distribute -- and at 390 the free
 *    space is negative, where `space-between` degenerates to flex-start. Different arithmetic
 *    at each end, the same picture at both, and a computed property that differed regardless.
 *
 * 2. `min-width: auto` + `word-break: normal` UNDO TWO CORE DECLARATIONS THE SOURCE DOES NOT
 *    HAVE, and together they are the whole of a 144px height difference at 390x844.
 *    wp-includes/blocks/columns/style.css sets `min-width: 0` and `word-break: break-word` on
 *    every .wp-block-column. The first lets a column shrink past its content; the second is
 *    the legacy alias CSS Text 3 defines as `word-break: normal` plus `overflow-wrap:
 *    anywhere`, and `anywhere` -- unlike `break-word` -- counts as a soft wrap opportunity when
 *    a browser computes min-content, so it shrinks the automatic minimum to about one
 *    character. Both had to go; RESTORING `min-width: auto` ALONE CHANGED NOTHING, measured.
 *    The source's columns are Bootstrap `.col` with neither declaration, so they bottom out at
 *    their real min-content and the band overflows its own viewport at 390 -- an inherited
 *    source defect the unit's own responsive note already records, reproduced rather than
 *    corrected.
 *
 * MEASURED BOTH WAYS, 2026-09-09, `tooling/extract/probe.js` on /?page_id=55 -- the footer is
 * a template part and renders on the sandbox parent -- at 1440x900, 1024x768, 768x1024 and
 * 390x844. Row box, then the four column widths:
 *
 *              before                     after                      source (relayed)
 *   1440x900   1296x204  306 x4          1296x204  306 x4           1296x204  306 x4
 *   1024x768    936x252  216 x4           936x252  216 x4            936x252  216 x4
 *   768x1024    696x276  156 x4           696x276  156 x4            696x276  156 x4
 *   390x844     366x516  73.5 x4          366x372  107/108/96/55     366x372  107/108/96/55
 *
 * The three wide viewports do not move at all; 390 lands on the source's numbers exactly,
 * last column at x=395 in a 390px viewport on both sides. The 366x516-against-366x372 box was
 * a ratio of 1.39 and so sat just under `box-ratio`'s 1.40 threshold -- no summary named it,
 * and it was found only by driving that viewport by hand.
 */
.wp-block-group.footer-nav > .wp-block-columns {
	justify-content: space-between;
}

.wp-block-group.footer-nav > .wp-block-columns > .wp-block-column {
	min-width: auto;
	word-break: normal;
}

/*
 * THE FOOTER'S INFORMATION BAND -- div.footer-content's three-column row: THE GUTTER BLEED.
 *
 * MEASURED ON PAGE 5 (the home page, a real page a visitor opens -- the footer is a template
 * part and renders on every page), tooling/extract/probe.js on
 * `.footer-content > .wp-block-columns`, 2026-09-10. Source figures relayed from this
 * package's brief:
 *
 *              source          build BEFORE      build AFTER
 *   1440x900   1344 @48        1296 @72          1344 @48
 *   1024x768    984 @20         936 @44           984 @20
 *   768x1024    744 @12         696 @36           744 @12
 *   390x844     414 @-12        366 @12           414 @-12
 *
 * The row was 48px narrow and 24px inset ON EVERY VIEWPORT, and NO NUMBER IN THE COMPARISON
 * REPORTED IT -- the band above it (1440x372 @0) and the heights of everything inside were
 * already exact, so the only wrong figure was this one box's own width and x.
 *
 * THE CAUSE IS BOOTSTRAP'S GUTTER, WHICH HAS NO BLOCK-MODEL COUNTERPART. The source's row is
 * `.row.gx-5`: `margin-inline: -24px` on the row, and `padding-inline: 24px` on each `.col`.
 * The two cancel for the CONTENT -- which is why the column content has always been at the
 * right x here -- but the ROW's own box is 24px wider on each side than the container, and so
 * are the 1px rules the columns draw, because those sit at the padded column's outer edge.
 * `wp-block-columns` has no such mechanism and sat flush inside the container instead.
 *
 * IT IS BUILT AS THE SOURCE BUILDS IT, IN TWO HALVES, AND THE HALVES ARE IN TWO FILES.
 * The `padding-inline: 24px` half IS a block attribute -- core/column declares
 * `supports.spacing.padding: true` -- so it lives in patterns/footer.php as
 * `style.spacing.padding` on each of the three columns, written as `var:preset|spacing|50`
 * (1.5rem = 24px, an exact substitution, not a rounding). The row's `blockGap.left` went to
 * `0px` in the same edit: the 48px between column CONTENT is now two 24px gutters meeting,
 * which is the source's own arithmetic, and leaving the old 48px gap there as well would have
 * made it 96.
 *
 * THE `margin-inline` HALF CANNOT BE AN ATTRIBUTE AND THAT IS MEASURED, NOT ASSUMED:
 * core/columns declares `supports.spacing.margin: [ "top", "bottom" ]` in
 * wp-includes/blocks/columns/block.json on this install -- the inline axis is not offered, so
 * there is no attribute in which a negative left/right margin could be written. Hence this
 * rule, and hence the cross-reference: EDITING EITHER HALF WITHOUT THE OTHER BREAKS THE
 * ALIGNMENT SILENTLY. A previous pass tried the padding on its own and correctly refused it,
 * because padding alone moves the column CONTENT to x=96/528/960 and breaks the x=72
 * alignment this band shares with every other band on the page. It is the negative margin
 * that pulls it back, and neither half is right without the other.
 *
 * WHY THE MARGIN IS A TWO-TERM calc AND NOT A FLAT -24px. `.footer-content` is a `constrained`
 * group, so the layout support emits `margin-left: auto !important; margin-right: auto
 * !important` and `max-width: var(--wp--style--global--content-size)` on this row. At 1440
 * that centres a 1296px row inside a 1352px content box -- a real 28px margin -- while at
 * 1024, 768 and 390 the container is narrower than 1296, the max-width does not bind and the
 * margins compute to 0. A flat `-24px` would therefore land the row at x=20 at 1440 (44-24)
 * instead of 48, because it would throw the 28px of centring away. The first term reproduces
 * whatever the centring was worth at this width, the second is the source's gutter:
 *
 *     margin = (100% - min(100%, content-size)) / 2  -  24px
 *
 *   1440: (1352-1296)/2 - 24 = 28 - 24 =   4  ->  x = 44 + 4  = 48
 *   1024: (936 - 936)/2 - 24 =  0 - 24 = -24  ->  x = 44 - 24 = 20
 *    768: (696 - 696)/2 - 24 =  0 - 24 = -24  ->  x = 36 - 24 = 12
 *    390: (366 - 366)/2 - 24 =  0 - 24 = -24  ->  x = 12 - 24 = -12
 *
 * All four land on the source exactly. `min(100%, content-size)` is the row's own width under
 * the constrained layout, so `width` is that plus one gutter each side and `max-width` has to
 * be released for it to take effect. THE `auto` MARGINS CANNOT DO THIS THEMSELVES: CSS 2.2
 * 10.3.3 says that when the used width plus the non-auto margins EXCEEDS the containing block,
 * any `auto` margin is treated as ZERO -- so at 1024/768/390, where the row is now wider than
 * its container, `margin-inline: auto` would give 0 and leave the row at x=44 overflowing
 * right. That is why the margin is computed rather than delegated, and it was checked against
 * the spec rather than tried and eyeballed.
 *
 * `!important` MATCHES THE LAYOUT SUPPORT'S OWN. The generated rule is `!important` on both
 * margins at specificity (0,1,0); this selector is (0,3,0), so `!important` here wins on
 * specificity. `max-width` is NOT `!important` upstream and needs none here.
 *
 * THE 1px RULES MOVE WITH THE ROW, WHICH IS THE POINT. Each column's own `border-right` now
 * sits at the outer edge of its padded box -- x=495 / 943 / 1391 at 1440 -- exactly where the
 * source draws it, instead of 24px inboard of it.
 */
.wp-block-group.footer-content > .wp-block-columns {

	/* The source's gx-5 gutter, one place, shared with the calc below. */
	--wf-gutter: var(--wp--preset--spacing--50);
	--wf-row: min(100%, var(--wp--style--global--content-size));

	width: calc(var(--wf-row) + var(--wf-gutter) * 2);
	max-width: none;
	margin-inline: calc((100% - var(--wf-row)) / 2 - var(--wf-gutter)) !important;
}

/*
 * THE FOOTER'S INFORMATION BAND -- div.footer-content's three-column row, at 390 only.
 *
 * MEASURED: the source wraps this row TWO-PLUS-ONE at 390x844 (207 at x=-12, 207 at x=195,
 * then 414 on a second line) while the build holds all three abreast and squeezes them to
 * 90px each at x=12/150/288 -- a column that is 40px of icon, 16px of gap and 34px of text.
 * At 768x1024 and wider the source is three abreast (248 each at 768, 328 at 1024, 448 at
 * 1440) and so is the build, so this rule is bounded to the narrow end and hands every other
 * width back untouched.
 *
 * WHY IT IS A MEDIA QUERY AND NOT THE SOURCE'S OWN MECHANISM, stated because the band above
 * got the mechanism and this one could not. The source's wrap is not content-driven in any
 * way this build can copy: div.col carries Bootstrap gx-5's 24px gutter padding on each side,
 * which inflates each column's min-content by 48px and is what pushes the third onto a second
 * line. THE GUTTER HAS NO BLOCK-MODEL COUNTERPART -- the unit's own structure records that,
 * and records that reproducing it as column padding was refused because it moves the column
 * CONTENT to x=96/528/960 and breaks the x=72 alignment this band shares with every other
 * band on the page. Driven here to be sure rather than argued: with `flex: 1 0 0`,
 * `min-width: auto` and `word-break: normal` on these columns -- the exact rule that fixed the
 * link band above -- all three still fit on one line at 390 (81/106/83, filling 366 with its
 * two 48px gaps) and the band got TALLER, 619 against a baseline 571. So the mechanism does
 * not carry over and a width is the only lever left.
 *
 * WHERE THE 767.98px COMES FROM, AND WHAT IS NOT MEASURED ABOUT IT. It is the widest point
 * strictly below 768x1024, the narrowest captured viewport at which the source is three
 * abreast, so both measured endpoints are reproduced: three abreast at 768, two-plus-one at
 * 390. It is also Bootstrap's own `md` boundary and this theme's existing spelling for a
 * Bootstrap breakpoint (blocks/stats-kpi/style.css and blocks/hero-carousel/style.css both
 * step at 991.98px, `lg`). NOTHING BETWEEN 390 AND 768 IS MEASURED ON EITHER SIDE, and the
 * source's own switch is content-driven rather than a breakpoint at all, so this reproduces
 * the four sampled points and invents the rest -- the same honest limit blocks/stats-kpi's
 * four font sizes carry, and flagged in this package's hand-back the same way.
 *
 * `calc(50% - 24px - 1px)` IS TWO TERMS, NEITHER OF THEM A MAGIC NUMBER, and the second one
 * is why the first draft of this rule stacked all three one-per-line instead. 24px is half
 * the band's own 48px blockGap. 1px is the column's own right rule, and it has to be
 * subtracted because .wp-block-column computes `box-sizing: content-box` -- measured, not
 * assumed -- so the border sits OUTSIDE the flex basis and a plain `calc(50% - 24px)` gives
 * each column a 160px outer box, two of which plus the 48px gap need 368 in a 366 row. With
 * the border term the arithmetic is exact and stays exact at any width, because every term is
 * proportional or a constant the row also carries: 158 + 1 + 48 + 158 + 1 = 366 at 390x844.
 * That is what puts the third column alone on a second line, where `flex-grow` takes it out
 * to the full 366.
 *
 * BOTH DECLARATIONS ARE `!important` because both are cancelling one of core's own:
 * `flex-wrap: nowrap !important`
 * on `.wp-block-columns.is-not-stacked-on-mobile`, and `flex-grow: 0` on
 * `.wp-block-columns.is-not-stacked-on-mobile > .wp-block-column[style*=flex-basis]`, which is
 * specificity (0,4,0) -- the same as this file's own selector, so without `!important` it
 * would come down to source order between two stylesheets rather than to anything stated.
 * THE `is-not-stacked-on-mobile` CLASS ITSELF STAYS AND SO DOES THE ATTRIBUTE BEHIND IT: what
 * it really prevents is core's `flex-basis: 100% !important` under `@media (max-width: 781px)`,
 * i.e. the full stack, which the source never does at any width. Only the `flex-wrap` half is
 * relaxed here.
 *
 * MEASURED BOTH WAYS, 2026-09-09, same instrument and same four viewports. Row box, then the
 * three column boxes:
 *
 *              before                          after
 *   1440x900   1296x272  400x271 x3           1296x272  400x271 x3
 *   1024x768    936x352  280x351 x3            936x352  280x351 x3
 *   768x1024    696x376  200x375 x3            696x376  200x375 x3
 *   390x844     366x571   90x570 x3            366x599  159x399 / 159x399 / 366x175
 *
 * THE THREE WIDE VIEWPORTS DO NOT MOVE AT ALL. At 390 the band is 28px TALLER than before
 * (599 against 571) and that is the right direction rather than a regression: the three
 * columns were 90px wide, which is 40px of icon plus 16px of gap and 34px of text, and the
 * source is not three abreast there at all. The whole built footer goes 1519 -> 1403 at 390
 * -- both figures MEASURED on footer.wp-block-template-part, not arithmetic on the two bands
 * -- once this band's +28 and the link band's -144 are both in, against a source footer of 1447
 * -- 72px over before, 44px under after. That 1447 is RELAYED from a YAML comment on the
 * unit's own responsive note, which says the four viewports were diffed with this same
 * instrument but does not cite a run; it is used here as a direction check and nothing rests
 * on it.
 *
 * SEPARATELY AND NOT CLOSED HERE: the built column is 271 tall at 1440x900 against the
 * source's 296 (relayed from the unit's own structure, which decomposes that 296). That is a
 * 25px difference outside the four findings this package was given, it is not touched by any
 * rule in this file, and it is reported in the hand-back rather than chased.
 */
@media (max-width: 767.98px) {

	.wp-block-group.footer-content > .wp-block-columns.is-not-stacked-on-mobile {
		flex-wrap: wrap !important;
	}

	/*
	 * THE SECOND HAIRLINE — the other half of the 23px, and the half that could NOT be an
	 * attribute. The first half is `blockGap.top: 0px` in patterns/footer.php; read its
	 * docblock there first, because this rule only makes sense as the +1 beside that -24.
	 *
	 * WHAT THE SOURCE DOES: it declares `border-width: 0 1px 1px 0` on EACH div.col, so a
	 * row that wraps collects the bottom rule once per LINE. At 390x844 the source's row
	 * wraps two-plus-one and the two lines measure 515 (514 + its own 1px) and 176
	 * (175 + its own 1px), summing to the 691 this band's contract derives. This build
	 * draws the rule once, on core/columns, for the reason patterns/footer.php's own
	 * docblock gives -- our columns are separated by a 48px gap where the source's butt,
	 * so a per-column rule breaks the continuous line into segments with holes in it. That
	 * decision is right at every width and is NOT reopened here; what it costs is the
	 * line-1 rule, which had nothing to draw it.
	 *
	 * WHY IT IS DRAWN AS A `border-top` ON THE LAST COLUMN RATHER THAN A `border-bottom` ON
	 * EACH, which is the shape the source has. Measured both, 2026-09-10, same instrument
	 * and same page:
	 *
	 *                                        band     row    line-1 rule
	 *   baseline                             390x814  366x714  absent
	 *   border-bottom on each column         390x816  366x716  two 159px segments, 48px hole
	 *   border-top on the last column        390x791  366x691  one continuous 366px line
	 *
	 * Both reach 691 once the row gap is gone -- they are geometrically identical, and the
	 * per-column form needs a third declaration to cancel the columns block's own bottom
	 * rule or it double-draws at the bottom. The difference is entirely where the paint
	 * lands, and the hole is the same artifact this unit already refused at 1440. So the
	 * continuous form is the source's PICTURE reproduced with the block model's own
	 * mechanism, which is what the rest of this unit does with the gutter too.
	 *
	 * `:last-child` IS SOUND ONLY INSIDE THIS MEDIA QUERY, and that is why it lives here
	 * rather than beside the block's other border rules. It names the third column, which
	 * is alone on line 2 at this width and therefore spans the full 366 -- so its top edge
	 * IS the line-1/line-2 boundary, full width. At 768 and above all three columns share
	 * one flex line and the same selector would paint a rule across the top of the band
	 * that the source does not have anywhere. Measured after: borderTopWidth is 1px at
	 * 390x844 and 0px at 768x1024, 1024x768 and 1440x900.
	 *
	 * The colour is the same `light-gray` preset the block's other two rules use, and it
	 * computes to rgb(222, 226, 230) -- the source's own border colour, measured on the
	 * rendered page rather than read off the token.
	 */
	.wp-block-group.footer-content > .wp-block-columns > .wp-block-column:last-child {
		border-top: 1px solid var(--wp--preset--color--light-gray);
	}

	/*
	 * THE `- 48px` WAS `- 24px` UNTIL 2026-09-10, AND THE CHANGE IS THE GUTTER BLEED ABOVE,
	 * NOT A NEW MEASUREMENT. Every term still means what the paragraph above says it means;
	 * two of them moved because the row did.
	 *
	 * `50%` is now half of a 414px row rather than half of a 366px one -- 207, which is the
	 * source's own measured column box at this viewport (207 at x=-12, 207 at x=195). The
	 * subtrahend is the column's own 24px gutter on EACH side, which the old 24px could not
	 * be: it was half of the 48px blockGap that used to sit BETWEEN the columns, and that gap
	 * is now 0. The 1px is unchanged and is still the column's own right rule, still outside
	 * the flex basis because `.wp-block-column` computes `box-sizing: content-box`.
	 *
	 * 158 + 48 + 1 = 207, and two of those fill the 414 row exactly with no gap left over.
	 */
	.wp-block-group.footer-content > .wp-block-columns > .wp-block-column {
		flex-basis: calc(50% - 48px - 1px) !important;
		flex-grow: 1 !important;
	}
}

/*
 * THE IMAGE-LINK DEMO ROW — core STACKS AT 781 WHERE THE SOURCE STACKS AT 992, AND THE
 * 210px BAND BETWEEN THEM IS THE WORST DIFFERENCE THIS UNIT HAS.
 *
 * The source lays its image-link instances out in Bootstrap `col-lg-4`, which is three
 * abreast from `lg` (992px) up and FULL CONTAINER WIDTH below it. core stacks a columns
 * block at `max-width: 781px` (wp-includes/blocks/columns/style.css, the
 * `:not(.is-not-stacked-on-mobile)` block) and holds it three abreast at 782 and above. So
 * the two agree below 782 and again at 992, and DISAGREE ACROSS 782-991 — a 210px band in
 * which the build renders the widget three-up at a third of the width the source gives it,
 * and at a completely different x. NONE OF THE FOUR CAPTURED VIEWPORTS CAN SEE IT: 768 is
 * below the band and 1024 is above it, which is why it survived every comparison this unit
 * has had.
 *
 * MEASURED ON PAGE 124 — the unit's own instance page and the only page that carries this
 * widget — with tooling/extract/probe.js on
 * `.entry-content > .wp-block-columns > .wp-block-column > .wp-block-group`, 2026-09-10.
 * Source figures relayed from this package's brief, not read here:
 *
 *            source            build BEFORE        build AFTER
 *   780      672x548 @54       696x548 @42         696x548 @42     (unchanged — core already stacked)
 *   800      672x548           216x264 @532        696x548 @52
 *   850      672x548           216x264 @557        696x548 @77
 *   900      672x548           216x264 @582        696x548 @102
 *   950      —                 216x264 @607        696x548 @127
 *   992      272x320 @680      285x333 @663        285x333 @663    (unchanged — above the band)
 *   1024     —                 296x344 @684        296x344 @684    (unchanged)
 *   1440     —                 416x464 @952        416x464 @952    (unchanged)
 *
 * THE HEIGHT WAS WRONG TOO, and it is the half no width sweep was looking for: the widget
 * measured 264 tall across the band against the source's 548, because a 500px-square image
 * clamped into a 216px column is 216 square plus its caption. Both axes land on the source's
 * own 548 now. The width is 696 against 672 — the same relationship the build already had at
 * 780 and which that viewport records as AGREEING, because the 24px is this theme's root
 * padding against Bootstrap's container gutter: a standing difference between the two layout
 * systems, present at every width where both are full-bleed, and not this rule's to close.
 * The x error across the band was about 470px and is now 2px at 800 (52 against the source's
 * own 54 at 780, the only x this package was given inside the band).
 *
 * `image-link-row` IS A HOOK CLASS ON THE INSTANCE PAGE'S OWN COLUMNS BLOCK, NOT ON THE
 * PATTERN. patterns/image-link.php is the core/group and the core/image inside it and
 * nothing else — the three-column shell is how the demo page reproduces the source's own
 * demo layout, so it lives in page 124's post_content and the class went there with it.
 * Scoping to it is what keeps this rule off every other columns block on the site, which
 * would be a decision about the theme rather than about this unit.
 *
 * BOTH DECLARATIONS ARE `!important` BECAUSE BOTH OF CORE'S ARE. core sets
 * `flex-wrap: nowrap !important` on `.wp-block-columns` from 782 up and `flex-basis: 0` on
 * the columns in the same block; re-stacking needs the wrap back and the basis returned to
 * the 100% core itself uses below 782, so this reproduces core's own narrow-viewport
 * declarations over a wider band rather than inventing a third layout.
 *
 * THE TWO EMPTY COLUMNS COST NOTHING, checked rather than assumed: they measure 696x0 when
 * stacked, exactly as they already did at 780 before this rule existed.
 */
@media (min-width: 782px) and (max-width: 991.98px) {

	.wp-block-columns.image-link-row {
		flex-wrap: wrap !important;
	}

	.wp-block-columns.image-link-row > .wp-block-column {
		flex-basis: 100% !important;
	}
}