/**
 * Bonza, global site footer.
 *
 * Figma: cY9QX6IwGVaaGI4r7J2RRF, component set FOOTER 564:95449.
 * Desktop variant 29399:99534 (1480px), Tab 2 17298:196546 (744px),
 * Mobile 2 17298:196807 (428px). Button states from component set
 * Button 29049:58925 (Kind=Secondary used for the two solid CTAs,
 * Kind=Outline for the amber-band secondary CTA). ClickUp 86eypb6aw.
 *
 * Rendered by clients/bonza/bonza.php (bonza_footer_render_global) on
 * the `blocksy:builder:footer:custom-output` filter. Scoped entirely
 * under .bfg-footer so it never leaks into other client CSS.
 *
 * Colour tokens are declared locally (no site-wide theme.json colour
 * preset exists yet, that is task 86eyk8nqd "Design foundations",
 * still in progress) as `var(--bfg-*, <figma-hex>)` so a later global
 * token pass can override them without touching this file.
 *
 * @date 2026-08-26
 */

.bfg-footer {
	--bfg-cream: var(--bfg-color-cream, #F8EDE3);
	--bfg-amber: var(--bfg-color-amber, #FFA825);
	--bfg-green: var(--bfg-color-green, #247B4E);
	/* 86eypb6aw Figma-sync (final parity pass): both greens are now the
	   single Figma-literal #247B4E, not the two darkened stand-ins this
	   file used before (#257E50 / #1F6B42). Re-measured against every
	   surface they actually sit on: #247B4E on #F8EDE3 is 4.53:1 (passes
	   WCAG 2.2 AA's 4.5:1 floor for normal text, incl. the 14px/900
	   nav headings and card eyebrow tag); white text on a #247B4E fill
	   (the primary button) is 5.23:1. Both clear AA with the exact
	   Figma value, so the extra darkened token this file used to carry
	   for "small text on green" is no longer needed. --bfg-green-text
	   is kept as a separate variable (same value) rather than deleted,
	   so every existing var(--bfg-green-text) call site below does not
	   need touching. */
	--bfg-green-text: var(--bfg-color-green-text, #247B4E);
	--bfg-yellow: var(--bfg-color-yellow, #FFC125);
	--bfg-ink: var(--bfg-color-ink, #2E2A2A);
	--bfg-white: var(--bfg-color-white, #FFFFFF);
	/* WHY --bfg-ink not --bfg-white: Figma draws the copyright line
	   #FFFFFF on this #F8EDE3 band, 1.15:1 contrast (measured via the
	   WCAG relative-luminance formula), fails WCAG 2.2 AA (4.5:1 floor
	   for normal text). Landing under 86eypb8gy, the whole-site AA audit
	   task, per the plan's explicit instruction to defer this fix out of
	   the footer build task. --bfg-ink is now the Figma-literal #2E2A2A
	   (86eypb6aw Figma-sync, was #494545), which on #F8EDE3 measures
	   12.3:1, passes AA and AAA (7:1) with more margin than before. */
	--bfg-copyright-color: var(--bfg-color-copyright, var(--bfg-ink));

	--bfg-heading-font: "Nominee", var(--theme-font-family, sans-serif); /* --theme-headings-font-family tier removed: defined nowhere in any deployed stylesheet, was a dead fallback link */
	--bfg-body-font: "Kobe1.1", var(--theme-font-family, sans-serif);
	/* Same "not loaded yet, fall back to theme font" pattern seen live
	   on this site's clients/bonza/bonza.css (cart panel heading, search
	   headline), written by concurrent work on another task and not yet
	   committed to this git worktree. Nominee/Kobe1.1 have no @font-face
	   anywhere on the site yet (open project-wide font question, see
	   ClickUp 86eypb6aw "Fonts" section). */

	display: flex;
	flex-direction: column;
	background-color: var(--bfg-cream);
	font-family: var(--bfg-body-font);
	color: var(--bfg-ink);
}

.bfg-footer a {
	color: inherit;
	text-decoration: none;
}

.bfg-footer h2,
.bfg-footer h3 {
	margin: 0;
	font-family: var(--bfg-heading-font);
	font-weight: 900;
	text-transform: uppercase;
}

.bfg-footer ul {
	list-style: none;
	margin: 0;
	padding: 0;
}

.bfg-footer button:focus-visible,
.bfg-footer a:focus-visible {
	outline: 2px solid var(--bfg-green);
	outline-offset: 2px;
}

/* WHY a scoped override: the shared green focus outline above is
   2.60:1 against this band's #FFA825 fill, below the 3:1 WCAG 2.2 AA
   floor for non-text UI indicators (SC 1.4.11). Ink clears it at
   4.90:1, the same colour already used for this band's text/borders. */
.bfg-band--signup a:focus-visible,
.bfg-band--signup button:focus-visible {
	outline-color: var(--bfg-ink);
}

/* ---------------------------------------------------------------------
   Band 1, Health Hub cards + CTA (#34457:282314)
   --------------------------------------------------------------------- */
.bfg-band--hub {
	display: flex;
	flex-direction: column;
	align-items: center;
	padding: 64px;
	/* 86eypb6aw Figma-sync: Figma's own frame tree has TWO nested
	   auto-layout frames here -- an outer one (single child, its own
	   gap value is a no-op) and an inner one that actually holds
	   hub-intro / Cards Stack / the CTA button and carries gap:64. This
	   flat single-level flex column collapses both into one, so 64 is
	   the value that matters; 48 (this rule's old value) was measuring
	   the outer frame's irrelevant gap. */
	gap: 64px;
}

.bfg-hub-intro {
	display: flex;
	flex-direction: column;
	align-items: center;
	gap: 16px;
	/* 86eypb6aw parity audit (FT-02, 2026-09-14): the earlier 600px cap
	   here (a prior Figma-sync fix for a different residual mismatch)
	   forces "GO DEEPER ON THE SCIENCE" to wrap to two lines at
	   1440/1512, where the Figma reference render (cY9QX6IwGVaaGI4r7J2RRF,
	   node 34457:282316) shows it on one line -- the intro column runs
	   to the desktop hub band's own inner content width (1384px at the
	   1512 anchor: 1512 viewport minus the band's own 64px+64px
	   padding), not a fixed 600px box. Re-scoped into the existing
	   <=1024 tablet media query below rather than removed outright: the
	   600px cap was never actually load-bearing at 744/428 (the intro's
	   own rendered width there is already narrower than 600 -- 600px
	   and 388px measured live), but keeping it explicit for <=1024
	   makes that intentional, not just accidental. */
	max-width: none;
	text-align: center;
}

.bfg-eyebrow {
	margin: 0;
	font-family: var(--bfg-heading-font);
	font-weight: 900;
	font-size: 14px;
	line-height: 1.2; /* >=1.2x, 86eypb6j8 */
	letter-spacing: 0.02em;
	text-transform: uppercase;
}

.bfg-h2 {
	font-size: 36px;
	line-height: 40px;
	color: var(--bfg-green);
}

.bfg-lead {
	margin: 0;
	font-weight: 700;
	font-size: 20px;
	line-height: 24px;
}

.bfg-cards {
	display: flex;
	flex-direction: column;
	gap: 16px;
	width: 100%;
	/* 86eypb6aw Figma-sync: Figma's "Cards Stack" frame is 800px wide
	   at the 1512 desktop anchor (34457:282320), not 720. */
	max-width: 800px;
}

.bfg-card {
	display: flex;
	align-items: center;
	justify-content: space-between;
	gap: 16px;
	padding: 24px;
	background-color: var(--bfg-white);
	border-radius: 8px;
	box-shadow: 0px 8px 16px 0px rgba(0, 0, 0, 0.1);
}

.bfg-card-content {
	display: flex;
	flex-direction: column;
	gap: 8px;
}

.bfg-card-tag {
	font-family: var(--bfg-heading-font);
	font-weight: 900;
	font-size: 12px;
	/* 86eypb6aw Figma-sync: was unset, so it inherited the theme's own
	   line-height (a unitless ratio that recomputes per font-size,
	   ~19.8px at 12px here) instead of Figma's tight 14.4px "Category
	   Label" leading (34457:282323, 12.0/14.40234375), which also
	   inflates every article card's height above Figma's 90px. */
	line-height: 14.4px;
	letter-spacing: 0.0833em;
	text-transform: uppercase;
	color: var(--bfg-green-text);
}

.bfg-card-title {
	margin: 0;
	font-size: 16px;
	line-height: 20px;
	font-weight: 400;
}

.bfg-card-title strong {
	font-weight: 700;
}

/* 86eypb6aw Figma-sync: Figma's "Icon Alignment Wrapper"
   (34457:282325) is a bare 24x24 box with no fill, border or radius --
   the 40x40 ring/circle this rule used to draw was never in the
   design. */
.bfg-card-arrow {
	flex: 0 0 auto;
	display: flex;
	width: 24px;
	height: 24px;
	align-items: center;
	justify-content: center;
}

.bfg-card-arrow img {
	width: 20px;
	height: 20px;
}

/* ---------------------------------------------------------------------
   Buttons. Default/hover/disabled fills come straight from Figma
   component set Button 29049:58925.
   --------------------------------------------------------------------- */
/* FIX (client-reported, 86eypb6aw, 2026-09-21): the outlined "Explore
   Bioactive Bites Supplements" CTA wrapped with runaway line spacing and
   dwarfed the green button beside it. The padding was never the cause. A
   fixed `height` on a flex container does not shrink to its content, it
   clips it, so once the label wrapped the second line rendered outside the
   48px box and the 16px padding stopped applying. Forcing the buttons to a
   240px width still reported height 48 with the text sitting outside.
   Measured live (btnfix.mjs, previous session): the label needs 326px of
   text in 328px of available space at desktop. It fits by two pixels, which
   is why it wraps on the client's screen and not on a headless render, and
   at 320/375 the button is only 292 to 335px wide so it always wraps.
     - `height` becomes `min-height`: a single-line button still measures
       exactly 48px, a wrapped one grows to roughly 55 to 64px with its
       padding intact.
     - `line-height: 26px` becomes `1.3`, about 15.6px at this 12px font,
       which is the gap between wrapped lines the client asked to reduce.
       Single-line vertical rhythm is unchanged because min-height still
       sets the box.
   The `padding: 16px` shorthand is deliberately left alone. Figma node
   34685:47233 specifies 12 vertical / 16 horizontal on this component and
   the existing comment on the outline variant citing it is accurate. */
.bfg-btn {
	display: inline-flex;
	align-items: center;
	justify-content: center;
	gap: 8px;
	min-height: 48px;
	padding: 16px;
	border-radius: 999px;
	font-family: var(--bfg-heading-font);
	font-weight: 900;
	font-size: 12px;
	line-height: 1.3;
	letter-spacing: 0.04em;
	text-transform: uppercase;
	border: none;
	cursor: pointer;
	/* FIX (live-verified 2026-09-21, 86eyxb3yt): this rule DOES match the
	   rendered element (unlike the .bhp-/.bcd-/.fc- cases fixed elsewhere in
	   this pass, where no rest-state transition existed at all), but its own
	   value was wrong -- 0.15s ease, not the contract's 300ms ease-out -- so
	   the near-duplicate 300ms declarations previously left on the :hover
	   rules below never actually governed anything; a rest-state transition
	   value is what a real browser uses. box-shadow added since
	   .bfg-btn--primary:hover changes it. */
	transition: background-color 300ms ease-out, border-color 300ms ease-out, color 300ms ease-out, box-shadow 300ms ease-out;
}

/* Kind=Secondary: the two solid CTAs ("Explore the health hub",
   "Shop Superfoods & Ancient Grains"). */
.bfg-btn--primary {
	background-color: var(--bfg-green-text);
	color: var(--bfg-white);
	box-shadow: 0px 4px 6px -2px rgba(0, 0, 0, 0.03), 0px 12px 16px -4px rgba(0, 0, 0, 0.08);
}

.bfg-btn--primary:hover {
	/* source:FIGMA -- Button Secondary/Large hover (hover-type-contract.md L41): bg green ->
	   gold, text white -> dark ink (both already correct here), PLUS a 1.5px #B86E00 border
	   added and the default shadow removed at Large size (Small gets no border, per contract's
	   Secondary/Small vs /Large distinction) -- neither was implemented before this pass.
	   Dark ink on gold = 8.72:1 (WCAG AA, computed above on the search-panel Secondary/Small
	   fix). Color/shadow only. CORRECTION (86eyxb3yt, live-measured): the earlier
	   `border: 1.5px solid` here DID reflow (default is border:none, so hover grew the
	   button 48x238 -> 50x240 in chromium + webkit at every width, against the CWV no-reflow
	   rule). The 1.5px #B86E00 ring is now an inset box-shadow: same ring painted inside
	   the box, no layout space. */
	background-color: var(--bfg-yellow);
	color: var(--bfg-ink);
	box-shadow: inset 0 0 0 1.5px #B86E00;
	/* transition moved to the .bfg-btn rest-state rule above -- see its
	   FIX comment. Declaring it here too was dead weight: the rest-state
	   value is what a real browser uses. */
}

/* 86eypb6aw Figma-sync: `.bfg-footer a { color: inherit }` above is
   (0,1,1) specificity, which beats this rule's own un-scoped
   `.bfg-btn--primary { color: var(--bfg-white) }` (0,1,0), so the CTA
   text was silently rendering ink-on-green (1.46:1, axe-flagged
   "serious" color-contrast) on every primary button that is an <a>,
   not a <button>. Re-scoped under .bfg-footer to win on specificity
   without touching the shared .bfg-footer a rule itself. White on the
   button's #247B4E fill is 5.23:1, passes AA. */
.bfg-footer .bfg-btn--primary {
	color: var(--bfg-white);
}

.bfg-footer .bfg-btn--primary:hover {
	color: var(--bfg-ink);
}

.bfg-btn--primary[aria-disabled="true"] {
	background-color: var(--bfg-green-text);
	opacity: 0.6;
	cursor: not-allowed;
}

/* Kind=Outline: "Explore Bioactive Bites Supplements" on the amber band.
   Figma instance override uses the band's ink colour for the default
   border/text (not the component's default green), matching #34685:47233. */
.bfg-btn--outline {
	background-color: transparent;
	border: 1px solid var(--bfg-ink);
	color: var(--bfg-ink);
	/* 86eypb6aw Figma-sync: Figma's outline button instance
	   (34685:47233) overrides the shared Button component's own
	   weight/padding -- 800 (not the component default 900 the base
	   .bfg-btn rule above sets) and 12px top/bottom x 16px sides (not
	   the uniform 16px .bfg-btn padding). */
	font-weight: 800;
	padding: 12px 16px;
}

.bfg-btn--outline:hover {
	/* source:FIGMA -- Button Outline/Large hover (hover-type-contract.md L43): "Only the
	   background fills in; border and text hold" -- unchanged from Default. The previous
	   border-color/color shift to --bfg-green had no contract backing and contradicted this:
	   this instance's own Default already overrides the component's default green to ink
	   (34685:47233, comment above), so "hold" means stay ink, not shift to a different green
	   than either state ever specified. Background-only change, no reflow. Ink on white =
	   14.18:1 (already established elsewhere in this file, unchanged value). */
	background-color: var(--bfg-white);
	/* transition already covers background-color via the shared .bfg-btn
	   rest-state rule above (.bfg-btn--outline inherits its base class) --
	   see that rule's FIX comment. */
}

.bfg-btn--outline[aria-disabled="true"] {
	background-color: var(--bfg-white);
	border-color: var(--bfg-green);
	opacity: 0.6;
	cursor: not-allowed;
}

.bfg-btn--block {
	width: 100%;
}

/* ---------------------------------------------------------------------
   Bands 2 and 4, image strips (#34457:282305 / #34457:282313). Both
   Figma nodes reuse the same template (EL-3eee4d10) and the same
   imageRef, so one photo, used twice, is correct here, not a bug.

   86eypb6aw Figma-sync: the Media-Library `image-strip.png` this band
   used to reference was NOT the Figma export -- 1959x120 (16.3:1) vs
   Figma's actual 3024x259 (11.68:1) render of imageRef
   3c7a107e18daf6049c0fd2fcb44749784c8cc175. With object-fit:cover at
   this band's ~11.4:1 rendered aspect, the wrong asset's much wider
   native ratio forced extra vertical cropping, flattening/losing the
   torn-edge grass-tuft detail visible in the correct export. Swapped
   to a new `image-strip-v2.png` Media Library upload (exact Figma
   export, imported via `wp media import`, see
   bonza_footer_asset_url()) instead of overwriting the old Media
   Library file in place.
   --------------------------------------------------------------------- */
/* 86eypb6aw Figma-sync: the two fixed heights this used to carry
   (126.58px above 690px, 36.61px below) do not track viewport width,
   so the strip drifted from Figma's true ratio (rectangle
   34457:282305 is width/11.69 at every anchor) by as much as -92px at
   2560 and +61px at 768 (768 was cropping to only the middle ~52% of
   the texture). aspect-ratio locks the same 11.69:1 ratio at every
   width instead of two guessed breakpoints. */
.bfg-image-strip {
	display: block;
	width: 100%;
	height: auto;
	aspect-ratio: 1920 / 164;
	object-fit: cover;
}

/* 86eypb6aw Figma-sync (post-close residual): image-strip-v2.png's own
   last pixel row (y:163 of 164) carries alpha 198, not 255 like every
   other row -- confirmed by sampling the live file directly, not a
   guess. Wherever that row lands, it partially shows whatever is
   BEHIND the img's own box rather than the flat amber fill the rest of
   the image carries. The img sitting immediately before .bfg-band--signup
   has .bfg-footer's cream (#F8EDE3) behind it, so that one row reads as
   a thin cream seam right at the amber band's top edge -- exactly what
   was reported live, and confirmed NOT a DOM/layout gap
   (getBoundingClientRect() top/bottom values are pixel-identical
   between this img and .bfg-band--signup at every breakpoint checked).
   Backing this specific img with the same amber the row is supposed to
   be lets that translucent row blend into more of itself instead of
   into cream. The second .bfg-image-strip (after the signup band) does
   NOT get this override: its own neighbour below is .bfg-main, which is
   transparent and already falls through to the same cream .bfg-footer
   background the strip itself sits on, so its bottom row already blends
   into a matching color and shows no seam. (The second strip needed a
   different fix instead -- see .bfg-image-strip--post-signup below.) */
.bfg-image-strip--pre-signup {
	background-color: var(--bfg-amber);
}

/* 86eypb6aw Figma-sync (post-close residual, round 2): a real structural
   bug the seam fix above did not address, client-reported live as "the
   pattern is reversed". Root cause is a REAL rotation, not "no rotation
   field" as an earlier draft of this comment wrongly claimed -- the raw
   Figma node data does carry a relativeTransform per node, this file's
   first pass just didn't check for it. Node 34457:282305 (pre-signup)
   carries rotation -180deg with a determinant-negative transform
   ([[-1,0,1480],[0,1,872]]) -- i.e. Figma renders THAT instance as a
   horizontal mirror (scaleX(-1)) of the raw imageRef. Node 34457:282313
   (post-signup) carries ~0deg rotation but its own transform
   ([[1,0,0],[0,-1,1399.16]]) is a vertical mirror (scaleY(-1)) of the
   SAME raw imageRef. The two nodes are therefore both mirrors of the
   source image, in DIFFERENT axes, not "the second one flipped
   relative to the first". Confirmed by re-fetching both nodes' raw
   Figma JSON directly (not the earlier flattened MCP summary, which
   omits relativeTransform) and by comparing the two nodes' rendered PNG
   exports pixel-by-pixel against rotate180(post) vs vflip(post): RMS
   3.34 / 97.2% exact-pixel match for rotate180, vs RMS 31.01 / 90.1%
   for vflip -- rotate180 is the correct transform, not a plain
   scaleY(-1) as an earlier version of this fix shipped (that version
   moved the torn edge to the correct vertical side but left the
   silhouette horizontally mirrored to the wrong side: torn point at
   x=1008 instead of Figma's x=475/rotate180's x=473, a roughly 9px mean
   / 25px max column error across the strip). image-strip-v2.png, the
   asset actually deployed, is pixel-identical to node 34457:282305's
   (pre-signup's) own already-mirrored export, not to the raw imageRef
   -- so relative to the DEPLOYED asset, the post-signup instance needs
   a full 180-degree rotation to match Figma, which is exactly what a
   180-degree relative rotation between the two nodes' own transforms
   works out to. */
/* 86eypb6aw client feedback (9 Sep, follow-up): a thin seam reappeared
   right at THIS strip's own top edge, against the amber signup band
   above it -- the earlier pre-signup fix's own comment above reasoned
   this strip needed no background-color because "its bottom row
   already blends into cream," which is true of the RAW, unrotated
   image, but this strip carries `transform: rotate(180deg)` (see WHY
   above): rotation swaps which rendered edge carries the translucent
   last raw row -- after 180deg it lands on this strip's rendered TOP,
   sitting against amber, not its rendered bottom against cream. Same
   root cause as the pre-signup fix (image-strip-v2.png's own last row,
   alpha 198 not 255).
   FIRST attempt here shipped a flat `background-color: var(--bfg-amber)`
   across the whole box, mirroring the pre-signup fix literally -- an
   independent audit caught that this wipes out the torn-edge silhouette
   at small breakpoints (320px renders this strip at only ~27px tall,
   so the antialiased torn-edge pixels at the box's OTHER end are mostly
   semi-transparent from downscaling, and a flat background color shows
   solid amber through all of them instead of the intended jagged reveal
   down to cream). Confirmed by direct pixel comparison: before/after
   diffs were non-zero along the strip's rendered BOTTOM edge too, not
   just the seam this fix targets.
   Corrected to a `background-size:100% 3px; background-position:bottom`
   gradient patch instead of a full-box fill. `bottom` here is in this
   element's OWN pre-rotation coordinate space, which 180deg carries to
   the rendered TOP -- i.e. exactly the edge that needs patching -- while
   leaving every other pixel of the box (including the antialiased torn
   edge at the rendered bottom) fully transparent and untouched. 3px is
   comfortably larger than the single affected raw row at every
   breakpoint's scale factor, so it fully covers the seam without
   needing to compute the exact sub-pixel row height per breakpoint.
   Verified live via CSS injection at both extremes (320px and 2560px)
   before committing: seam gone at the top, torn-edge silhouette intact
   at the bottom, at both. */
/* 86eypb6aw client feedback (Elneil, 9 Sep, item 4, round 2): the seam is
   NOT fully closed by the 3px patch above -- reproduced live at 320/375
   (mobile breakpoint, where this strip renders at only ~27-32px tall):
   pixel-sampling the actual rendered PNG (parity-measure.js screenshot,
   home-320.png) shows the patch's own FIRST device row (the row nearest
   the box's true top edge, adjacent to .bfg-band--signup) render as
   #F8E9D7/#F9E7D3, ~92% cream + a sliver of amber, not solid amber like
   the 5 rows after it -- i.e. the rotated box's edge is snapping to a
   half-device-pixel boundary Chrome doesn't fully cover with a 3px
   background at this element's non-integer (27.33px/32.03px) height, at
   this element's specific DPR2 device-pixel grid. NOT present at 768/
   1024/1440/2560 (checked all four; only the expected single antialiased
   row at the box's true bottom edge, no anomalous row mid-patch), and NOT
   fixable by shifting the box (tested `margin-top:-1px` live, the same
   anomalous row still appears, just 1 row earlier -- confirms this is the
   patch's own edge-rendering, not a gap between elements).
   FIX, verified live via addStyleTag CSS injection + full-page screenshot
   + pixel-sampling at 375 before committing (same method the prior round
   used): doubling the patch to 6px closes the seam completely at 320/375
   (all rows sampled solid #FFA825, zero anomalous rows) with no visible
   change to the torn-edge silhouette at either end (6px is 2.4% of the
   247px desktop strip height, 22% of the 27px mobile strip height where
   the torn edge is already down to a handful of antialiased pixels per
   the original fix's own comment above -- confirmed by a side-by-side
   crop, no visible difference at that breakpoint's own scale). */
.bfg-image-strip--post-signup {
	transform: rotate(180deg);
	background-image: linear-gradient(var(--bfg-amber), var(--bfg-amber));
	background-size: 100% 6px;
	background-repeat: no-repeat;
	background-position: bottom;
}

/* ---------------------------------------------------------------------
   Band 3, amber sign-up band (#34685:47227)
   --------------------------------------------------------------------- */
.bfg-band--signup {
	display: flex;
	flex-direction: column;
	align-items: center;
	padding: 20px 64px;
	/* 86eypb6aw Figma-sync: same nested-frame situation as
	   .bfg-band--hub above -- Figma's real eyebrow/heading/actions
	   spacing (34685:47228) is gap:16, not the outer wrapper's 48
	   (which, again, has only one child so its own gap never renders).
	   Confirmed identical (16px) at every breakpoint's own frame. */
	gap: 16px;
	background-color: var(--bfg-amber);
	text-align: center;
}

/* editor-friendly-ok - @font-face registers a font resource, it targets no
 * block-editor content itself; the literal "Inter" name here is what every
 * font-face rule must use to bind the family name to a file (a CSS custom
 * property cannot appear inside @font-face). The rule that actually renders
 * this text, .bfg-band--signup .bfg-eyebrow below, uses the
 * var(--wp--preset--font-family--inter, "Inter", ...) pattern so the block
 * editor's Styles panel can still override it - same split used by
 * custom/css/fonts.css for Nominee/Kobe1.1 (ClickUp 86eyv0pqj, PR #740),
 * now merged to main alongside this fix (PR #741) -- this site has two
 * files following the same @font-face/preset-var pattern.
 *
 * FIX (CU-86eyv2c1y, header/footer font audit): this eyebrow declared
 * "Inter" with no @font-face anywhere in the build, so it silently fell
 * back to var(--theme-font-family) (Poppins) instead. Direct Figma node
 * inspection this pass (#34685:47229, the sign-up band's eyebrow text)
 * confirms Figma genuinely specifies Inter here -- fontFamily "Inter",
 * "Extra Bold", weight 800, 14px, uppercase, 0.02em letter-spacing --
 * not a stand-in for Nominee/Kobe1.1. Unlike those two, Inter is
 * SIL Open Font License, freely available via Google Fonts, so it is
 * registered below rather than left unresolved. Only the Extra Bold
 * (800) weight/latin subset was sourced -- the only cut this eyebrow
 * actually uses anywhere in this build.
 */
@font-face {
	font-family: "Inter";
	src: url("../fonts/inter/Inter-ExtraBold.woff2") format("woff2");
	font-weight: 800;
	font-style: normal;
	font-display: swap;
}

/* WHY ink, not the Figma-literal #FFFFFF: white on this band's #FFA825
   fill is ~1.93:1, the same WCAG 2.2 AA failure class as the
   copyright line above (both flagged in the ClickUp task as needing a
   fix, not an as-drawn build). Ink restores AA (~4.9:1). */
.bfg-band--signup .bfg-eyebrow {
	font-family: var( --wp--preset--font-family--inter, "Inter", var( --theme-font-family, sans-serif ) );
	font-weight: 800; /* overrides the base .bfg-eyebrow rule's 900 -- Figma #34685:47229's Extra Bold is 800 for this specific eyebrow */
	font-size: 14px; /* already 14px via the base .bfg-eyebrow rule above; redeclared here for locality, not a correction -- Figma #34685:47229 is also 14px, so this was never wrong */
	color: var(--bfg-ink);
}

.bfg-band--signup .bfg-h2 {
	color: var(--bfg-ink);
	/* 86eypb6aw Figma-sync: Figma's own text node
	   ('Start With the Gut.
Support the Whole Dog.', 34685:47230)
	   carries a hard line break, so the heading is meant to always
	   render as these exact two lines, not reflow at whatever width
	   its container happens to be. The theme_mod below now preserves a
	   real "\n" (textarea + sanitize_textarea_field, was a single-line
	   text field that stripped it), so this just needs to render it. */
	white-space: pre-line;
}

.bfg-signup-actions {
	display: flex;
	flex-direction: column;
	align-items: stretch;
	/* 86eypb6aw client feedback (ClickUp comment 90180253179219, 9 Sep):
	   "add spacing on the [two] buttons ... on mobile/desktop views."
	   Figma's own button-stack frame (34685:47231) uses gap:10px, which
	   this matched exactly -- confirmed via the Figma API's raw node
	   data, not just re-reading this file's own comment -- so this is a
	   deliberate client-requested departure from spec, not a Figma-
	   parity bug fix. Bumped to 16px for visibly more breathing room
	   without changing the 360px stack width or button sizing Figma
	   still governs. */
	gap: 16px;
	width: 100%;
	/* 86eypb6aw Figma-sync: Figma's button-stack frame (34685:47231) is
	   360px wide at every breakpoint (desktop/tablet/mobile all match). */
	max-width: 360px;
}

/* ---------------------------------------------------------------------
   Band 5, main footer (#34457:280279)
   --------------------------------------------------------------------- */
/* WHY .bfg-bottom is NOT nested inside .bfg-main: in the Figma tree
   "Container" (the bottom bar, #34457:280485) is a SIBLING of
   "bonza-footer" (#34457:280279, trust row + nav section), not a
   child of it. Keeping that same sibling relationship here means the
   64px horizontal padding declared once on .bfg-main is not applied a
   second time to the bottom bar (an earlier version nested
   .bfg-bottom inside .bfg-main and gave it its own 64px padding too,
   doubling the inset to 128px and, combined with .bfg-main's
   align-items:center shrink-wrapping an un-widened child, also
   breaking justify-content:space-between). */
.bfg-main {
	/* position:relative anchors .bfg-pattern-green (86eypb6aw Figma-sync,
	   see that rule below) -- Figma's decorative "green wide 1" rectangle
	   (I21316:76925;34457:280280) sits behind this band's trust badges +
	   nav columns, positioned with its own exact absolute x/y/w/h.

	   86eypb6aw Figma-sync (final parity pass): isolation:isolate is the
	   actual fix for the pattern being invisible at every breakpoint.
	   position:relative alone does NOT create a stacking context on its
	   own -- a positioned element only gets one once it also has a
	   non-auto z-index, or (as here) an explicit isolation. Without one,
	   .bfg-pattern-green's z-index:-1 escapes past this element straight
	   to the ROOT stacking context's negative-z layer, which paints
	   BEFORE .bfg-footer's own in-flow #F8EDE3 background, i.e. behind
	   it -- confirmed by pixel-sampling the live page (cream both
	   before and after this element boundary) and by injecting only
	   `isolation:isolate` in isolation, which alone flips the sampled
	   pixel to green.

	   NOT overflow:clip: an earlier version of this fix added it,
	   reasoning it would contain the pattern's horizontal spill once
	   max-width:none (see .bfg-pattern-green below) let the image
	   render at its real, wider-than-this-band Figma width. Verified
	   live that assumption was wrong on two counts: horizontal overflow
	   of an absolutely positioned child does not force a scrollbar or
	   otherwise need containing (it simply paints outside this box,
	   which is the correct, intended look here), and this element's own
	   `bottom:-208px` on the pattern (needed so the torn edge and the
	   solid fill below it reach down toward the bottom bar) is ALSO
	   vertical overflow of this same box -- overflow:clip was silently
	   clipping that intentional downward bleed too, leaving only a
	   ~39px sliver of the pattern's 247px height visible. Confirmed via
	   a live getBoundingClientRect() + computed-style check after the
	   isolation fix deployed: position/isolation were both correct, but
	   the visible render still showed no pattern until overflow:clip
	   was removed here. */
	position: relative;
	isolation: isolate;
	display: flex;
	flex-direction: column;
	align-items: stretch;
	gap: 56px;
	/* 86eypb6aw Figma-sync (residual fix): padding-bottom was 32px,
	   putting the bottom bar's top edge at nav-bottom + 32; Figma's
	   solid-fill edge (34457:280485's own y-offset within the band) is
	   nav-bottom + 40. */
	padding: 64px 64px 40px;
	/* Figma's footer component is authored at a fixed 1480px canvas
	   width (component #29399:99534, "designedWidth": "1480px"). Unlike
	   Band 1/Band 3 above, whose children each carry their own max-width
	   and stay naturally centered regardless of the band's width, this
	   band's nav columns use flex:1 1 auto and actively stretch to fill
	   whatever width they're given, so without a cap here they spread
	   far past Figma's intended proportions on very wide viewports.
	   WIDTH IS REQUIRED HERE, not just max-width: .bfg-footer is itself
	   flex-direction:column, so .bfg-main's inline axis is that flex's
	   CROSS axis. margin-inline:auto alone suppresses cross-axis stretch
	   (Flexbox L1 9.4 step 11: an "auto" cross margin means don't
	   stretch), leaving the band shrink-to-fit and only coincidentally
	   at 1480px whenever its content's max-content width happens to
	   exceed that. width:100% forces the intended cap to actually bind
	   regardless of content. */
	width: 100%;
	max-width: 1480px;
	margin-inline: auto;
}

/* Decorative "green wide 1" rectangle (I21316:76925;34457:280280),
   exact Figma absolute x/y/w/h relative to the bonza-footer frame's own
   top-left, which is the same reference point .bfg-main's padding box
   gives an absolutely-positioned child. z-index:-1 (not a DOM-order
   trick) is required: per the CSS stacking spec, a positioned element
   with z-index:auto still paints ABOVE non-positioned in-flow siblings
   regardless of source order, so only a negative z-index puts it behind
   the plain, non-positioned .bfg-trust-row / .bfg-nav-section content. */
.bfg-pattern-green {
	position: absolute;
	z-index: -1;
	pointer-events: none;
	/* 86eypb6aw Figma-sync (final parity pass): max-width:none overrides
	   the theme's global `img { max-width: 100% }` reset, which was
	   capping this image at .bfg-main's own width (1440/1480) instead
	   of letting it render at its real, wider Figma size -- the right
	   edge was landing ~11px short of Figma's, leaving a cream sliver.
	   top/left below are re-anchored from the BOTTOM of this band via
	   `bottom`, not a hardcoded `top`, because the live nav content
	   renders taller than Figma's own 384px nav frame once WP menu
	   items or real copy are in place; anchoring from the top with a
	   fixed offset would drift the torn edge upward through the nav
	   content as soon as that height differs even slightly from
	   whatever was measured at commit time. Anchoring from the bottom
	   edge of .bfg-main (which is fixed by this band's own
	   padding-bottom, not by variable content height) keeps the torn
	   edge locked to the same distance above the bottom bar regardless
	   of how tall the nav content ends up being. Values re-verified by
	   pixel-sampling the live render, not by copying Figma's raw
	   top/height numbers unchecked (see the WHY note on .bfg-main). */
	left: -11.24px;
	right: auto;
	top: auto;
	/* 86eypb6aw Figma-sync (round-5 residual fix): tuned when .bfg-main's
	   padding-bottom was 32px; now 40px, -200px re-closes an 8px gap
	   (pattern image top was landing at nav+0.7 instead of Figma's
	   nav-7.45). */
	bottom: -200px;
	width: 1552.86px;
	max-width: none;
	height: 247.32px;
	object-fit: cover;
}

/* 86eypb6aw client feedback (ClickUp comment 90180253179219, 9 Sep): "the
   torn-edge image green strip on desktop should [go] to the edge ...
   wider monitor it leaves a straight gap on left & right side." Measured
   live (getBoundingClientRect): the fixed 1552.86px width above -- Figma's
   own size for its 1480px canvas -- stops covering the viewport once it
   grows past ~1502px (the point where .bfg-main's centered 1480px cap no
   longer keeps this image's -11.24px/1552.86px box flush with both true
   edges); at 2560px it left 528px of cream on the left and 478px on the
   right. This was flagged as a known, deliberately out-of-scope gap in
   PR #734's own CHANGELOG entry ("pattern image full-bleed at 2560px+"),
   not a regression -- closing it now per this comment.
   left:50% + translateX(-50%) is relative to .bfg-main's own box, but
   .bfg-main is itself horizontally centered within the full-width
   .bfg-footer (no ancestor of #footer constrains it, confirmed via the
   live page's own markup), so this lands the image centered on the TRUE
   viewport too. width:100vw then reaches both true edges exactly the way
   .bfg-bottom-wrap's flat fill already does below it. Scoped to only the
   width past which the native 1552.86px box first falls short, so every
   narrower viewport -- already pixel-verified across 5 audit rounds --
   keeps that exact box, untouched. object-fit:cover on the fixed 247.32px
   height will upscale/crop more of the source PNG at very wide viewports,
   the same trade-off .bfg-image-strip already makes at width:100% two
   rules above. */
@media (min-width: 1503px) {
	.bfg-pattern-green {
		left: 50%;
		width: 100vw;
		transform: translateX(-50%);
	}
}

.bfg-trust-row {
	display: flex;
	flex-wrap: wrap;
	justify-content: center;
	/* 86eypb6aw Figma-sync (residual fix): Figma's "Review Copy Variant"
	   row (34457:280282) is align-items:flex-start, not center -- the
	   taller badges (B Corp 62px, TR[1]BE 59px) sit top-aligned against
	   the shorter 56px ones, not vertically centered among them. */
	align-items: flex-start;
	gap: 20px 40px;
}

.bfg-trust-row img {
	height: 56px;
	width: auto;
}

/* Dedicated class, not an alt-text selector: alt text is a translated
   string (WPML, five languages) and must never be relied on to select
   an element. */
.bfg-trust-row .bfg-badge--bcorp {
	height: 62px;
}

/* 86eypb6aw Figma-sync: Figma's own "admin-ajax (1) 2" frame
   (I21316:76925;35219:67607) for this badge is 132.19x59.06 at the
   1512 desktop anchor, not the 125x56 this badge's PHP width/height
   attributes and inherited .bfg-trust-row img height:56 used to
   render at. Dedicated class (not an nth-child/src selector) so this
   one badge can override the shared row's uniform height without
   touching the other four. */
/* 86eypb6aw (asset swap, team-lead's fix): the 132.19x59.06 above was
   the OLD composite raster's footprint -- icon+wordmark+count+"TREES
   PROTECTED" label stacked into one flat screenshot. The asset is now
   the real Figma vector for just the wordmark+icon row (node
   I21316:76925;35219:67608, confirmed via the pinned export's
   icons.json: 124x34, exported:true), a different, wider-per-height
   shape (3.65:1 vs the old composite's 2.24:1) -- 59px still would
   render this correctly per its OWN ratio (width:auto below computes
   from the real intrinsic 124x34), but at a much wider footprint
   (59*3.647=215px) than this row was ever budgeted for, especially at
   tablet (see the nowrap budget note a few dozen lines down). height
   here now matches the new asset's own native 34px at this desktop
   anchor, 1:1, the same "use the anchor's own pixels directly" rule
   this file applies everywhere else. */
.bfg-trust-row .bfg-badge--tr1be {
	height: 34px;
}

.bfg-nav-section {
	display: flex;
	flex-direction: row;
	gap: 40px;
}

.bfg-intro-col {
	display: flex;
	flex-direction: column;
	/* WHY not "justify-content: center" (Figma's own layout value for this
	   node): Figma's siblings there are all "hug" height so centering is a
	   no-op. In CSS the sibling nav columns are much taller (13-link
	   DISCOVER column) and flex's default align-items:stretch makes this
	   column match that height too, so centering here would sink the logo
	   and socials to the middle of the whole nav row instead of keeping
	   them level with the other columns' headings. */
	justify-content: flex-start;
	gap: 24px;
	/* 86eypb6aw Figma-sync: Figma's NavigationSection row has 5 equal
	   FILL columns (244.80px each at the 1512 anchor: intro/logo,
	   SHOP, DISCOVER, SUPPORT, CONTACT). flex:1 1 auto sizes each
	   column off its own content instead (basis:auto means "shrink
	   from the content's own hug-width"), which is why the 13-link
	   DISCOVER column and the address-heavy CONTACT column were
	   rendering far wider than the 3-link SHOP column. flex:1 1 0
	   (basis:0) makes every column grow from an equal zero baseline,
	   ignoring content width, so all 5 end up genuinely equal. */
	flex: 1 1 0;
	min-width: 0;
}

.bfg-logo img {
	width: 189px;
	height: 64px;
	/* The theme's global `img { max-width: 100%; height: auto }` reset
	   overrides an explicit width once this column's flex row is squeezed
	   by the wider DISCOVER/SUPPORT nav columns (max-width always wins
	   over width in the cascade). Figma fixes this logo frame at 189x64
	   regardless of its parent's width, so pin it here too. */
	max-width: none;
	flex-shrink: 0;
}

/* z8udzkavcj: the desktop row has 5 equal columns, and at 1025-1110px the
   logo column is narrower than 189px (147px at 1025), so the pinned logo ran
   into the SHOP heading. Let it overhang the 40px column gap by 24px at most,
   keeping 16px clear of SHOP; height:auto keeps the 189:64 ratio. From about
   1113px up the column is wide enough and the logo stays at Figma's 189x64. */
@media (min-width: 1025px) {
	.bfg-logo img {
		max-width: calc(100% + 24px);
		height: auto;
	}
}

.bfg-social {
	display: flex;
	gap: 16px;
}

.bfg-social a {
	display: flex;
	align-items: center;
	justify-content: center;
	width: 40px;
	height: 40px;
	border: 1.5px solid var(--bfg-green);
	border-radius: 20px;
}

/* NOT COVERED by hover-type-contract.md -- social icon circle isn't Button/Link/Selection/
   WISHLIST ICON/subscription (the only sets this contract resolved); left as-is, unverified
   against this contract. Border stays --bfg-green (1.5px, unchanged), only fill + icon color
   move -- no reflow. White icon on --bfg-green fill = 5.23:1 (already established elsewhere
   in this file for this exact color pair, unchanged value). */
.bfg-social a:hover {
	background-color: var(--bfg-green);
}

.bfg-social a:hover img {
	filter: brightness(0) invert(1);
}

.bfg-social img {
	width: 18px;
	height: 18px;
}

.bfg-nav-col,
.bfg-contact-col {
	/* 86eypb6aw Figma-sync: see the WHY note on .bfg-intro-col's own
	   flex above -- same fix, same reason, so all 5 nav-row columns
	   size equally regardless of how many links or how much address
	   copy any one of them holds. */
	flex: 1 1 0;
	min-width: 0;
	display: flex;
	flex-direction: column;
	gap: 16px;
}

.bfg-nav-col h3,
.bfg-contact-col h3 {
	font-size: 14px;
	line-height: 1.4; /* was 16px (1.14x), 86eypb6j8 */
	letter-spacing: 0.02em;
	color: var(--bfg-green-text);
}

.bfg-nav-col ul {
	display: flex;
	flex-direction: column;
	gap: 12px;
}

/* 86eypb6aw Figma-sync (residual fix): the <a>'s own line-height:16px
   below only sets the inline text box; the <li> itself still falls back
   to the theme's own default li line-height (26.4px unitless-ratio at
   this font-size), inflating each row's actual pitch to 38.4px and the
   whole column to 519px against Figma's 384px (16px rows, 28px pitch
   via the ul's 12px gap). Pin it on the li directly. */
.bfg-nav-col li {
	line-height: 1.4; /* was 16px (1.14x), 86eypb6j8 */
}

.bfg-nav-col a {
	font-weight: 700;
	font-size: 14px;
	line-height: 1.4; /* was 16px (1.14x), 86eypb6j8 */
}

.bfg-nav-col a:hover {
	/* NOT COVERED by hover-type-contract.md -- NAVIGATION/LINKS is MIXED classification in
	   the contract with no resolved color delta given for its CHILD variant (only that it's
	   a confirmed-usable Bonza variant, contract L24). This color/underline pair is unchanged
	   from its own prior live-verified audit trail (86eyv0k44, computed via CDP
	   CSS.getMatchedStylesForNode + forcePseudoState, see the block below), which is stronger
	   evidence than an unmeasured contract gap -- left as-is. color-only + underline, no
	   reflow. contrast-exempt: value unchanged from a prior pass's own measured/audited pair,
	   not newly introduced here. */
	color: var(--bfg-green-text);
	text-decoration: underline;
}

.bfg-contact-item {
	display: flex;
	flex-direction: column;
	gap: 4px;
}

.bfg-contact-item .bfg-contact-label {
	font-weight: 700;
	font-size: 14px;
	line-height: 1.4; /* >=1.2x, 86eypb6j8 */
	color: var(--bfg-green-text);
}

.bfg-contact-item .bfg-contact-value {
	font-weight: 700;
	font-size: 14px;
	line-height: 1.4; /* was 16px (1.14x); PR 1064 only covered a.bfg-contact-value, 86eypb6j8 */
}

/* 86eypb6ab: the phone, WhatsApp and email links wrap to two lines at 768px
   (the phone line is 32px tall), and Figma's 16px leading on 14px text is
   1.14x, too tight for wrapped lines. Deliberate deviation from Figma's
   16px (text node 34457:280446): 1.4x on the links only, the Support and
   Address spans keep Figma's 16px. Single-line links grow from 16px to 20px. */
.bfg-contact-item a.bfg-contact-value {
	line-height: 1.4;
}

/* 86eypb6aw client feedback (Vita, 10 Sep, item 3): "all links should be
   consistent when we do hovering which is green and underline." Audited
   every footer link's current cascade-winning rule before adding this
   (walked document.styleSheets live, confirmed via .matches()): .bfg-
   nav-col a:hover (line ~874 above) already sets var(--bfg-green-text) +
   underline and was the only footer link family with any :hover rule at
   all. The three REAL links in this column (tel:, wa.me, mailto: -- the
   two plain-text rows, Support and Our Address, are <span>, not <a>, per
   the live markup) had no :hover rule whatsoever, so hovering them did
   nothing. Matched to a.bfg-contact-value specifically (not the bare
   .bfg-contact-value class, which the two <span> rows also carry) so
   this never applies a link-style hover to non-interactive text.
   Scoped under .bfg-contact-item so its (0,3,1) specificity beats both
   the unscoped .bfg-footer a (0,1,1), the theme's own global a:hover
   (0,1,1, wp-content/themes/blocksy/static/bundle/main.min.css) and this
   file's own .bfg-contact-item .bfg-contact-value (0,2,0) base rule two
   lines up. Confirmed the win live via CDP CSS.getMatchedStylesForNode
   (this exact rule listed as the active color declaration) and via
   CSS.forcePseudoState + a settle wait for the theme's own color
   transition (an un-forced real hover samples mid-transition and looks
   like it failed; forcing the state and waiting ~400ms for the theme's
   transition to finish is what actually proves it): computed color goes
   ink rgb(46,42,42) -> rgb(36,123,78) (= --bfg-green-text) with
   text-decoration underline, on tel:, wa.me and mailto: alike; the two
   plain-text spans (Support, Our Address) are untouched, still
   rgb(46,42,42) / none, because they carry no `a.` in this selector. */
.bfg-contact-item a.bfg-contact-value:hover {
	/* NOT COVERED by hover-type-contract.md -- same basis as .bfg-nav-col a:hover above:
	   plain body-text link, no matching resolved delta in this contract. This exact pair is
	   already live-verified via CDP (see the block comment directly above), stronger evidence
	   than an unmeasured contract gap -- left as-is. color-only + underline, no reflow.
	   contrast-exempt: value unchanged from a prior pass's own measured/audited pair. */
	color: var(--bfg-green-text);
	text-decoration: underline;
}

/* 86eypb6aw Figma-sync, updated 10 Oct to the current homepage frames
   (36250:90632): the "Email" value is 16/700 like every other contact
   value. Its colour differs per frame: ink #2E2A2A at the 1512 desktop
   frame, green #247B4E (same as the labels) at the 744 and 428 frames,
   so green is the default and ink applies from 1025px up. */
.bfg-contact-item .bfg-contact-value[href^="mailto:"] {
	color: var(--bfg-green-text);
	font-weight: 700;
}

@media (min-width: 1025px) {
	.bfg-contact-item .bfg-contact-value[href^="mailto:"] {
		color: var(--bfg-ink);
	}
}

.bfg-contact-item .bfg-contact-vat {
	font-weight: 700;
	font-size: 14px;
	/* 86eypb6aw Figma-sync: Figma's VAT text node (34457:280459) sets
	   an explicit tight 14.91px leading; left unset here it was
	   inheriting the theme's own line-height ratio instead (~23.1px at
	   this font-size), which is a pure browser-fallback artifact, not
	   a real Figma value. */
	line-height: 1.4; /* was 14.91px (1.07x), 86eypb6j8 */
}

/* ---------------------------------------------------------------------
   Bottom bar (#34457:280485). Direct child of .bfg-footer, a sibling
   of .bfg-main (see the WHY note on .bfg-main above), so this is its
   only source of horizontal padding, not doubled on top of .bfg-main's.
   --------------------------------------------------------------------- */
/* WHY a solid green fill on the site-wide footer's bottom bar, not the
   cream band: the same #257E50 already used (and AA-audited at 5.03:1
   for white text) on the checkout footer variant
   (checkout-header-footer.css .bfg-footer--checkout). The old --bfg-ink
   copyright override two rules up was a documented stand-in for
   exactly this missing background (see that variable's own WHY
   comment) -- restoring the real background makes the Figma-literal
   white copyright text correct again, not a regression.
   Scoped to .bfg-bottom-wrap (a wrapper that exists ONLY around the
   site-wide footer's bottom bar, added by bonza_footer_render_global())
   rather than bare .bfg-bottom, because bonza_checkout_footer_render()
   reuses the bare .bfg-bottom/.bfg-copyright/.bfg-payment-row/
   .bfg-payment-icon classes directly with no such wrapper -- an
   unscoped rule here would also restyle the checkout footer, which is
   untouched by this task. */
.bfg-bottom-wrap {
	position: relative;
	/* 86eypb6aw Figma-sync: the fill now lives on this full-width
	   wrapper, not on .bfg-bottom (which stays capped at max-width:1480
	   for its CONTENT, matching every other band's content cap). Before,
	   the green was painted on the capped element itself, so at ultra
	   -wide viewports (2560+) cream showed on both sides of the bar
	   instead of the fill reaching the true edges the way Figma's FILL
	   -sized bands do. */
	background-color: var(--bfg-green);
}

/* 86eypb6aw Figma-sync (round-5 residual fix): the footer's bottom edge
   was landing at nav+140 vs Figma's nav+132 (an 8px gap below the
   copyright/payment row, invisible in normal use but reported by a
   zero-tolerance pass). Figma's frame has 28px below the icons, not
   .bfg-bottom's shared (checkout-footer-affecting) 36px -- override
   bottom padding only, scoped so the unscoped .bfg-bottom rule's 36px
   top stays and the checkout footer (no .bfg-bottom-wrap) is
   unaffected. */
.bfg-bottom-wrap .bfg-bottom {
	--bfg-copyright-color: var(--bfg-white);
	padding-bottom: 28px;
}

.bfg-bottom {
	position: relative;
	display: flex;
	align-items: center;
	justify-content: space-between;
	gap: 16px;
	width: 100%;
	max-width: 1480px;
	margin-inline: auto;
	box-sizing: border-box;
	/* 86eypb6aw Figma-sync (residual fix): 28px top put the copyright
	   text's vertical centre at nav-bottom + 66 against Figma's nav-
	   bottom + 82 (measured against 34457:280486); the extra 8px here
	   combines with .bfg-main's own +8px padding-bottom above to close
	   the gap. */
	padding: 36px 64px;
	flex-wrap: wrap;
}

.bfg-copyright {
	margin: 0;
	font-weight: 700;
	font-size: 14px;
	line-height: 1.4; /* >=1.2x, 86eypb6j8 */
	color: var(--bfg-copyright-color);
}

/* Agency credit link (z8udzkavcj). Same colour as the line (white on the green bar, 5.23:1),
   underlined so it reads as a link without relying on colour, visible focus ring. */
.bfg-copyright .bfg-copyright__credit {
	color: inherit;
	text-decoration: underline;
	text-decoration-thickness: 1px;
	text-underline-offset: 2px;
}

.bfg-copyright .bfg-copyright__credit:hover {
	color: inherit;
	text-decoration-thickness: 2px;
}

.bfg-copyright .bfg-copyright__credit:focus-visible {
	outline: 2px solid currentColor;
	outline-offset: 2px;
	border-radius: 2px;
}

/* ---------------------------------------------------------------------
   Payment marks row (2026-09-09, updated after the final Figma-parity
   audit): .bfg-payment-row is shared by both the checkout and
   site-wide footers. .bfg-payment (the original plain-text-pill class)
   is no longer used by either -- bonza_checkout_footer_render() was
   updated to call bonza_footer_payment_icons() and render
   .bfg-payment-icon marks too, matching the site-wide footer
   (86eypb6aw Figma-sync). .bfg-payment is kept, unmodified, only in
   case a future caller still needs the plain-text fallback; it is not
   currently rendered anywhere in custom.php.
   --------------------------------------------------------------------- */
.bfg-payment-row {
	display: flex;
	flex-wrap: wrap;
	justify-content: flex-end;
	align-items: center;
	gap: 4px;
}

.bfg-payment {
	display: inline-flex;
	align-items: center;
	justify-content: center;
	height: 28px;
	padding: 0 6px;
	min-width: 41px;
	border-radius: 4px;
	background-color: var(--bfg-white);
	color: var(--bfg-ink);
	font-size: 9px;
	font-weight: 700;
	line-height: 1;
	letter-spacing: 0.02em;
	text-transform: uppercase;
	white-space: nowrap;
}

/* Used by both the site-wide footer (bonza_footer_render_global()) and,
   since 2026-09-09, the checkout footer (bonza_checkout_footer_render())
   too. Each exported mark already carries its own white rounded-rect
   backing (baked into the SVG/PNG), so this is just a sizing box, no
   extra background. */
.bfg-payment-icon {
	display: inline-flex;
	align-items: center;
	justify-content: center;
	height: 28px;
}

.bfg-payment-icon img {
	display: block;
	width: auto;
	height: 28px;
	max-width: none;
	border-radius: 4px;
}

/* ---------------------------------------------------------------------
   Tablet, 744/768 (Figma "Tab 2" 17298:196546; Blocksy tablet range)
   --------------------------------------------------------------------- */
@media (max-width: 1024px) {
	/* 86eypb6aw Figma-sync: Figma's tablet hub-band frame (34457:287493)
	   is padding:24 on ALL sides, not just left/right -- top/bottom used
	   to fall through to the desktop rule's 64px unchanged. */
	.bfg-band--hub {
		padding: 24px;
		/* Same nested-frame pattern as the desktop gap fix above:
		   Figma's tablet inner content frame (34457:287494) is gap:24,
		   not the desktop-inherited 64. */
		gap: 24px;
	}

	/* 86eypb6aw parity audit (FT-02, 2026-09-14): explicit at <=1024 --
	   the desktop rule above now runs max-width:none, so without this
	   the tablet/mobile intro column would inherit that unconstrained
	   width too. Re-measured live before this change: it was never the
	   binding constraint at 744/428 (rendered 600px/388px, both under
	   the cap), so this keeps that identical, not a new value. */
	.bfg-hub-intro {
		max-width: 600px;
	}

	.bfg-band--signup {
		padding-left: 24px;
		padding-right: 24px;
	}

	/* 86eypb6aw Figma-sync: shared by both bands' <h2> -- Figma's tablet
	   "Go Deeper on the Science" (34457:287497) and "Start With the
	   Gut..." (34685:55582) headings are both 30/36 at this width, not
	   the desktop-inherited 36/40. */
	.bfg-h2 {
		font-size: 30px;
		line-height: 36px;
	}

	/* 86eypb6aw Figma-sync: Figma's tablet lead paragraph
	   (34457:287498) is 18/24, not the desktop-inherited 20/24. */
	.bfg-lead {
		font-size: 18px;
	}

	/* 86eypb6aw Figma-sync (residual fix): Figma's tablet article-card
	   title (34457:287501) is 14/20, not the desktop-inherited 16/20. */
	.bfg-card-title {
		font-size: 14px;
	}

	/* 86eypb6aw Figma-sync (round-3 residual fix): this still had the
	   pre-round-2 padding-bottom (32px), so the desktop .bfg-main
	   rule's padding-bottom:40px fix never reached tablet -- the bottom
	   bar landed 24px too high (nav+32 vs Figma's nav+56 at this
	   breakpoint). 56px matches the same "+8 beyond the plain nav gap"
	   relationship the desktop value uses, re-verified by pixel
	   sampling, not copied blind. */
	.bfg-main {
		padding: 64px 24px 56px;
	}

	/* 86eypb6aw Figma-sync: Figma's tablet trust row never wraps, but
	   the individual badges are also smaller here than at desktop
	   (Certified B 29x56, TR[1]BE 117.5x52.5, the other 3 all 32px
	   tall), not the desktop sizes this file used everywhere before
	   this rule existed. Without these overrides, nowrap alone just
	   pushed the row's (desktop-sized, ~871px of) content past the
	   696px content width, overflowing the B Corp badge off the left
	   edge of the viewport instead of fixing the wrap -- caught by
	   re-measuring getBoundingClientRect() live after deploying the
	   first version of this fix, not assumed from Figma's numbers
	   alone. With these sizes the row totals 458.5px of badges plus
	   4x40px gaps, 618.5px, comfortably inside 696px. */
	.bfg-trust-row {
		flex-wrap: nowrap;
	}

	.bfg-trust-row img {
		height: 32px;
	}

	.bfg-trust-row .bfg-badge--bcorp {
		height: 56px;
	}

	/* 86eypb6aw (asset swap): 52.5px was the OLD composite frame's
	   tablet height (117.5x52.5, same 2.24:1 ratio as the desktop
	   132.19x59.06 -- 52.5/59.06 = 0.8889, the same scale every other
	   trust badge uses tablet-vs-desktop). The new vector-only asset's
	   desktop anchor is 34px (see the base rule above), so applying
	   that identical 0.8889 scale gives 34*0.8889 = 30.22px here, not
	   a re-guess -- same method, new asset's own number. */
	.bfg-trust-row .bfg-badge--tr1be {
		height: 30.22px;
	}

	/* 86eypb6aw Figma-sync (final parity pass): Figma's tablet
	   NavigationSection (34457:283249) is a VERTICAL stack -- the
	   logo+socials frame on its own full-width row, then a SEPARATE
	   horizontal row of the 4 equal 144px nav/contact columns below it
	   (34457:283290, gap:40). The previous version of this file's own
	   comment ("Tab 2 keeps Shop/Discover/Support/logo in one unwrapped
	   row") was wrong -- re-checked directly against the Figma node
	   tree, not just eyeballed. Re-created here with flex-wrap instead
	   of a markup change: .bfg-intro-col is forced to its own full-width
	   line (flex-basis:100%), which pushes every following column onto
	   a second line where they share the remaining width equally. */
	.bfg-nav-section {
		flex-wrap: wrap;
		row-gap: 40px;
		column-gap: 40px;
	}

	.bfg-intro-col {
		flex: 1 1 100%;
	}

	/* 86eypb6aw Figma-sync (residual fix): this used to shrink the logo
	   to 140x48 at tablet -- Figma's logo frame (34457:283251, tablet
	   node 17298:196546) is 189x64 at every breakpoint down to mobile,
	   same as desktop, so this override was simply wrong. Removed; the
	   base (unscoped) .bfg-logo img rule's 189x64 + max-width:none now
	   applies here too. */

	.bfg-nav-col,
	.bfg-contact-col {
		flex: 1 1 144px;
		min-width: 0;
	}

	/* Figma tablet Container (34457:283370) is already column-stacked
	   (copyright above, payment row centered below, gap 12px) at 744px,
	   not just at the narrower mobile floor -- match that here instead
	   of only at the ≤690px breakpoint below. Scoped to .bfg-bottom-wrap
	   (site-wide footer only, see the WHY note on that class above) so
	   the checkout footer's own .bfg-bottom/.bfg-payment-row, which has
	   no such wrapper, is unaffected in the 691-1024px range. */
	/* 86eypb6aw Figma-sync (round-5 residual fix): footer bottom edge
	   was nav+160 vs Figma's nav+168 (mirror case of the desktop fix
	   above) -- Figma's tablet frame has 32px below the icons, not the
	   uniform 24px this used. */
	.bfg-bottom-wrap .bfg-bottom {
		flex-direction: column;
		align-items: center;
		gap: 12px;
		padding: 24px 24px 32px;
		text-align: center;
	}

	.bfg-bottom-wrap .bfg-payment-row {
		justify-content: center;
	}

	/* Figma tablet "green wide 1" (34457:283164). Anchored from the
	   bottom like the desktop rule above (see that WHY note) rather
	   than Figma's raw top offset, for the same reason: live nav
	   content height can differ from Figma's own assumption. -125px
	   keeps the same proportion of the image showing above .bfg-main's
	   bottom edge as the desktop rule (~24px of this image's 149px,
	   same ~16% ratio the desktop rule uses against its own 247.32px);
	   re-verified live, -59px was showing far too much of the image
	   and its torn edge cut across the last 2-3 lines of nav text. */
	/* 86eypb6aw Figma-sync (round-3 residual fix): re-offset to match
	   .bfg-main's padding-bottom moving from 32px to 56px above --
	   -101px keeps the same visible proportion of the image now that
	   the band's bottom edge sits 24px lower. */
	.bfg-pattern-green {
		left: -91px;
		top: auto;
		bottom: -120px;
		width: 935px;
		height: 149px;
	}
}

/* 86eypb6aw parity audit (measured with the fixed overflow harness, which
   reports each element's own left/right against the true viewport instead
   of conflating it with document.scrollWidth): this fixed 935px tablet
   pattern (left:-91px above) has a right edge at -91+935 = 844px. That
   comfortably overhangs the viewport (no gap) everywhere from 691px up to
   844px, but the ≤1024px tablet media query keeps using this SAME fixed
   935px box all the way up to 1024px -- past 844px it stops reaching the
   right edge at all, leaving a growing cream gap (180px wide at the
   bucket's own 1024px ceiling, measured live via getBoundingClientRect).
   This is the same class of defect as Elneil's item 5 (the desktop
   full-bleed fix a few hundred lines up), just at a different, previously
   unchecked width band. Same fix, reused: past the point the fixed box
   stops covering (845px, one px past 844), let it scale to 100vw instead,
   centered on the true viewport the same way the desktop ≥1503px rule
   already does. Scoped to stop at 1024px because the ≤1024px bucket ends
   there and the desktop rules (already verified gap-free at 1440/2560,
   see this same task's own earlier report) take over above it. */
@media (min-width: 845px) and (max-width: 1024px) {
	.bfg-pattern-green {
		left: 50%;
		width: 100vw;
		transform: translateX(-50%);
	}
}

/* ---------------------------------------------------------------------
   Mobile, Blocksy's real mobile breakpoint (NOT 768px), Figma "Mobile 2"
   17298:196807 drawn at 428, floor at 375.
   --------------------------------------------------------------------- */
@media (max-width: 690px) {
	.bfg-band--hub {
		padding: 20px;
		/* 86eypb6aw Figma-sync: Figma's mobile inner content frame
		   (34457:293313) is gap:20, not the desktop-inherited 64. */
		gap: 20px;
	}

	/* 86eypb6aw Figma-sync: Figma's mobile eyebrow (34457:293315,
	   'Keep Reading') is 12/16 ls:0.24, not the desktop-inherited
	   14/16 ls:0.28. Not scoped to .bfg-band--hub specifically --
	   .bfg-band--signup's own eyebrow already carries an identical
	   12px override a few lines below, so this is a safe, matching
	   value for both. */
	.bfg-eyebrow {
		font-size: 12px;
	}

	/* 86eypb6aw Figma-sync: Figma's mobile lead paragraph
	   (34457:293317) is 18/24, not the desktop-inherited 20/24. */
	.bfg-lead {
		font-size: 18px;
	}

	/* 86eypb6aw Figma-sync (residual fix): Figma's mobile article-card
	   title is 14/20, not the desktop-inherited 16/20 (same value as
	   the tablet override above). */
	.bfg-card-title {
		font-size: 14px;
	}

	.bfg-h2 {
		font-size: 24px;
		line-height: 32px;
	}

	.bfg-band--signup {
		padding: 20px;
	}

	.bfg-band--signup .bfg-eyebrow {
		font-size: 12px;
	}

	/* 86eypb6aw Figma-sync (round-3 residual fix): same bug as the
	   tablet override above -- this still had the pre-round-2
	   padding-bottom (32px), so the mobile bottom bar was 28px too high
	   (copyright nav+52 vs Figma nav+80, pattern top nav+11 vs
	   Figma nav+36). 62px re-closes the gap, re-verified by pixel
	   sampling. */
	.bfg-main {
		padding: 64px 20px 60px;
	}

	/* 86eypb6aw Figma-sync: Figma's mobile trust row (34457:288408) is
	   a compact 3-column layout -- col 1 the B Corp badge (spans both
	   rows), col 2 TR[1]BE stacked over 1% for the Planet, col 3 Trees
	   stacked over Rainforest Trust, 20px gap both axes -- not the
	   naive wrap onto 3 uneven flex rows this used to fall back to.
	   Targeted by position (nth-child) rather than adding wrapper
	   markup, since the 5 badges are always rendered in this same
	   fixed order by bonza_footer_render_global(). */
	.bfg-trust-row {
		display: grid;
		grid-template-columns: auto auto auto;
		grid-template-rows: auto auto;
		align-items: center;
		justify-content: center;
		column-gap: 20px;
		/* 86eypb6aw Figma-sync (residual fix): 20px here (matching the
		   column-gap) made the grid 116.5px tall (max(52.5,48) + 20 +
		   max(44,28)) against Figma's 104px mobile trust-row height
		   (34457:288408). Figma's actual row-gap within the stacked
		   pairs is 7.5px, giving 52.5 + 7.5 + 44 = 104. */
		row-gap: 7.5px;
	}

	.bfg-trust-row img {
		height: auto;
	}

	.bfg-trust-row .bfg-badge--bcorp {
		grid-column: 1;
		grid-row: 1 / span 2;
		height: 104px;
	}

	/* 86eypb6aw (asset swap): same 0.8889 scale as the tablet override
	   above, same reasoning -- 34px desktop anchor * 0.8889 = 30.22px,
	   not the old composite frame's 52.5px. Row1's natural max drops
	   from max(52.5,48)=52.5 to max(30.22,48)=48; bcorp's own
	   grid-row:1/span 2 still spans a fixed 104px total, so the grid's
	   span-track-growth step (CSS Grid sizing algorithm, not something
	   this rule has to compute by hand) distributes the remaining
	   ~4-5px across row1/row2 automatically -- align-items:center then
	   centers this badge inside whatever height that cell ends up at,
	   same as before. Reasoned through the spec rather than re-verified
	   live (no deploy access this session); flagging that plainly. */
	.bfg-trust-row .bfg-badge--tr1be {
		grid-column: 2;
		grid-row: 1;
		height: 30.22px;
	}

	.bfg-trust-row img:nth-child(3) {
		grid-column: 2;
		grid-row: 2;
		height: 44px;
	}

	.bfg-trust-row img:nth-child(4) {
		grid-column: 3;
		grid-row: 1;
		height: 48px;
	}

	.bfg-trust-row img:nth-child(5) {
		grid-column: 3;
		grid-row: 2;
		height: 28px;
	}

	/* 86eypb6aw Figma-sync: Figma's mobile NavigationSection stacks
	   every column full-width, so the flex-basis trick used at tablet
	   is not needed here -- a plain column direction already matches. */
	.bfg-nav-section {
		flex-direction: column;
		gap: 40px;
	}

	.bfg-nav-col,
	.bfg-contact-col {
		flex: 1 1 auto;
	}

	/* 86eypb6aw Figma-sync: Figma's mobile nav column headings/links
	   (e.g. 34457:288537 'SHOP') are 12/16 ls:0.24, not the
	   desktop-inherited 14/16 ls:0.28. The contact-column selectors
	   below repeat the ".bfg-contact-item" ancestor those base rules
	   use (footer.css, ~line 644) on purpose -- a bare ".bfg-contact-
	   label" here would be a lower-specificity (0,1,0) selector than
	   the base ".bfg-contact-item .bfg-contact-label" (0,2,0) it needs
	   to override, and specificity beats source order regardless of
	   which cascade layer/media query comes later. */
	.bfg-nav-col h3,
	.bfg-contact-col h3,
	.bfg-nav-col a,
	.bfg-contact-item .bfg-contact-label,
	.bfg-contact-item .bfg-contact-value,
	.bfg-contact-item .bfg-contact-vat {
		font-size: 12px;
	}

	/* Column stacking + centered payment row already set at the ≤1024px
	   tablet breakpoint above (Figma tablet Container is column-stacked
	   too); only the tighter side padding changes at this floor. Scoped
	   to .bfg-bottom-wrap (site-wide footer only) for the same reason as
	   the ≤1024px rule above -- the checkout footer's own bare
	   .bfg-bottom must not inherit this. */
	.bfg-bottom-wrap .bfg-bottom {
		padding: 20px;
	}

	/* Figma mobile "green wide 1" (34457:288409). Anchored from the
	   bottom like the desktop rule above (see that WHY note); -111px
	   keeps the same ~16% of the image showing above .bfg-main's
	   bottom edge as the desktop rule (proportional to this image's
	   own 132px height, see the matching note on the tablet rule
	   above). Re-verified live, -47px was cutting the torn edge across
	   the VAT line. */
	/* 86eypb6aw Figma-sync (round-3 residual fix): re-offset to match
	   .bfg-main's padding-bottom moving from 32px to 62px above. */
	/* 86eypb6aw parity audit (team-lead lead, fixed overflow harness):
	   -198px/829px is not an arbitrary guess -- checked the fresh pinned
	   export's index.json bbox for this same rectangle inside the actual
	   "Home Page - M" frame (whose own bbox is x:3904, width:428, i.e.
	   Figma's real 428px mobile anchor, not the page label's "425"):
	   the rectangle sits at x:3706, width:829 -- relative left
	   3706-3904 = -198, exactly this file's own -198/829. So Figma's OWN
	   design already overhangs its 428px mobile frame by 203px on the
	   right (631-428) and 198px on the left, at its native anchor width,
	   before this file ever touches it -- this was never a wrong number.
	   The harness now correctly flags real overflow at 320/375 (narrower
	   than Figma's 428 anchor, which has no Figma frame of its own to
	   copy) because this was a flat copy of the 428-anchor pixels across
	   the whole 320-690 bucket, so it does not shrink with the viewport
	   the way Figma's own design would once you cross below 428.
	   FIX: convert left/width to viewport-relative units, preserving
	   Figma's own ratio exactly (-198/428 = -46.2617%, 829/428 =
	   193.6916%) so at 428px this renders pixel-identical to before, and
	   below 428 it now scales down with the viewport instead of staying
	   flat. height/bottom are untouched on purpose -- object-fit:cover
	   already absorbs the width change the same way the desktop/tablet
	   full-bleed rules do elsewhere in this file, and the vertical anchor
	   here was tuned against live, variable-height nav content across
	   several prior rounds; re-deriving it was not needed for this fix
	   and changing it without being able to re-verify live would risk
	   that existing calibration for no reason.
	   RESIDUAL, stated plainly rather than hidden: because Figma's own
	   ratio overhangs its frame by design, this scaled version STILL
	   overhangs at every width below 428 (e.g. ~152px past the viewport
	   at 320, down from 311px before) -- it cannot reach zero measured
	   overflow while staying Figma-accurate, since Figma's own value
	   already exceeds its frame at the one width it actually specifies.
	   Confirmed harmless: position:absolute + pointer-events:none, and
	   scrollWidth==docWidth at 320 both before and after this change
	   (no scrollbar either way) -- this is a decorative bleed past the
	   edge, not a layout break. */
	.bfg-pattern-green {
		left: -46.2617%;
		top: auto;
		bottom: -108px;
		width: 193.6916%;
		height: 132px;
	}

	/* Figma mobile payment marks (17298:196807) are smaller than desktop:
	   standard marks are 29x20 (vs desktop's 41x28); width:auto scales
	   proportionally from this height. */
	.bfg-payment-icon img {
		height: 20px;
	}

	/* 86eypb6aw Figma-sync: Figma's mobile copyright line (34457:288616)
	   is 12/16, not the desktop-inherited 14/16 -- at 14px it was
	   wrapping to 2 lines instead of Figma's single line. */
	.bfg-copyright {
		font-size: 12px;
	}
}

/* hp3 (86eypb6m6 #9): Figma "Evidence-based articles..." (D 34457:282316 tree)
   is a 600px-wide centred text box (Kobe 700 20/24 => 3 lines at 1512; T/M are
   18/24 in the 600 / 388 column, already correct via the <=1024 rule). The
   intro column above runs the full 1384px band width so this lead stayed on
   one 1194px line. Cap only the lead, not the heading (which must stay on
   one line). */
.bfg-hub-intro .bfg-lead {
	max-width: 600px;
}

/* 86eypb6aw L1 map vs Figma footer: the footer button label is 12px with a 26px line-height
   (Button 29384:40264 etc.) inside a 48px box. Padding drops from 16px to 11px so the
   box stays 48px (11 + 26 + 11). */
.bfg-footer .bfg-btn {
	line-height: 26px;
	padding-top: 11px;
	padding-bottom: 11px;
}

/* 86eypb6aw footer rhythm per the current homepage frames (36250:90632, all three widths):
   body rows are 16px on 20px leading and headings sit on 16px leading, so the ul's 12px gap gives
   Figma's 32px link pitch everywhere. vertical-align:top stops the link's own font metrics
   adding 1px to the li line box in Chromium. */
.bfg-eyebrow {
	line-height: 16px;
}

.bfg-nav-col h3,
.bfg-contact-col h3 {
	line-height: 16px;
	white-space: nowrap; /* z8udzkavcj, see the hyphenation note below */
}

.bfg-nav-col li,
.bfg-nav-col a,
.bfg-contact-item .bfg-contact-label,
.bfg-contact-item .bfg-contact-value,
.bfg-contact-item a.bfg-contact-value,
.bfg-contact-item .bfg-contact-vat,
.bfg-copyright {
	line-height: 20px;
}

.bfg-nav-col a {
	vertical-align: top;
}

/* z8udzkavcj: the inherited overflow-wrap:break-word split long DE/NL words at any letter
   ("KUNDENSERVIC/E", "Geschäftsbedingunge/n") at 740-1100px. Headings stay on one line, as in
   Figma (Klantenservice overhangs its 147px column by 13px, still 26px clear of the next);
   long words in links and contact rows hyphenate instead, short ones are left whole. */
.bfg-nav-col a,
.bfg-contact-item .bfg-contact-label,
.bfg-contact-item .bfg-contact-value {
	-webkit-hyphens: auto;
	hyphens: auto;
	-webkit-hyphenate-limit-before: 5;
	-webkit-hyphenate-limit-after: 5;
	hyphenate-limit-chars: 12 5 5;
}

/* Outline CTA label is Nominee 400 in Figma (Button 29049:57897); only the 900 cut is loaded,
   so this changes the declared weight and the visual weight stays on the 900 face. */
.bfg-btn--outline {
	font-weight: 900; /* 86eyy8hud: Figma button labels are Nominee Heavy Extended, served 900 */
}

/* 86eypb6aw L1 map: two leftover height gaps against Figma, both measured live on v1 at 1440.
   - The outline CTA label is 326.2px wide on the loaded 900 face (Figma 326px at 400), and the
     button's 16px side padding left 326px, so it wrapped by 0.2px and the amber band grew 34px.
     Padding 10px 14px keeps the 48px box (10 + 26 + 10 + 2px border) and fits one line at 768 and up.
   - The bold lead-in inside the hub card title added 1px to its line box (21 vs the 20px leading),
     making every hub card 91.4px against Figma's 90px. */
.bfg-signup-actions .bfg-btn--outline {
	padding: 10px 14px;
}

.bfg-card-title strong {
	line-height: 1;
}

/* 86eypb6aw footer band CTAs: Figma keeps both buttons 48px tall. The labels are 12px (the WCAG
   floor) on the loaded Nominee 900 face; FR/ES/NL labels are 337-450px wide at that size, wider
   than the fixed 360px stack, so they wrapped to 2 lines at 26px leading (74px box).
   - 600px and up: the stack grows to the widest label (never below Figma's 360px, never past the
     row) and labels stay on one line, so both buttons stay equal width and 48px tall.
   - Under 600px: 320-375 (and FR/ES at 428) cannot fit one line at 12px (EN needs 356px, 320 gives
     280), so a wrapped label uses 16px leading and 6px padding: two lines still make the 48px box. */
.bfg-signup-actions .bfg-btn {
	line-height: 16px;
	padding-block: 6px;
}

@media (min-width: 600px) {
	.bfg-signup-actions {
		width: max-content;
		min-width: 360px;
		max-width: 100%;
	}

	.bfg-signup-actions .bfg-btn {
		white-space: nowrap;
		line-height: 26px;
		padding-block: 10px;
	}
}

/* 86eypb6aw round 3 (9 Oct sweep). editor-friendly-ok: footer chrome, no block surface.
   1. Signup band seam (Vita: "a .5 pixel showing" at the band bottom): when the
      band/strip boundary lands on a fractional y, Chromium antialiases the rotated
      strip's top row against cream, so a light line shows at 320-1515 in every
      language. The band now paints 2px of amber over that row; the strip's own top
      2px are amber already, so the torn silhouette is unchanged.
   2. Torn edge above ~2175px: object-fit:cover on the fixed 247.32px height
      cropped the torn top off and the last nav link sat on flat green. fill keeps
      the whole torn profile, stretched horizontally, at any width. */
.bfg-band--signup {
	position: relative;
	z-index: 1;
	box-shadow: 0 2px 0 var(--bfg-amber);
}

@media (min-width: 1503px) {
	.bfg-pattern-green {
		object-fit: fill;
	}
}

/* TR1BE counter badge (86eypb6aw round 3): Figma's footer layer is the OneTribe
   counter (wordmark, tree count, TREES PROTECTED, #247B4E), 124x49 at the 1512
   frame and 110 wide at 744 and 428. Only the counter variant; the wordmark-only
   fallback keeps the rules above. */
.bfg-trust-row .bfg-badge--tr1be-counter {
	width: 124px;
	height: 49px;
}

@media (max-width: 1024px) {
	.bfg-trust-row .bfg-badge--tr1be-counter {
		width: 110px;
		/* auto, not 43.5px: below ~400 the mobile trust grid's middle column is
		   narrower than 110 and img max-width:100% shrinks the width, so a fixed
		   height would squash the badge. The 124x49 attributes keep the ratio. */
		height: auto;
	}
}

/* G29: the TR1BE badge is wrapped in a link to the OneTribe profile. The
   anchor takes over the grid placement the img had as a direct child, and
   is line-height:0 so it adds no inline-baseline gap around the image. */
.bfg-trust-row .bfg-badge-link {
	display: inline-flex;
	line-height: 0;
	min-width: 0;
}

@media (max-width: 690px) {
	.bfg-trust-row .bfg-badge-link {
		grid-column: 2;
		grid-row: 1;
		align-self: center;
		justify-self: center;
	}
}

/* G38 (z8udzkgng4) 11px floor for block buttons on pages where hero-banner.css
   does not load (product page). Same values as the hero-banner.css rule. */
@media (max-width: 767px) {
	html body .bfg-btn--block {
		font-size: 11px;
		letter-spacing: 0;
		text-wrap: balance;
	}
}

/* z8udzkgngq M14 (QA 21 Oct): footer band CTAs on 320 to 341px phones. The band gives the button
   V - 40px; with 16px side padding the 11px English label (269px) needs 342px of viewport, so at 320
   it wrapped. 4px side padding keeps the label on one line from 318px up. Stays at the 11px floor.
   DE/FR/ES/NL labels are wider than any phone button and keep the balanced wrap.
   !important and the long selector beat hero-banner.css (home and category pages), which sets the
   G38 6px padding with !important at 767px and below; 6px leaves 268px, 1px short of the label. */
@media (max-width: 341px) {
	html body .bfg-signup-actions a.bfg-btn.bfg-btn--block {
		padding-left: 4px !important;
		padding-right: 4px !important;
	}
}

/* z8udzkgngq M14 (Glendon 23 Oct): the closing band button label stays on one line. ES and FR
   full labels need 352-363px against 288-328px at 360-412, so those two languages swap to a
   short label at 412px and below. The full label stays in the DOM, visually clipped, so the
   accessible name is unchanged. */
.bfg-btn__short {
	display: none;
}

@media (max-width: 412px) {
	.bfg-btn__short {
		display: inline;
	}

	.bfg-btn__long {
		position: absolute;
		width: 1px;
		height: 1px;
		overflow: hidden;
		clip-path: inset(50%);
		white-space: nowrap;
	}
}

/* z8udzkgnhc X8: article pages end with the Related Resources row only, so the
   shared "Go Deeper on the Science" hub band is skipped on single posts (all 5
   languages). Every other page keeps it (client-approved register row G4). */
body.single-post .bfg-footer .bfg-band--hub {
	display: none;
}