/** * Homepage block pattern styles — Aquinas Classical Academy. * * Every rule that sets color, background, or brand typography is prefixed * with `html body` to out-specificity Kadence's own default block/element * CSS (kadence/assets/css/*.min.css), which otherwise sits at an equal or * higher specificity and wins on load order — the same fix already applied * to the global button override in functions.php. Values (colors, font * families/sizes, spacing) come from theme.json tokens only; nothing here * introduces a new color or font. * * Heading font-family is the same bug in a new spot: theme.json's * generated CSS sets `h1,h2,h3,h4,h5,h6{font-family:cardo}` and * `h2{font-family:lora}`, both plain-tag selectors. Kadence's own base * CSS sets the identical `h1,h2,h3,h4,h5,h6{font-family:var(--global- * heading-font-family)}` (which resolves to the literal keyword * "inherit"), also a plain-tag selector — same specificity, and * Kadence's stylesheet loads later, so it wins for any h1-h6 that * doesn't declare its own font-family. Every actual heading tag * (h1/h2/h3) used in these patterns now sets its own font-family below * for exactly this reason — a bare class selector already outranks a * plain tag selector on specificity regardless of the `html body` * prefix, but the prefix is kept for consistency with every other rule * in this file. `.aca-diff-row__heading` (h3) already declared its own * font-family before this fix and was never actually affected. * * Same story for font-size on three of the h2-tagged section headings * (.aca-welcome__heading, .aca-differentiators__heading, * .aca-find-way__heading). theme.json's h2 rule and Kadence's own * hardcoded h2 rule both cap these at ~28px (the generic "heading" * token), but all three are specified in Figma as Cardo Bold 64/120 — * H1 scale, not the smaller size an h2 tag would suggest (verified * directly against Figma nodes 1:54, 17:52, and 1:100 respectively). * Each now sets its own font-size (var(--wp--preset--font-size--display) * — the same fluid/responsive token already used for the H1, so these * scale the same way across breakpoints instead of becoming a fixed * pixel size) and line-height (1.2, matching Figma's documented 64/120 * and theme.json's own heading line-height) for the same reason: a * plain tag selector can't win a specificity fight against Kadence's * plain tag selector once Kadence loads later, no matter what the * "correct" value is. * * The Hero h1 (.aca-hero__heading) was WRONGLY assumed at the time of * that fix to already be correct via theme.json's h1-specific rule, on * the theory that Kadence only hardcoded a shared h1-h6 rule. It * doesn't just do that — Kadence's base CSS also hardcodes a dedicated * `h1 { font-size: 32px; line-height: 1.5; }`, tied specificity with * theme.json's own h1 rule, loading later and winning, exactly like * every other case here. Confirmed via computed styles (not just * reading the CSS source) that the Hero heading was actually rendering * at 32px/48px instead of 64px/76.8px before this was caught. Same * fix as the others: font-size (var(--wp--preset--font-size--display)) * and line-height (1.2) declared explicitly below, matching Figma node * 1:42's confirmed 64/120 spec. * * A fourth variant of the same underlying problem surfaced in the * Welcome row: `html body .aca-welcome__row` is (0,0,1,2) — one class, * two type selectors. Kadence's own `.single-content .wp-block-columns * { margin-bottom: var(--global-md-spacing); }` is (0,0,2,0) — two * classes, no type selectors. CSS specificity compares class-count (c) * before type-count (d), so Kadence's rule wins outright on c (2 vs 1) * regardless of d — confirmed live in DevTools' Computed panel, not * assumed. `html body` ancestors only defend against a *type-selector* * arms race (h1, p, etc.); they do nothing against a selector that * simply uses more classes. Every `.aca-welcome__row*`/`.aca-welcome__ * image` selector below now also includes the element's own generic WP * block class (`.wp-block-columns`, `.wp-block-column`, `.wp-block- * image`) for exactly this reason — it costs nothing (the element * already carries that class) and raises c to 2, tying any * `.single-content .wp-block-*`-shaped Kadence default and winning on d * (html + body) instead. */ /* --------------------------------------------------------------------- * Shared: photography placeholders * ------------------------------------------------------------------- */ html body .aca-photo-placeholder { position: relative; margin: 0; overflow: hidden; } html body .aca-photo-placeholder img { display: block; width: 100%; height: 100%; object-fit: cover; } /* --------------------------------------------------------------------- * Hero * ------------------------------------------------------------------- */ /* * aspect-ratio matches Figma's actual Hero frame (node 1:40, file * eBOw6GfQzuFBs1gn9W0vDh): 1988.0001220703125 x 1017px — the trailing * .0001 is float-export noise, so this uses the clean 1988/1017 fraction * (differs from the exact figure in the 8th significant digit, i.e. not * at all). Applied unconditionally, with no breakpoint/media-query gate * and no separate min-height rule. * * That's deliberate, not an oversight: a block-level box with `aspect- * ratio` set and `height: auto` only uses the ratio as a *preferred* * size — if the content (padding + eyebrow + heading + subtext + button) * needs more height than the ratio implies, the browser still grows the * box to fit it, same as if aspect-ratio weren't there at all. Verified * this holds here, not assumed: rendered the real markup/CSS/webfonts * (Playwright, real Cardo font, and the H1's actual fluid font-size — * computed from WordPress core's own wp_get_typography_font_size_value() * algorithm against this theme's real settings, not guessed) at 20 * widths from 320 to 1920px, before and after adding this rule. Below * ~900px the rendered height is byte-for-byte identical with or without * aspect-ratio (content need already exceeds the ratio's implied height, * so the ratio is a no-op there) — including the specific 320/375/480px * widths called out as previously tight: clearance between the Schedule * a Visit button and the wave curve measured at 21px/24px/29px in both * states, not 0px and not reduced by this change. Above ~900px the ratio * takes over smoothly (matches the ratio-implied height exactly from * 900px up to 1920px, where it lands at 982px, vs. this section's * previous auto height of 616px there) with no dip or discontinuity at * the crossover. No separate mobile handling needed as a result. */ html body .aca-hero { position: relative; aspect-ratio: 1988 / 1017; padding: clamp(4rem, 12vw, 8rem) clamp(1.5rem, 6vw, 5rem); } /* * Background layer only — this is what the wave clip-path is scoped to, * never the .aca-hero section itself, so the curve can't ever clip * .aca-hero__content (heading/subtext/button sit in their own stacking * context at z-index: 3, well above this layer's z-index: 1). * * Placeholder color and dark photo tint are combined into one * `background` value so both are carried by, and clipped with, this * single element. When real photography replaces the placeholder, swap * only the `background-color` line below for a `background-image: url(...)` * (keeping the same rgba() tint layer on top of it) — the clip-path * needs no changes at all. * * Shape: measured directly from the actual Figma hero background pixels * (file eBOw6GfQzuFBs1gn9W0vDh, node 9:27), not estimated from a * screenshot. That node is a single flattened raster image, not a * vector — the photo→white transition row was scanned at every pixel * column, lightly smoothed, and fit with cubic bezier segments (see * template-parts/site-header.php for the #aca-hero-wave path and the * full measurement methodology). The real curve: deepest at the left * edge itself (not an interior trough), a subtle bump-then-dip ripple * through the middle third, then a continuous rise to its shallowest * point at the right edge. Two earlier passes here — a hand-guessed * clip-path: polygon(), then a hand-tuned bezier — both assumed the low * point sat away from the left edge; that assumption was wrong, which * is exactly why this one was measured instead of eyeballed. * * clip-path references an SVG (#aca-hero-wave, defined once * in template-parts/site-header.php) built from real cubic bezier * curves rather than clip-path: polygon() — a polygon of straight-line * segments was tried first and, regardless of point count, read as * near-straight-diagonal on the long rise rather than a continuous arc. * The SVG path's clipPathUnits="objectBoundingBox" keeps every * coordinate a 0–1 fraction of this element's own box, so the curve * still scales proportionally at any viewport width or hero height — * nothing here is a fixed pixel value; verified at 1920/1024/480px. */ html body .aca-hero::before { content: ""; position: absolute; inset: 0; z-index: 1; background-image: linear-gradient(rgba(20, 20, 20, 0.4), rgba(20, 20, 20, 0.4)), url(/wp-content/uploads/2026/10/home-hero.jpg); background-color: var(--wp--preset--color--muted-text); background-size: cover; clip-path: url(#aca-hero-wave); } html body .aca-hero[data-placeholder-label]::after { content: attr(data-placeholder-label); position: absolute; top: 16px; left: 16px; z-index: 2; background-color: var(--wp--preset--color--black); color: var(--wp--preset--color--off-white); font-family: var(--wp--preset--font-family--roboto); font-size: 0.6875rem; font-weight: 500; letter-spacing: 0.04em; text-transform: uppercase; padding: 0.25rem 0.5rem; border-radius: 3px; } html body .aca-hero__content { position: relative; z-index: 3; max-width: 46rem; } html body .aca-hero__heading { color: var(--wp--preset--color--white); font-family: var(--wp--preset--font-family--cardo); font-size: var(--wp--preset--font-size--display); line-height: 1.2; margin-top: 0.75rem; } html body .aca-hero__subtext { color: var(--wp--preset--color--warm-cream); } /* * Mobile only -- desktop's left-aligned eyebrow/heading/subtext/button * (against the section's own padding, no auto-centering) is correct and * untouched here. Below the 782px breakpoint (this codebase's standard * "mobile" cutoff -- see .aca-stats__grid/.aca-footer__grid below) the * design calls for all four centered instead. Scoped to * .aca-hero__content and its own descendants only, not the shared/base * .wp-block-buttons class, so no other section's button row is affected. * * The aspect-ratio removal on .aca-hero itself is a separate, unrelated * fix living in the same breakpoint: WebKit (Safari, and Chrome-on-iOS, * which is WebKit under the hood) has shipped multiple 2026 fixes for * aspect-ratio boxes not correctly growing past their ratio-derived * height to fit content that needs more room -- this section's own * eyebrow/heading/subtext/button stack is tall enough at mobile widths * to hit exactly that case, confirmed live on a real iPhone: the box * locks to its pure aspect-ratio height with no growth, and the * subtext/button render below the box's actual bottom edge, overlapping * the next section. `min-height: min-content` (an earlier attempt at a * single-property fix) was proven NOT to be a safe substitute here -- * on Blink it takes an entirely different sizing code path than the * plain `aspect-ratio` + implicit `min-height: auto` that already works * correctly there, and collapses the box back down to the same broken * pure-ratio height, reproducing this exact bug on Chrome too. Dropping * aspect-ratio outright below this breakpoint sidesteps the whole * cross-engine ambiguity: with no ratio to reconcile against, ordinary * block-flow content sizing (which every engine gets right) is all * that's left. .aca-hero::before (the background/curve layer) needs no * matching change -- it's `position: absolute; inset: 0` against * .aca-hero, so it already fills whatever height results, and its * `background-size: cover` already adapts to any box height; the * #aca-hero-wave clip-path is objectBoundingBox-scoped so it re-scales * with the box rather than breaking. Above 782px the ratio is restored * unchanged -- desktop was never part of this bug. */ @media (max-width: 782px) { html body .aca-hero { aspect-ratio: auto; } html body .aca-hero__content { text-align: center; } html body .aca-hero__content .wp-block-buttons { justify-content: center; } } /* --------------------------------------------------------------------- * Welcome / Cause * ------------------------------------------------------------------- */ /* * The Welcome row's original bottom margin (13.925rem / 222.8px, measured * Welcome image bottom to stats bar top -- see the comment on * .aca-welcome__row below). Pulled into a custom property so the Video * feature section, when it sits between Welcome and the stats bar, can * reuse the literal same value as its bottom padding instead of a second * copy of the number. */ html body { --aca-welcome-stats-gap: 13.925rem; } html body .aca-welcome__heading { font-family: var(--wp--preset--font-family--cardo); font-size: var(--wp--preset--font-size--display); line-height: 1.2; margin-bottom: 1.25rem; } html body .aca-welcome__heading .aca-welcome__heading-accent { color: var(--wp--preset--color--mustard-gold); display: block; } html body .aca-welcome__text { color: var(--wp--preset--color--muted-text); max-width: 42rem; } /* * margin-top/margin-bottom and the image's own size below were * originally measured against node 10:30 ("ArchwayStudent 1")'s reported * bounding box (x 859, y 1156, 655x818) — which turned out to be stale: * compositing that node's own exported bitmap against the "Section * Cause" text node (1:53) at their reported coordinates puts the text * block directly on top of the photo, which isn't what the file actually * renders. The real geometry (image, and by extension these two margins) * was instead measured directly off four independently-rendered * composites of the whole page — pixel-scanning for the photo/white- * background edge, the same technique already used for the Hero wave * curve — consistent across all four to within ~1px: the image actually * renders at 456x745, top edge at y≈1180, bottom edge at y≈1925. text * node 1:53's own reported position (x 905) was independently * corroborated by that same pixel scan (measured text start ≈903), so * unlike the image node, its numbers are trusted as-is. * - margin-top 57.3px = Hero frame's bottom edge (node 1:40, y 106 + * height 1017 = 1123) to the Welcome image's measured top (≈1180). * - margin-bottom 222.8px = the Welcome image's measured bottom (≈1925) * to the stats bar background's top edge (node 1:82 "Section Urgent * Cause", y 2148). * Neither value lines up with this theme's generated spacing-preset * scale (settings.spacing.spacingScale in theme.json: steps 20-80 work * out to 7/10.7/16/24/36/54/81px via WordPress core's own * compute_spacing_sizes() algorithm — checked against the real formula, * not assumed), and no rule anywhere else in this codebase references * `--wp--preset--spacing--*` either, so introducing that token here * would be a new pattern, not an existing one. Plain rem values instead, * matching how .aca-welcome__image's own aspect-ratio below is already a * flat measured value rather than a fluid one. * * gap 146.5px is the same pixel-measured methodology: the space between * the image's measured right edge (≈758) and the text column's left * edge (905), at the same 1920px reference width as every other value * here. * * padding-inline is new: this row had no horizontal inset at all, so it * sat flush against the true browser edge while every other section * (Hero, stats, etc.) has one — the same missing-is-layout-constrained * problem already identified for this row's width behavior, just on the * left/right axis instead of growth. Rather than invent a separate * value, this reuses .aca-hero's own padding formula verbatim * (clamp(1.5rem, 6vw, 5rem)) so the two sections' content edges are * driven by the literal same rule, not two numbers that happen to * match today. Confirmed via rendered left-edge measurement at seven * widths (375-1920px) that .aca-hero__content and this row now align * exactly at every one, not just visually close. */ html body .aca-welcome__row.wp-block-columns { /* * !important: WordPress core itself ships * `.wp-block-columns { align-items: normal !important; }`, which beats * ANY non-important rule outright regardless of specificity -- the * specificity bump from appending .wp-block-columns above was never * enough on its own for this specific property, only for the * Kadence-vs-class-count issue it was originally added for. align-items: * normal resolves to stretch on a flex row, so without this the row * stretches to its tallest child and the (non-stretching) text column * just sits at the top of that taller box -- confirmed as the real * mechanism via the identical, actually-reported bug on * .aca-diff-row.wp-block-columns below, not assumed here. */ align-items: center !important; gap: clamp(2rem, 7.63vw, 9.15625rem); margin-top: 3.58125rem; margin-bottom: var(--aca-welcome-stats-gap); padding-inline: clamp(1.5rem, 6vw, 5rem); } /* * flex-basis was previously a percentage (33.65%/66.35%, matching the * measured 456:900 ratio). That grows with the viewport, which is wrong * here: this row's wrapping `wp:group {"layout":{"type":"constrained"}}` * never actually gets a max-width on the front end (WP's real * constrained-layout CSS is keyed to an `is-layout-constrained` class * that only the block *editor* adds at save time — this pattern's HTML * is hand-authored, so that class, and the width rule tied to it, are * both simply absent; confirmed by grepping this file's own output for * that class, not assumed). With no ceiling above it, a percentage-based * image column grows without bound as the viewport widens — which is * exactly the "image dominates the page" symptom, at a wider absolute * size than the 456px it was fixed at, not just the wrong ratio. * * flex-grow: 0 with a fixed flex-basis keeps the image at its real * measured 456px at any container width at or above roughly 602px * (456px image + the row's own gap), full stop — it never grows past * that regardless of viewport. flex-shrink: 1 still lets it shrink * below 456px on narrower containers, same as before. The text column's * flex-grow: 1 absorbs whatever space the image column doesn't use, and * .aca-welcome__text's own max-width: 42rem below already stops the * paragraph itself from stretching past a readable line length, so that * absorbed space becomes whitespace, not a wider paragraph. */ html body .aca-welcome__row-image.wp-block-column { flex: 0 1 456px; } html body .aca-welcome__row-text.wp-block-column { flex: 1 1 0%; } /* * border-radius is a flat 228px (456 / 2), not a percentage or a calc() * tied to the element's current width — deliberately, and only correct * because of the flex-basis fix above. Per the CSS border-radius spec, * when a box's two same-edge corner radii would sum to more than that * edge's current length, both are scaled down proportionally until they * exactly fit — so at any width at or below 456px, the browser itself * reduces 228px+228px down to exactly half of whatever the current * width actually is, with no extra CSS needed. That auto-scaling is what * broke before: the image's old percentage width could exceed 456px, and * above that width 228px is LESS than half the current width, so the * corners stopped meeting at the top-center and the arch flattened. * Confirmed directly (not assumed) via Playwright's computed * border-top-left-radius at several rendered widths, both below and at * this element's 456px ceiling — getComputedStyle() reports the * authored 228px/228px at every width since that resolution happens at * paint time, not in computed style, so this was checked visually * (rendered screenshots), not by reading computed values. * * max-width: 456px here too, as a backstop independent of the flex fix * on .aca-welcome__row-image above: below the mobile breakpoint where * core's wp:columns block stacks columns (flex-basis: 100%), this figure * would otherwise still be free to render wider than 456px on any * viewport wider than that — mobile *stacked* still means "one * full-width column," and viewports well past 456px exist above that * breakpoint too (e.g. a tablet just under it). */ html body .aca-welcome__image.wp-block-image { border-radius: 228px 228px 0 0; aspect-ratio: 456 / 745; max-width: 456px; } /* --------------------------------------------------------------------- * Video feature (editor-inserted group between Welcome and Stats) * ------------------------------------------------------------------- */ /* * When the Video feature group directly follows the Welcome group, the * Welcome row's 222.8px bottom margin no longer separates Welcome from the * stats bar -- it separates Welcome from the video. Shrink it to a normal * section gap here only; the selector needs the adjacent .aca-video-feature * to match, so Welcome is unchanged on any page without it. * --wp--preset--spacing--80 is the largest step of theme.json's spacing * scale (5.0625rem / 81px). Specificity (0,3,2) -- :has() counts as its * argument's one class -- beats the base * .aca-welcome__row.wp-block-columns rule (0,2,2) and Kadence's * .single-content .wp-block-columns (0,2,0). */ html body .wp-block-group:has(+ .aca-video-feature) > .aca-welcome__row { margin-bottom: var(--wp--preset--spacing--80); } /* * The 222.8px that used to sit between Welcome and the stats bar moves to * the bottom of this section, so video-to-stats matches the original * Welcome-to-stats rhythm. Same custom property as .aca-welcome__row. */ html body .aca-video-feature.wp-block-group { padding-bottom: var(--aca-welcome-stats-gap); } /* * Below the 782px columns breakpoint (same 781px max-width query used * elsewhere in this file) the flat 222.8px is far too tall for a phone. * Scale it with the viewport instead: 64px floor, 15vw in between (~117px * at 781px), never above the desktop value. Desktop (782px+) keeps the * full --aca-welcome-stats-gap above. */ @media (max-width: 781px) { html body .aca-video-feature.wp-block-group { padding-bottom: clamp(4rem, 15vw, var(--aca-welcome-stats-gap)); } } /* * Same section-H2 values as .aca-differentiators__heading (and * .aca-welcome__heading / .aca-find-way__heading). Those three are separate * rules, not a shared selector list, so the values are repeated here. * * font-size is the same fluid --wp--preset--font-size--display token the * differentiators heading uses (theme.json fluid: true, wideSize 1920px, so * WP generates clamp(35.2px, 2.2rem + ((1vw - 3.2px) * 1.8), 64px) -- 64px * only at 1920px and up), so both headings scale together at every width. * * margin-top: 0 -- the eyebrow above already carries margin-bottom 32px, * and the generic h2 top margin (96px live, = 1.5em at 64px) was winning * the margin collapse. (0,2,2) beats those (0,1,1) content-heading rules. */ html body .aca-video-feature__heading.wp-block-heading { font-family: var(--wp--preset--font-family--cardo); font-size: var(--wp--preset--font-size--display); line-height: 1.2; text-align: center; margin-top: 0; } /* Full width of the group's content box, scaling down with it on mobile. */ html body .aca-video-feature .wp-block-video { width: 100%; max-width: 100%; } html body .aca-video-feature .wp-block-video video { display: block; width: 100%; max-width: 100%; height: auto; } /* --------------------------------------------------------------------- * Stats bar * ------------------------------------------------------------------- */ /* * .wp-block-group appended: this section's own outer element is * `
`, carrying the * same generic WP block class this file's top comment now warns about * (a class-count specificity loss to a Kadence `.single-content * .wp-block-*` default, distinct from the html-body type-selector * defense). Not confirmed to be an active conflict on the live site the * way .aca-welcome__row's was — applied proactively since the exposure * itself is real and the fix costs nothing. */ /* * border-top/bottom: confirmed via Figma nodes 18:1950/18:1952 ("Rectangle * 74"/"Rectangle 75"), two 1920px-wide, 4px-tall mustard-gold rectangles * sitting at this section's own top and bottom edges. Decorative only, * new scope this batch -- not a fix to an existing regression. * * padding-top/bottom 107px/127px (6.6875rem/7.9375rem): previously an * unmeasured clamp(2.5rem, 5vw, 3.5rem), which landed the live section at * ~202px tall against Figma's real 324px. Measured directly from plain * rectangle/ellipse nodes, not text -- node 1:82's own top/bottom (y 2148, * height 324) against icon circle node 16:9's top/bottom (y 2255, height * 90) -- so unlike the differentiators heading gap, there's no text * leading to correct for here; the raw metadata delta is the real value: * 2255-2148=107 top, (2148+324)-(2255+90)=127 bottom. 107+90+127=324, * matching node 1:82's real height exactly. Fixed values, not a clamp, * since the icon circle they wrap is itself a fixed 90px at every width * (.aca-stats__icon below), the same reasoning already used for the * differentiators numeral/row measurements. */ html body .aca-stats.wp-block-group { position: relative; background-color: var(--wp--preset--color--wine); padding: 6.6875rem clamp(1.5rem, 6vw, 5rem) 7.9375rem; border-top: 4px solid var(--wp--preset--color--mustard-gold); border-bottom: 4px solid var(--wp--preset--color--mustard-gold); } /* * Background layer only -- same architecture as .aca-hero::before: kept * off .aca-stats itself so the opacity only fades the decorative * texture, not the wine background color or the content on top of it. * * Confirmed via Figma node 12:35 ("Rectangle 75", same position/size as * the section's own background rect 1:82): a repeating cross/quatrefoil * texture, authored in Figma at ~10% opacity. Asset * (assets/stats-bar-pattern.png) is exported at exactly 1920x324 -- the * section's own real Figma dimensions -- confirming Figma's scaleMode: * CROP means "fill the section," not "tile a small swatch," so this * isn't a `repeat` tile. * * background-size: cover, not 100% 100% -- that stretched each axis * independently to fill the box, which only looks right at the box's * original 1920x324 proportions. At narrower widths where the stats * grid wraps to 2x2, the section gets much taller relative to its * width, and the independent-axis stretch visibly squeezed/elongated * the pattern's crosses out of proportion -- confirmed via real * screenshots at the wrapped width, not assumed from the mechanism * alone. cover scales the image uniformly on both axes and crops * whatever overflows, keeping the crosses correctly shaped at any * width -- the right tradeoff for a subtle, repeating-looking texture * where losing a bit at the edges is unnoticeable but a warped shape * isn't. * * opacity 0.3, not Figma's literal 0.1: a deliberate client-directed * deviation, not a measurement. This value has moved twice before * landing here, and both earlier moves were methodology mistakes worth * recording so they don't repeat: * 1. The first pass (0.3) was tuned against a broken export of this * asset with a solid white background instead of a transparent * one, so the whole layer faded in uniformly rather than showing * texture -- 0.3 was only needed to make anything visible at all * against THAT file. * 2. After the file was corrected to a real transparent background, * a second pass dropped this to 0.15 based on zoomed, upscaled * screenshot crops, which made the subtle per-pixel contrast look * far more visible than it actually is at real, un-zoomed viewing * scale -- confirmed genuinely near-invisible on the live page, * and reproduced here too once re-checked at native (unscaled) * screenshot resolution instead of a magnified crop. * Re-tested a third time at native resolution against the confirmed * true background-color (rgb(106, 7, 16) / #6A0710, verified via * getComputedStyle and a direct pixel sample of the rendered * screenshot, not assumed): 0.15-0.2 reads as flat red at normal * viewing distance, 0.3 is where the texture is reliably visible * without magnification, 0.5+ starts to compete with the wine red. */ html body .aca-stats::before { content: ""; position: absolute; inset: 0; z-index: 0; background-image: url(../stats-bar-pattern.png); background-size: cover; background-position: center; background-repeat: no-repeat; opacity: 0.3; pointer-events: none; } html body .aca-stats__grid { position: relative; z-index: 1; display: flex; flex-wrap: wrap; justify-content: space-between; gap: 2rem; } html body .aca-stats__item { display: flex; align-items: center; gap: 1.25rem; flex: 1 1 200px; } html body .aca-stats__icon { flex: none; width: 90px; height: 90px; border-radius: 50%; background-color: var(--wp--preset--color--warm-cream); display: flex; align-items: center; justify-content: center; } /* * svg (Newman Guide's star, still hand-drawn -- no real Figma asset * exists for it, see the note in aquinas_child_register_stats_pattern()) * stays at its own placeholder size. img (the other three, now real * exported Figma assets) is sized via width/height attributes matching * each icon's own real Figma footprint (80px/82px/82px -- AquinasIcons_ * Student/Alumni/Priest, file eBOw6GfQzuFBs1gn9W0vDh) set directly on * each tag rather than forced to one shared number here, so this * rule only needs to keep them block-level (avoids inline-image * baseline whitespace inside the flex-centered circle). The real icons * are exported pre-colored black, not wine -- confirmed by sampling the * exported PNGs' opaque pixels (0,0,0) directly, not assumed -- so * unlike the svg they carry no `fill` override here; recoloring them * would depart from what Figma actually exported. */ html body .aca-stats__icon svg { width: 42px; height: 42px; fill: var(--wp--preset--color--wine); } html body .aca-stats__icon img { display: block; } html body .aca-stats__number { color: var(--wp--preset--color--white); font-family: var(--wp--preset--font-family--cardo); font-weight: 700; font-size: clamp(2.25rem, 4vw, 3rem); line-height: 1.1; margin: 0; } html body .aca-stats__label { color: var(--wp--preset--color--off-white); font-family: var(--wp--preset--font-family--roboto); font-size: 1.125rem; margin: 0; } /* --------------------------------------------------------------------- * What Makes Aquinas Different * ------------------------------------------------------------------- */ /* * margin-top 7rem (112px) is measured directly from Figma: the stats * bar background's bottom edge (node 1:82 "Section Urgent Cause", y * 2148 + height 324 = 2472) to this heading's own top edge (node 17:52, * y 2584). Both are plain rectangle/text node coordinates, not a raster * fill like the Welcome image's node was, so there's no reason to * distrust these the way that one turned out to need pixel-scanning. * * .wp-block-heading appended for the same reason as .aca-stats above: * this element is `

`, so it carries the exact class this codebase has a * confirmed real bug with elsewhere (.aca-welcome__row losing to * `.single-content .wp-block-columns` on class-count). Applied * proactively, not because this specific rule was seen failing live. */ /* * margin-bottom was a flat 12rem (192px), reasoned at the time from a * pixel-scanned Figma measurement at the 1920px reference width (see git * history). Live review confirmed that fixed value reads as an * oversized gap at BOTH breakpoints, not a mobile-only symptom -- flat * rem values don't scale down with the viewport the way this section's * other spacing (padding-inline, row gaps) already does via clamp(), so * the same 192px gap that's merely generous on desktop dominates a * mobile viewport's far shorter vertical space. Replaced with a * responsive clamp() so both breakpoints shrink accordingly: floor * 3.5rem/56px (well below the old fixed value at any width), scaling * via 8vw, ceiling 9rem/144px on desktop -- brought roughly in line * with this same section's row-to-row gaps just below (7.6875rem/ * 8.3125rem/10rem), rather than sitting well above all of them as the * old flat 192px did. */ html body .aca-differentiators__heading.wp-block-heading { font-family: var(--wp--preset--font-family--cardo); font-size: var(--wp--preset--font-size--display); line-height: 1.2; text-align: center; margin-top: 7rem; margin-bottom: clamp(3.5rem, 8vw, 9rem); } /* * padding-inline brought in scope this batch: previously flagged as an * out-of-scope, section-wide fix while addressing the numeral's own * offset. This section's outer `wp:group {"layout":{"type":"constrained"}}` * is inert on the front end for the same reason .aca-welcome__row's was * before that fix -- the `is-layout-constrained` class it needs is only * added by the block editor at save time, and this pattern's HTML is * hand-authored -- so without this rule the section sits flush against * the true browser edge with no inset at all. Reuses Hero's own padding * formula verbatim (clamp(1.5rem, 6vw, 5rem)), the same value already * applied to .aca-welcome__row for the identical reason, so the section's * content edges line up with every other section rather than introducing * a second number that happens to match today. * * This is also the real fix for the per-row heading wrapping to two * lines: the text column was narrower than Figma's box only because this * section had zero horizontal inset while Figma's did, not because the * heading itself needs text-align or a size change -- confirmed Figma * shows the headings as left-aligned, single-line, no text-center class, * exactly as already coded. */ html body .aca-differentiators.wp-block-group { padding-inline: clamp(1.5rem, 6vw, 5rem); } html body .aca-differentiators__heading .aca-differentiators__heading-accent { color: var(--wp--preset--color--mustard-gold); } /* .wp-block-columns appended -- same exposure as .aca-welcome__row, this * element is `
`. The existing * !important on margin-bottom already wins regardless of specificity, so * it's left alone; the class is added so position (and anything added * here later) gets the same protection without relying on !important * everywhere. * * align-items: stretch needs its own !important for a DIFFERENT reason * than the class-count issue above: WordPress core ships * `.wp-block-columns { align-items: normal !important; }`, which wins * outright over any non-important rule regardless of specificity, so no * specificity trick beats it -- only a matching !important does. This * was previously set to `center`, fixing the immediate symptom (numeral/ * heading/body sitting at the top of the row instead of against the * image) but centering the wrong box: the numeral's real Figma bounding * box is IDENTICAL to its paired image's (same top edge, same 372px * height), so the text column needs to STRETCH to the row's full height * -- matching the image -- not shrink-wrap to its own content and center * that smaller box. See .aca-diff-row__text below for how the numeral * and heading are positioned within that now-stretched column. */ html body .aca-diff-row.wp-block-columns { position: relative; align-items: stretch !important; margin-bottom: clamp(2rem, 5vw, 3.5rem) !important; } /* * Real row-to-row gaps, measured in Figma from each row's own * numeral/image top+height (the two share identical top/height values * within a row, so either reference point gives the same row-bottom): * 123px between row 1 and row 2, 133px between row 2 and row 3. This is * separate from, and doesn't touch, the within-row numeral-to-heading * offset (156px top / 180px left gap, set on .aca-diff-row__number and * .aca-diff-row__text above) -- that's the gap between the numeral and * its own row's heading; this is the gap between one row's content and * the next row's. :nth-of-type is used instead of a shared value because * the three real gaps differ from each other. * * Row 3's own margin-bottom (the space before the accreditation logos) * is now measured too: raw metadata gives row 3's bottom (17:44/17:47, * y 3822 + height 372 = 4194) to the accreditation group's top (18:1958, * y 4352) as 158px, and unlike the heading-to-row-1 gap above, pixel- * scanning an actual Figma screenshot confirms this one directly -- both * sides here are image/vector nodes, not auto-height text, so there's no * hidden leading to correct for. ~160px (10rem) is used as the clean * rem-equivalent of the ~158-166px raw/pixel-measured range. */ html body .aca-diff-row.wp-block-columns:nth-of-type(1) { margin-bottom: 7.6875rem !important; } html body .aca-diff-row.wp-block-columns:nth-of-type(2) { margin-bottom: 8.3125rem !important; } html body .aca-diff-row.wp-block-columns:nth-of-type(3) { margin-bottom: 10rem !important; } /* .wp-block-image appended -- this figure is `
`. */ html body .aca-diff-row__image.wp-block-image { border-radius: 36px; aspect-ratio: 583 / 372; } /* * .wp-block-group appended -- this is `
`. * * height: 100% makes this box fill its parent .wp-block-column, which * itself now stretches to the row's full height (align-items: stretch * above) -- i.e. the same height as the paired image, confirmed * identical in Figma. Percentage heights resolve correctly here because * a stretched flex item has a definite used height for descendants to * size against, not an auto one. * * padding-left 11.25rem (180px) insets the heading/body from this * column's own edge to reproduce the real gap between the numeral and * the heading in Figma -- see the full measurement in the comment on * .aca-diff-row__number below. It does NOT affect the numeral's own * position: an absolutely-positioned child's `left` offset is measured * from the parent's padding-box edge (its outer edge, same as the * border-box when there's no border), not the padding-adjusted content * edge -- confirmed directly with an isolated test (a padded parent * plus an absolute left:0 child landed the child at the parent's own * unpadded edge), not assumed. That's what lets the numeral sit flush * at this column's true start while the padding still pushes the * heading/body in. * * padding-top 9.75rem (156px) is the same mechanism on the vertical * axis: the numeral is pinned to top: 0 of this box (see * .aca-diff-row__number below), matching the image's own top edge, and * this padding-top pushes the heading/body down by the same 156px that * used to be encoded as the numeral's own negative top offset -- the * math is unchanged, only which box it's anchored to. */ html body .aca-diff-row__text.wp-block-group { position: relative; height: 100%; padding-left: 11.25rem; padding-top: 9.75rem; } /* * Numeral-behind-text overlap: confirmed real via Figma's own node * positions, not a bug to remove. * * top: 0, NOT the numeral-top-to-heading-top offset. Confirmed directly * in Figma: the numeral's bounding box is IDENTICAL to its paired * image's -- same top edge, same 372px height (e.g. row 1: both node * 3:91 and its image rect start at y 2822, both 372px tall) -- so the * numeral is meant to span the same vertical range as the image, not * sit as its own auto-height group offset above the heading. With * .aca-diff-row__text now stretched to the row's full height (matching * the image -- see that rule above) and this numeral positioned * relative to it, top: 0 puts the numeral flush with the image's own * top edge on every row. The 156px numeral-to-heading offset (nodes * 3:91/3:92, 17:48/17:49, 17:44/17:45, the same fixed constant as * before) is now expressed as padding-top on .aca-diff-row__text * instead, pushing the heading/body down from that same shared top * edge -- the math is unchanged, only which box it's anchored to. * * left: 0, NOT an offset relative to the heading. The numeral's real * absolute position in Figma is ~314px for the text-left rows (01, 03) * and ~992px for the text-right row (02) -- both match the column-start * convention the opposite row's image uses for its own column (e.g. * row 2's image starts at x 313, almost identical to row 1/3's numeral * at x 314), not an offset from wherever the heading happens to sit. * left: 0 here (an absolutely-positioned child measures its offset from * the parent's padding-box edge, i.e. .aca-diff-row__text's own * unpadded edge -- see the comment on that rule above) puts the numeral * at this column's true start in exactly the same way regardless of * which physical side of the row the column is on, which is what * actually reproduces "same column-start convention" in code rather * than one specific pixel number. * * The gap this leaves between the numeral and the heading -- the * padding-left on .aca-diff-row__text -- is 184px/174px/68px on rows * 1/2/3 (heading-left minus numeral-left in Figma's own coordinates). * Rows 1 and 2 agree closely; row 3 doesn't (its heading wraps to two * lines, likely hand-nudged independently of the numeral). Using 180px, * representative of the two consistent rows, as one shared value rather * than encoding row 3's likely-incidental deviation. * * font-size 291px (18.1875rem) is confirmed via get_design_context * (which reports the authored value straight from the node) on node * 3:91, the "01" numeral. The task asked to confirm this is one * consistent value across all three rows rather than a per-row number; * 17:48 ("02") and 17:44 ("03") were not independently re-checked via * get_design_context in this pass, so this single value is applied to * all three on the strength of the 3:91 check plus the original design * intent (one shared numeral style), not because all three nodes were * individually confirmed -- worth a follow-up get_design_context call * on those two nodes once Figma access is available again. It was * previously an unverified clamp(5rem, 12vw, 9rem); opacity (0.5) and * color (warm-cream) were already correct. * * These are Figma's real relative numbers, faithfully reproduced -- * but the ABSOLUTE page position this produces still won't match * Figma's ~314px/~992px exactly, because this section's own left/right * padding doesn't match Figma's real ~314px inset for this section (it * currently has no real padding constraint at all beyond whatever * generic default applies -- the differentiators section's `wp:group * {"layout":{"type":"constrained"}}` is inert on the front end for the * same reason .aca-welcome__row's was before that fix: the * `is-layout-constrained` class it needs is only added by the block * editor at save time, and this pattern's HTML is hand-authored). * Fixing that is a section-wide padding change, not a numeral-specific * one, so it's flagged here rather than folded into this fix. * * position: absolute + z-index: 0, with the heading/body given z-index: 1 * of their own (rather than a negative z-index on the numeral alone, * which would otherwise be enough by itself: a positioned descendant * with a negative z-index paints below any normal in-flow sibling * within the same containing block). That simpler version is what was * tried first, and it's correct CSS, but it hit an actual rendering bug * in this environment's Chromium: with z-index: -1 specifically, at this * font-size, the "1" in "01" silently failed to paint at all (confirmed * via getBoundingClientRect/elementFromPoint that the glyph's own box * was there and correctly sized, it just never got drawn) — removing * only the negative z-index, nothing else, made it paint correctly * again. Rather than ship something that happened to break in testing, * this uses a non-negative z-index on the numeral and lets the heading/ * body opt into a higher one instead, which produces the identical * visual stacking without tripping whatever that bug is. */ html body .aca-diff-row__number { position: absolute; top: 0; left: 0; z-index: 0; font-family: var(--wp--preset--font-family--lora); font-weight: 700; font-size: 18.1875rem; color: var(--wp--preset--color--warm-cream); opacity: 0.5; line-height: 1; margin: 0; } /* * top needs no override here -- it's 0 at every width, same as desktop, * since the numeral always tracks its stretched box's own top edge * regardless of column width. font-size scales down with the same * factor .aca-diff-row__text's padding-top below now uses, keeping the * numeral-to-heading offset proportionate on a narrow column. left * needs no override either, for the same reason established previously: * checked directly via rendered getBoundingClientRect at 375px. * * .aca-diff-row__text's own padding-top halves along with font-size, * same proportion as desktop. padding-left does NOT simply halve to * 5.625rem (the naive equivalent) -- at this font-size a two-digit * numeral like "01" renders ~146px wide, confirmed by both * getBoundingClientRect and a pixel-level screenshot check, which found * the heading's own leading letter genuinely starting underneath the * numeral's stroke at 90px, not just a bounding-box artifact (the * equivalent desktop check found a real, clear gap there, so this is a * mobile-specific fix, not a revisit of the desktop numeral/heading * overlap, which is intentional and confirmed via Figma elsewhere in * this file). 10rem/160px clears the numeral's real ~146px width with a * small margin. */ @media (max-width: 599px) { html body .aca-diff-row__number { font-size: 9.09375rem; } html body .aca-diff-row__text.wp-block-group { padding-left: 10rem; padding-top: 4.875rem; } /* * Equal spacing between all three stacked blocks -- overriding the * three different desktop-measured nth-of-type margins (7.6875rem/ * 8.3125rem/10rem), which read as inconsistent once stacked into a * single mobile column rather than three side-by-side desktop rows. */ html body .aca-diff-row.wp-block-columns:nth-of-type(1), html body .aca-diff-row.wp-block-columns:nth-of-type(2), html body .aca-diff-row.wp-block-columns:nth-of-type(3) { margin-bottom: 3rem !important; } } /* * Desktop's alternating image-left/image-right layout is achieved via * literal DOM source order (see the $first/$second swap in * aquinas_child_register_differentiators_pattern()), not a CSS * order/grid-area property -- "reverse" rows (02, 04, ...) put the image * column before their own text column. WP core's mobile column-stacking * rule (below 782px) preserves DOM order when it stacks columns, so those * rows rendered image-then-text once stacked. Pushing whichever column * holds the image to the end makes every stacked row read number/text * then image, regardless of row position or count (previously this was a * row-02-only nth-of-type rule, which missed row 04 on the Academics * page). Scoped to the stacking breakpoint only, so desktop's side-by-side * alternation (driven by that same DOM order) is unaffected. */ @media (max-width: 781px) { html body .aca-diff-row.wp-block-columns > .wp-block-column:has(.aca-diff-row__image) { order: 2; } } /* * .wp-block-heading appended -- `

`. position/z-index: see the comment on * .aca-diff-row__number above. * * text-align: center is a deliberate deviation from Figma, requested * directly by the client to match the already-centered body copy below * -- Figma itself confirms these headings (nodes 3:92/17:49/17:45) are * left-aligned, single-line text (textAlignHorizontal: LEFT), so this is * knowingly overriding the design file, not a bug fix. */ html body .aca-diff-row__heading.wp-block-heading { position: relative; z-index: 1; font-family: var(--wp--preset--font-family--lora); font-weight: 700; font-size: var(--wp--preset--font-size--heading); line-height: 1.2; color: var(--wp--preset--color--black); text-align: center; margin: 0 0 0.75rem; } /* * text-align: center confirmed directly via get_design_context on node * 3:95 (the body paragraph), which reports a literal `text-center` * class on the node itself -- not inferred from a screenshot. * position/z-index: see the comment on .aca-diff-row__number above. * * margin: 0 was missing entirely -- unlike .aca-diff-row__heading just * above, which already zeroes its own margin-top explicitly, this rule * never set any margin at all. This

has no wp:paragraph block * comment wrapping it in block-patterns.php, so it doesn't pick up WP * core's block-library paragraph reset; without a theme-level `p` * reset covering it either, it was left to fall back to a default * margin (browser UA default is `margin: 1em 0`, sized against * whatever font-size it inherits) that this test harness never * reproduced. That default margin-top pushed the paragraph down below * its intended 156px-from-top position, extending this box past the * paired image's bottom edge on the live page. Zeroed here rather than * guessing at Kadence's actual default, since zero is correct * regardless of what that default turns out to be. */ html body .aca-diff-row__body { position: relative; z-index: 1; margin: 0; color: var(--wp--preset--color--muted-text); max-width: 26rem; text-align: center; } /* * gap 81px (5.0625rem) is measured directly from Figma: the ICLE logo's * right edge (node 18:1957 "icle_orig 1", x 590 + width 355 = 945) to * the NAPCIS logo's left edge (node 18:1956 "napcis-logo-scaled_orig 1", * x 1026). Previously an unmeasured clamp(2rem, 5vw, 4rem). * * align-items: center was already correct and is exactly why the two * logos should already level with each other -- the real bug was * .aca-accreditation__logo forcing both figures to the SAME aspect * ratio (320/84), when Figma shows they're genuinely different sizes: * ICLE is 355x98 (aspect 3.62), NAPCIS is 304x80 (aspect 3.8). Their * vertical centers, computed from Figma's own y+height/2, are IDENTICAL * (4401 for both) -- confirming they're meant to be center-aligned at * different heights, not forced to one shared box. See * .aca-accreditation__logo--icle/--napcis below for each one's own real * size; this shared rule now only carries what's actually common to both. */ html body .aca-accreditation { display: flex; flex-wrap: wrap; align-items: center; justify-content: center; gap: 5.0625rem; margin-top: clamp(1.5rem, 4vw, 3rem); } /* * .wp-block-image appended on each variant below -- both logos are now * real exported assets (`