/** * core/cover — the subpage-hero pattern's image-and-tint interior hero. * * Loaded by xperience_starter_enqueue_core_block_styles() in functions.php through * wp_enqueue_block_style( 'core/cover', … ), the same mechanism as core-media-text.css and * core-group.css beside it. SCOPED to `.subpage-hero`, `.subpage-hero-title` and * `.subpage-hero-tagline` — the classNames patterns/subpage-hero.php writes, named after the * source's own `.subpage-hero`, `.subpage-hero-title` and `.subpage-hero-tagline` — so nothing * here reaches a core/cover, an

or a

the source never measured. * * WHY CSS AT ALL, AND WHY THIS IS THE UNIT'S FILE RATHER THAN THE THEME'S. The unit contract * measures THREE ladders across the four captured viewports and this theme's own * settings.viewport has two tiers, so none of the three is expressible as a block attribute or * as a theme.json viewport override. The contract's own `structure` says so twice, in the * cover node's `configuration.why` ("reproducing 320/220/120 at the other three viewports * needs a scoped stylesheet with real @media rules") and in the heading node's ("a scoped * stylesheet is the route, not a theme.json viewport override"). Every rule below is scoped to * this one unit's hook class, which is what makes it this file's and not wp-theme-scaffold's. * * THE THREE LADDERS, ALL FOUR VALUES OF EACH MEASURED BY THE CONTRACT AGAINST THE SOURCE: * * viewport root min-height h1 font-size tagline font-size * 1440x900 400px 60px 25px * 1024x768 320px 50px 20px * 768x1024 220px 40px 18px * 390x844 120px 26px 16px * * BEFORE THIS FILE THE BUILD HELD THE DESKTOP VALUE AT ALL FOUR — root 400px everywhere and * 60px/25px everywhere — so three of the four viewports were wrong on all three ladders, and * one visible consequence had already been measured independently: at 390x844 the h1 rendered * 334x144, i.e. "Subpage Hero" WRAPPED TO TWO LINES at 60px in a 366-wide row, where the * source sets one line at 26px. A line-break difference is what a type ladder held at its * desktop value looks like from the outside. * * THE BREAKPOINTS ARE BOOTSTRAP'S, WHICH IS THE SOURCE'S. 768 (md), 992 (lg) and 1400 (xxl), * the same three this theme's own stylesheets already use (core-media-text.css writes the md * pair 768 / 767.98 for exactly this reason, and core-navigation.css and core-columns.css * carry 992 and 1400). Each of the four captured viewports lands in a different band: 390 in * the base, 768 in [768, 992), 1024 in [992, 1400), 1440 at 1400 and up. * * THE TWO BANDS NOTHING MEASURED, STATED RATHER THAN IMPLIED: 576–767 and 1200–1399. The * source is a Bootstrap site with six breakpoints and the capture has four viewports, so where * the source steps inside those two bands is not knowable from anything this build may read. * They take the neighbouring band's value here. That is a choice, not a measurement. * * WHY min-height CARRIES !important AND THE FONT SIZES DO NOT. core/cover serialises * `minHeight` as an INLINE style on the block's root (`style="min-height:400px"`), and no * selector beats an inline declaration. The contract states `minHeight: 400` as an attribute, * so the attribute stays exactly as written and the three narrower bands override it — which * needs the flag. The font sizes had no such constraint: the contract's heading and paragraph * nodes carry `fontWeight` and `textColor` and NO `fontSize` at all (the inline 60px/25px was * an addition this pattern's own comment flagged as such), so they are removed from the * attributes and the whole ladder lives here, where an ordinary selector wins. The desktop * band is left to the inline 400px rather than restated, so there is exactly one place each * value is written. * * SPECIFICITY IS WHAT WINS HERE, NOT SOURCE ORDER, deliberately. `.wp-block-cover.subpage-hero` * is (0,2,0) against core's own `.wp-block-cover { min-height: 430px }` at (0,1,0), and * `.wp-block-cover.subpage-hero .subpage-hero-title` is (0,3,0) against the global stylesheet's * bare `h1 { font-size: min(2.5rem, calc(1.375rem + 1.5vw)) }` at (0,0,1) and its * `h1, h2, … { font-weight: 800 }`. Global styles print AFTER a theme's block styles, so a * rule that merely tied on specificity would be parsed, matched and silently discarded. * * THE OVERLAY OPACITY IS PINNED HERE BECAUSE CORE QUANTISES dimRatio TO TENTHS AT RENDER, * AND THAT IS THE ONE THING ABOUT THIS UNIT THAT WAS MEASURABLY WRONG. The contract's own * algebra collapses the source's three painted layers -- base #0d6efd, image at opacity 0.5, * overlay rgba(28,58,169,0.7) -- onto core/cover's single-overlay-over-full-opacity-image * model at EXACTLY 0.85 over #1943b8; the image's surviving coefficient is 1 - 0.85 = 0.15, * which is what makes the two forms identical for every pixel of the image rather than for * an average of it. But block-library.js's `dimRatioToClass` emits * `has-background-dim-` + 10 * Math.round(ratio / 10), so a stored 85 renders the class * `has-background-dim-90`, and wp-includes/blocks/cover/style.css declares opacity for the * tenths only. No multiple of ten reproduces a 0.15 image coefficient -- 0.8 gives 0.20 and * 0.9 gives 0.10 -- so this is not closable by choosing a different attribute value, and * changing `customOverlayColor` could only trade one pixel's error for another's. * * MEASURED, 2026-09-10, sampling the same eight pixels of the built hero and of the source's * own three-layer stack reproduced from its declared rules over the same image file, both at * 1296x400: with core's 0.9 the maximum per-channel difference was 7/255 (consistently -6,-6 * on R and G over the lit parts of the photograph); with the opacity pinned to 0.85 it is * 1/255, which is the rounding of the source's own 8-bit hex values. The previous build * found this quantisation and handed it back as wp-theme-scaffold's to fix; it is not -- * the rule is scoped to `.subpage-hero`, this unit's own hook class, which wp-unit-build * makes the build's own ("A rule hung off your unit's own hook class is part of building * the unit"). * * THE SELECTOR NAMES `has-background-dim-90` DELIBERATELY. Core's own winning rule is * `.wp-block-cover .wp-block-cover__background.has-background-dim.has-background-dim-90` at * (0,4,0); adding `.subpage-hero` to the root takes this one to (0,5,0), so it wins on * specificity rather than on print order. Naming the quantised class also makes the rule * fail VISIBLY rather than silently if someone changes `dimRatio`: it stops matching and the * overlay reverts to whatever core's tenth is, instead of pinning 0.85 under an attribute * that no longer means it. * * @package WordPress * @subpackage Xperience_Starter * @since Xperience Starter 1.0 */ .wp-block-cover.subpage-hero .subpage-hero-title { font-size: 26px; } .wp-block-cover.subpage-hero .subpage-hero-tagline { font-size: 16px; } @media (max-width: 767.98px) { .wp-block-cover.subpage-hero { min-height: 120px !important; } } @media (min-width: 768px) and (max-width: 991.98px) { .wp-block-cover.subpage-hero { min-height: 220px !important; } } @media (min-width: 768px) { .wp-block-cover.subpage-hero .subpage-hero-title { font-size: 40px; } .wp-block-cover.subpage-hero .subpage-hero-tagline { font-size: 18px; } } @media (min-width: 992px) and (max-width: 1399.98px) { .wp-block-cover.subpage-hero { min-height: 320px !important; } } @media (min-width: 992px) { .wp-block-cover.subpage-hero .subpage-hero-title { font-size: 50px; } .wp-block-cover.subpage-hero .subpage-hero-tagline { font-size: 20px; } } @media (min-width: 1400px) { .wp-block-cover.subpage-hero .subpage-hero-title { font-size: 60px; } .wp-block-cover.subpage-hero .subpage-hero-tagline { font-size: 25px; } } .wp-block-cover.subpage-hero .wp-block-cover__background.has-background-dim.has-background-dim-90 { opacity: 0.85; }