/* * Theme Name: 5U Worlds * Theme URI: https://fiveandunderworldchampionship.com * Description: Child theme for the Five and Under World Championship website, * based on Twenty Twenty-Four. * Author: Five and Under World Championship * Template: twentytwentyfour * Version: 1.0.1 */ /* ============================================================ COLOR & TYPOGRAPHY TOKENS These custom properties drive every color decision on the site. Change a value here and it updates everywhere. ============================================================ */ :root { /* Brand colors SEMANTIC ROLES — the rule of thumb for using these going forward, established while building the nav's interaction states. Keep new sections consistent with this: --5u-red : primary CTA / actionable buttons only ("click this, it does something" — e.g. the "2026 Event Details" button) --5u-gold : highlighted but NON-interactive — section tags, labels, dividers/accents, and disabled/future states like the Shop "coming soon" button. Reserved meaning: notable, not clickable. --5u-slate : resting state for plain links/nav text, and also used for keyboard focus outlines (so focus stays visually distinct from both hover and from gold's "disabled" meaning) --5u-ice-white : hover/active brightening — "this is interactive and you're engaged with it" — also primary body text color on dark backgrounds */ --5u-navy-deepest: #060E16; /* footer background */ --5u-navy-dark: #0A1520; /* nav, event strip, champion card headers */ --5u-navy-base: #0D1B2A; /* hero (dark mode), champion section (dark mode) */ --5u-navy-lift: #112233; /* sponsors, mission (dark mode) */ --5u-navy-mid: #0F2236; /* explainer section (dark mode) */ --5u-red: #C8102E; /* primary CTA, accent */ --5u-red-hover: #a50d25; --5u-gold: #B8972A; /* section labels, footer headings, borders */ /* Medal-tier accents — Champions page only. Deliberately distinct from --5u-gold above: --5u-gold is reserved for non-interactive "notable" UI (section tags, disabled states) per the semantic rule documented above, not for literal medal coloring. These three are purely representational (this team won gold/silver/ bronze), so they get their own tokens rather than overloading --5u-gold with a second meaning. */ --5u-medal-gold: #D4AF37; --5u-medal-silver: #9DA7B0; --5u-medal-bronze: #B08D57; --5u-ice-white: #F0F4F8; /* primary text on dark */ --5u-slate: #8FA3B1; /* secondary text on dark */ --5u-slate-dim: #6B7C93; /* muted text, strip labels */ --5u-slate-dimmer: #4A5E6D; /* very muted text */ --5u-slate-dimmest: #3A4E5C; /* footer link color */ /* Light mode surface colors */ --5u-light-page: #F7F8FA; --5u-light-surface: #ffffff; --5u-light-surface-alt:#F0F4F8; --5u-light-border: #E2E8EF; --5u-light-text: #1A2733; --5u-light-text-body: #3A4E5C; --5u-light-text-muted: #4A5E6D; /* Typography */ --5u-font-display: 'Barlow Condensed', sans-serif; --5u-font-body: 'Barlow', sans-serif; /* Layout Full-width sections (nav, colored bands) stay edge-to-edge. This caps the INNER content of each section so text and elements don't stretch absurdly wide on large monitors — same pattern used by Silicon Valley Curling's site, which keeps a full-width nav but caps body content at a sane width. SINGLE SOURCE OF TRUTH: WordPress automatically generates a CSS custom property --wp--style--global--content-size from theme.json's settings.layout.contentSize value. Rather than hardcoding 1232px a second time here, we reference that generated property directly — so theme.json is the only place the actual number lives. If you ever change the site's content width, update ONLY theme.json's contentSize; this variable (and therefore every section on the homepage) follows automatically. The hardcoded 1232px below is a fallback only, used if that custom property is ever unavailable (e.g. theme.json failing to load), and should be kept roughly in sync as a safety net, though it is no longer the actively-used value in normal operation. */ --5u-content-max: var(--wp--style--global--content-size, 1232px); /* The ACTUAL visible content box width is narrower than --5u-content-max once you account for the section padding that insets content from the section's own edges (32px each side at minimum, per .su-hero/.su-strip/etc's calculated padding). Font-size clamps that used raw --5u-content-max as their MAX ceiling were calibrated to a wider box than the one they actually render inside — the visible content area only reaches the FULL --5u-content-max width once the viewport is content-max + (padding × 2) wide, creating a "dead zone" where the content box is already at full width but text was still using a smaller calculated max (confirmed via testing: with 32px padding each side, this zone spans roughly 1232–1296px viewport width). Use THIS variable, not --5u-content-max directly, when sizing text that should hold steady exactly when the content box itself stops growing. */ --5u-content-visible: calc(var(--5u-content-max) - 64px); /* The rings SVG's hatch pattern and "empty" alternating rings (8ft, button) need to paint the SAME color as whatever sits directly behind the rings graphic — i.e. .su-hero's own background — so the hatch punches genuinely show as "gaps" rather than a mismatched color. Defaults to light mode's hero background; overridden in body.dark-mode below to match dark mode's hero background instead. If .su-hero's background ever changes, update this variable to match, in both places. */ --5u-rings-bg: var(--5u-light-surface); /* Rings stroke/line color. Gold reads fine against the dark hero background (--5u-navy-base) but has too little contrast against light mode's white background to register as a visible texture at the rings' low opacity — confirmed via screenshot, where gold-on-white was nearly invisible aside from the pin dot. --5u-slate-dimmer was chosen over gold-darkened-further or plain --5u-slate: darkening gold risked reading as muddy/ brown, and --5u-slate itself is actually similarly low-contrast against white (both sit in a pale midtone band) — slate-dimmer is meaningfully darker (roughly 2.4x the contrast ratio against white) while staying a cool blue-gray rather than warming toward brown. Defaults to light mode's value here; overridden in body.dark-mode below back to gold, which already works correctly against the dark hero. */ --5u-rings-line: var(--5u-slate-dimmer); /* Hatch pattern line color — deliberately the OPPOSITE of --5u-rings-line in each mode (gold here, where the solid ring strokes are slate-dimmer). This gives the two hatched rings (12ft, 4ft) a visibly different tone from the two solid-stroke rings (8ft, button) they alternate with, so the alternating pattern reads more clearly as a pattern rather than a flat texture — confirmed as an improvement via side-by-side screenshot. Both colors stay subdued enough at the rings' low opacity that the motif stays recessive either way; this is a refinement of the texture, not a contrast fix like --5u-rings-line was. Overridden in body.dark-mode below to the opposite pairing (slate-dimmer hatch, gold strokes). */ --5u-rings-hatch: var(--5u-gold); /* Spacing */ --5u-section-pad: 38px 32px; } /* ============================================================ GOOGLE FONTS Previously loaded here via @import — moved to a proper wp_enqueue_style() call in functions.php instead, since @import is unreliable in production (slower, sometimes stripped by caching/minification, sometimes blocked by CSP). See the comment in functions.php's fiveunder_enqueue_styles() for the full explanation. This is the actual likely cause of Barlow/Barlow Condensed not rendering on the live site and silently falling back to the browser's default sans-serif. ============================================================ */ /* ============================================================ GLOBAL RESETS FOR TWENTYTWENTYFOUR TT4 applies some opinionated defaults we need to tame. ============================================================ */ /* overflow-x: hidden on BOTH html and body — body alone was tried first and confirmed NOT sufficient (still scrolled horizontally on iPad/phone after that fix shipped). The root cause: the actual viewport-level horizontal scrollbar is governed by the ROOT element (), not — per browser behavior, when the root element's own overflow isn't constrained, an overflowing descendant's box can still create a page-level scrollbar regardless of what alone specifies, because 's overflow only contains scrolling WITHIN 's own box, not the viewport's scroll root. Setting it on is what actually stops a full-bleed negative-margin element (see .su-champ-grid) from widening the page. */ html { overflow-x: hidden; width: 100%; } body { font-family: var(--5u-font-body); font-size: 15px; line-height: 1.65; background: var(--5u-light-page); color: var(--5u-light-text); /* Safeguard against full-bleed elements with negative margins (e.g. .su-champ-grid's intentional bleed past --5u-content-max toward the viewport edge) widening the PAGE's own horizontal scroll area. A child can legally extend past its parent's edge via negative margin; without something in the ancestor chain clipping that overflow, it propagates all the way up to the document, creating page-level horizontal scroll. See the matching rule on above — that's the one actually doing the work; this is kept too for defense in depth, since some browsers honor either depending on quirks/standards mode. */ overflow-x: hidden; width: 100%; } /* STICKY FOOTER — keeps the footer pinned to the bottom of the viewport on short pages instead of floating up directly under the content, while staying out of view (below the fold) until scrolled to on long pages. WordPress block themes wrap the header/main-content/footer template parts in a single ".wp-site-blocks" div, a direct child of body — confirmed via devtools — so that's the flex container that needs to stretch to at least the viewport height, with the main content area (not header/footer) absorbing any extra space. */ .wp-site-blocks { display: flex; flex-direction: column; min-height: 100vh; } .wp-site-blocks > main { flex: 1 0 auto; } /* Dark mode — applied to by theme.js */ body.dark-mode { background: var(--5u-navy-base); color: var(--5u-ice-white); --5u-rings-bg: var(--5u-navy-base); --5u-rings-line: var(--5u-gold); --5u-rings-hatch: var(--5u-slate-dimmer); } h1, h2, h3, h4, h5, h6 { font-family: var(--5u-font-display); } /* TT4 sets its own explicit heading color via theme.json (generated as a :root :where(h1,h2,...) rule), which doesn't change with our manual dark-mode toggle — confirmed as the cause of headings staying dark-text-colored even on a dark background on regular Gutenberg pages. :where() carries zero specificity, so a plain element selector here can't outrank it; !important is the reliable fix, same approach used elsewhere in this file for overriding WP/TT4-generated styles. */ body.dark-mode h1, body.dark-mode h2, body.dark-mode h3, body.dark-mode h4, body.dark-mode h5, body.dark-mode h6 { color: var(--5u-ice-white) !important; } a { color: var(--5u-red); text-decoration: none; } /* Dark mode: plain content links (History, Champions, etc. — not homepage-specific classes like .su-link, which already have their own treatment) used the same red as primary CTA buttons, which reads as harsh against the dark navy background and blurs the "red = actionable button" semantic this token is meant to carry elsewhere. Matches the resting/hover language already documented at the top of this file for nav links (slate resting, ice-white brightening on hover) instead of inventing a new pairing. Light mode is intentionally left as red — not flagged as a problem. */ body.dark-mode a { color: var(--5u-slate); } body.dark-mode a:hover { color: var(--5u-ice-white); } /* ============================================================ TWENTYTWENTYFOUR LAYOUT OVERRIDES — HOMEPAGE ONLY These rules strip WP's native content width cap and inter-block spacing so the homepage's Custom HTML block can go full-bleed and control its own section padding directly. Scoped to body.home (the class WP adds to whichever page is set as the static homepage in Settings -> Reading) — without this scoping, these rules were applying site-wide, which is why other native- Gutenberg pages (History, Champions, etc.) had no content max-width and squashed block spacing: theme.json's contentSize and WP's default block gap were being stripped from them too, not just from the homepage they were actually meant for. ============================================================ */ /* Belt-and-suspenders on width — theme.json sets contentSize to 100% but some constrained layout wrappers need this too */ body.home .is-layout-constrained > :where(:not(.alignleft):not(.alignright):not(.alignfull)) { max-width: 100% !important; } body.home .wp-site-blocks, body.home .wp-block-post-content, body.home .entry-content { padding-left: 0 !important; padding-right: 0 !important; max-width: 100% !important; } /* Remove any remaining inter-block margins */ body.home .is-layout-flow > * + *, body.home .wp-block-post-content > * + * { margin-top: 0 !important; } /* Hide the Post Title block. theme.json sets its color to transparent and font-size to 0, but display:none here ensures it takes up no space at all. */ .wp-block-post-title, h1.wp-block-post-title { display: none !important; } /* TT4's page template wraps the (hidden) title in two Spacer blocks — one above, one below — that reserve vertical space regardless of whether the title itself is visible. Hiding the title alone left ~144px of dead space at the top of every page. These spacers use TT4's preset spacing scale (--wp--preset-- spacing--50 and --30), so we target the spacer elements directly rather than guessing pixel values, since that scale can vary by TT4 version. */ .wp-block-post-title + .wp-block-spacer, .wp-block-spacer:has(+ .wp-block-post-title), .wp-block-spacer:has(+ h1.wp-block-post-title) { display: none !important; } /* Belt-and-suspenders: collapse the entire Group wrapping the title and its spacers down to zero height, in case the above :has() selectors don't catch every spacer (e.g. if TT4 changes the exact sibling structure in a future update). */ .wp-block-group:has(> h1.wp-block-post-title) { min-height: 0 !important; height: 0 !important; overflow: hidden; margin: 0 !important; padding: 0 !important; } /* Full width for our Custom HTML block. NOTE: theme.json sets contentSize to 1232px, which WordPress automatically exposes as the CSS variable --wp--style--global--content-size. Our own --5u-content-max variable (defined at the top of this file) reads directly from that generated property, so theme.json is the single source of truth for the site's content width — this homepage's hand- written calc()-based section padding and any other page built with native Gutenberg blocks both ultimately derive from the same one number, even though they apply it through different mechanisms (this page can't use theme.json's layout system directly since it's a Custom HTML block, not native blocks). */ .wp-block-html { max-width: 100% !important; width: 100% !important; padding: 0 !important; margin: 0 !important; } /* ============================================================ NATIVE PAGE CONTENT — SIDE PADDING (non-homepage pages: History, Champions, About, etc.) theme.json's `styles.spacing.padding` is set to 0 on all sides site-wide (needed for the homepage's full-bleed Custom HTML block), and theme.json has no mechanism to scope that to the homepage only — it isn't a body-class-aware system like the CSS overrides above. That 0 padding lands on .wp-block-post-content on EVERY page, not just the homepage. This is invisible at wide viewports because WP/TT4's native "constrained" layout already centers .wp-block-post-content at --5u-content-max width with auto side margins — at those widths, the empty space outside that centered box reads as if it were padding. But once the viewport narrows to roughly --5u-content-max or below, that auto-margin collapses to 0 and the content box becomes exactly viewport-width with its own padding still 0 — so text runs flush to the screen edge. This reproduces identically on desktop (narrow/resized browser window) and on every mobile breakpoint, which is why it can't be fixed inside a single max-width media query — it isn't a breakpoint-specific bug, it's a missing inset that's been there at every width all along, just masked by the centering at wide viewports. Fix: restore side padding directly on .wp-block-post-content, scoped to non-homepage pages so the homepage's full-bleed setup (handled separately above) is untouched. No !important needed — theme.json's generated rule uses :where() (zero specificity), so a plain class selector already outranks it. Same max(32px, calc(...)) inset formula as every homepage section, so native pages end up with the same effective ~1168px inner content width as the homepage instead of inventing a different number. */ body:not(.home) .wp-block-post-content { padding-left: max(32px, calc((100% - var(--5u-content-max)) / 2)); padding-right: max(32px, calc((100% - var(--5u-content-max)) / 2)); box-sizing: border-box; } /* ============================================================ NAVIGATION TT4's site header block gets a custom class "su-nav" applied in the Site Editor (select the Header template part, add "su-nav" to the block's Additional CSS class field). ============================================================ */ .su-nav, .wp-block-template-part.su-nav { background: var(--5u-light-surface) !important; border-bottom: 2px solid var(--5u-gold); min-height: 54px; /* Sticky header */ position: sticky; top: 0; z-index: 100; } /* Light mode is the default above — nav was previously a permanent dark band regardless of mode (same family as the footer), but confirmed direct request to make it toggle-aware: as a thick, high-contrast persistent element, it disproportionately dominated the page once everything else switched to light. Every other color rule in this nav block gets the same dark-mode override treatment below, for the same reason. */ body.dark-mode .su-nav, body.dark-mode .wp-block-template-part.su-nav { background: var(--5u-navy-dark) !important; } /* The outer "su-nav" group itself carries .alignwide, which TT4's own stylesheet caps at a fixed max-width via the --wp--style-- global--wide-size custom property and a centering margin. Override directly on the class WordPress actually renders. */ .su-nav.alignwide { max-width: 100% !important; width: 100% !important; margin-left: 0 !important; margin-right: 0 !important; padding-left: 16px !important; padding-right: 28px !important; box-sizing: border-box; } /* The inner row (logo + nav) is ALSO .alignwide, nested one level in. Same fix needed here, plus this is the flex row that should actually stretch and space its children apart. */ .su-nav .wp-block-group.alignwide { max-width: 100% !important; width: 100% !important; margin-left: 0 !important; margin-right: 0 !important; } /* CRITICAL: force the logo+nav row to stay on one line. TT4's flex group defaults to wrapping, and once the outer width grew to 100%, the gap between the two flex children exceeded the row's available space calculation and the nav dropped to a second line. NOTE: WordPress core's own .is-layout-flex base rule sets flex-wrap: wrap with no !important, but it was still beating our rule due to selector specificity / load order. The extra class repetition below (.su-nav.su-nav) artificially boosts specificity past core's single-class selector without relying on cascade order. IMPORTANT: every selector here is scoped with :not() to exclude anything inside the mobile responsive container. Earlier broader versions of these rules (especially the unscoped is-layout-flex rule and a bare div.wp-block-group selector with no .su-nav ancestor) were matching elements inside the mobile menu overlay too, interfering with TT4's own show/hide breakpoint logic and causing the mobile nav list to render inline in the desktop bar. */ .su-nav > .wp-block-group.alignwide.is-content-justification-space-between { flex-wrap: nowrap !important; align-items: center !important; width: 100%; } /* The two direct children (logo group, nav group) should not shrink to zero or grow unexpectedly — keep them sized to content. Scoped to the direct child of the top-level row only. */ .su-nav > .wp-block-group.alignwide.is-content-justification-space-between > .wp-block-group { flex: 0 0 auto !important; } /* Collapse the empty flow group WordPress inserts after the logo (an artifact of the Site Logo block's internal structure) so it doesn't add phantom width */ .su-nav .wp-block-site-logo + .wp-block-group.is-layout-flow:empty { display: none !important; } /* Logo is set to 96x96 in the Site Logo block itself (desktop size), which is too large on tablet/phone. Step it down at the same two breakpoints as the rest of the site rather than relying on the block's own fixed width/height attributes. */ .su-nav .wp-block-site-logo img { width: 96px !important; height: 96px !important; } /* is-layout-constrained adds TT4's default inner padding/margin behavior — neutralize ONLY on the top-level desktop nav row's own descendants, explicitly excluding anything inside the mobile responsive container so we never touch its internal layout or interfere with TT4's breakpoint visibility toggle. */ .su-nav > .wp-block-group.is-layout-constrained, .su-nav > .wp-block-group .is-layout-constrained:not(.wp-block-navigation__responsive-container *), .su-nav > .wp-block-group .is-layout-flex:not(.wp-block-navigation__responsive-container *) { max-width: 100% !important; } /* NOTE: TT4 uses a single nav link list for both desktop and mobile — there is no separate "desktop horizontal nav" element. The same