/*********************/
/* START :: Custom */
/*********************/
/*****************************/
/* START :: All Marquees */
/*****************************/
.scroller ul {
list-style: none;
}
.scroller,
.marquee {
max-width: 100%;
-webkit-transform: translate3d(0, 0, 0); /* bug fix: webkit flickering on mobile */
}
.scroller[data-animated="true"],
.marquee[data-animated="true"]{
overflow: hidden;
}
/* BB XL DESKTOP, and up */
@media screen and (min-width: 2000px) {
.marquee[data-animated="true"]{
-webkit-mask: linear-gradient(
90deg,
transparent,
white 10%,
white 90%,
transparent
);
mask: linear-gradient(
90deg,
transparent,
white 10%,
white 90%,
transparent
);
float: none;
margin-left: auto;
margin-right: auto;
max-width: 1234px;
}
}
.marquee > .fl-col-content {
-webkit-transform: translate3d(0, 0, 0); /* bug fix: webkit flickering on mobile */
align-items: center;
display: flex;
flex-direction: row;
flex-wrap: wrap;
gap: var(--scroll-gap);
padding: 0;
}
.marquee > .fl-col-content > div {
-webkit-transform: translate3d(0, 0, 0); /* bug fix: webkit flickering on mobile */
/* border: 3px solid trasparent; */ /* for debugging */
min-width: 200px;
min-height: 100px;
}
.marquee > .fl-col-content > div:first-child {
/* border: 3px solid rebeccapurple; */ /* for debugging */
}
.marquee > .fl-col-content > div:last-child {
/* border: 3px solid lime; */ /* for debugging */
}
/* restyle the marquee when motion is not activated */
body:not(.fl-builder-edit) .marquee[data-animated="false"] > .fl-col-content {
gap: 26px var(--scroll-gap);
justify-content: center;
}
body:not(.fl-builder-edit) .marquee[data-animated="true"] > .fl-col-content {
animation:
scroll
var(--_animation-duration, 60s)
var(--_animation-direction, forwards) linear infinite;
flex-wrap: nowrap;
width: max-content;
}
/* energy gradient in marquee bug fix */
body:not(.fl-builder-edit) .marquee.text > .fl-col-content:has(.fl-module-rich-text.energy-gradient) {
/* --scroll-gap: 0; */
display: flex !important;
}
body:not(.fl-builder-edit) .marquee {
--_animation-duration: 60s;
--_animation-direction: forwards;
}
body:not(.fl-builder-edit) .marquee.slow {
--_animation-duration: 140s;
}
body:not(.fl-builder-edit) .marquee.fast {
--_animation-duration: 40s;
}
body:not(.fl-builder-edit) .marquee.direction-right {
--_animation-direction: reverse;
}
body:not(.fl-builder-edit) .marquee.direction-left {
--_animation-direction: forwards;
}
@keyframes scroll {
to {
transform: translate(calc(-50% - calc(var(--scroll-gap, 0px)/2)));
}
}
body:not(.fl-builder-edit) .marquee[data-animated="loading"] > .fl-col-content {
flex-wrap: nowrap;
width: max-content;
}
@media (prefers-reduced-motion: reduce) {
/* restyle the marquee when motion is disabled */
.marquee > .fl-col-content {
gap: 26px var(--scroll-gap);
justify-content: center;
}
}
/* mobile */
@keyframes scrollmobile {
from {
transform: translate(26px);
}
to {
transform: translate(-50%);
}
}
/* mobile */
@media only screen and (max-width: 768px) {
body:not(.fl-builder-edit) .marquee[data-animated="true"] > .fl-col-content {
animation: scrollmobile
var(--_animation-duration, 20s)
var(--_animation-direction, forwards) linear infinite;
}
.marquee > .fl-col-content > div {
min-width: unset;
min-height: unset;
}
}
/*****************************/
/* START :: Logo Marquee */
/*****************************/
.row--logo-ticker > .fl-row-content-wrap {
padding-block: 24px;
}
.marquee.logos {
--scroll-gap: 200px;
}
.marquee.logos .fl-photo img {
border-radius: 0;
box-shadow: none;
}
body:not(.fl-builder-edit) .marquee[data-animated="loading"] > .fl-col-content .logo,
body:not(.fl-builder-edit) .marquee[data-animated="loading"] > .fl-col-content .logo img {
min-width: 120px;
}
.logo img {
border-radius: 0;
box-shadow: none;
height: 130px !important;
max-width: unset !important;
width: auto !important;
}
.marquee.logos > .fl-col-content > div {
-webkit-transform: translate3d(0, 0, 0);
min-width: 180px;
min-height: 130px;
}
/* mobile */
@media only screen and (max-width: 768px) {
body:not(.fl-builder-edit) .marquee.logos {
/* increase speed on mobile */
--_animation-duration: 20s;
--_animation-direction: forwards;
/* decrease gap between logos */
--scroll-gap: 50px;
}
.marquee.logos > .fl-col-content > div,
.marquee.logos .fl-photo img {
height: auto !important;
max-width: 50vw !important;
min-height: unset;
min-width: unset;
width: 50vw !important;
}
}
/***************************/
/* END :: Logo Marquee */
/***************************/
/**********************************/
/* START :: Testimonial Marquee */
/**********************************/
.maxwidth1366{
max-width: 1366px;
margin: 0 auto;
float: unset;
}
.marquee.testimonial {
--scroll-gap: 31px;
}
.marquee.testimonial .marquee-item {
width: 370px;
height: 475px;
}
.marquee.testimonial .marquee-item .small{
margin-top: auto;
}
body:not(.fl-builder-edit) .marquee.testimonial figure.marquee-item{
border-radius: 24px;
overflow: hidden;
border: 0!important;
}
body:not(.fl-builder-edit) .marquee.testimonial figure.marquee-item div,
.marquee.testimonial figure.marquee-item img{
height:100%!important;
width: 100%!important;
object-fit: cover;
}
/* MOBILE */
@media only screen and (max-width: 768px) {
.marquee.testimonial {
--scroll-gap: 16px;
}
.marquee.testimonial .marquee-item{
width: 300px;
/* BugHerd 539 - 340px clipped the name/role lines on the Careers
testimonial cards (longest card needs 413.5px at 390w). Desktop
370x475 is untouched above. */
height: 420px;
}
body:not(.fl-builder-edit) .marquee.testimonial figure.marquee-item{
border-radius: 16px;
}
.marquee.testimonial .fl-rich-text.large p{
font-size: 18px;
font-size: 1.13rem;
font-style: normal;
font-weight: 400;
line-height: 29px;
line-height: 1.81rem;
}
}
/**********************************/
/* END :: Testimonial Marquee */
/**********************************/
/**************************/
/* START :: Ticker Text */
/**************************/
.footer .ticker-text {
margin: 0;
}
.footer .ticker-text p {
font-family: var(--font-headline);
font-size: 152px !important;
font-size: 9.5rem !important;
font-weight: 700 !important;
line-height: 1;
text-transform: uppercase;
white-space: nowrap;
}
body.fl-builder-edit .footer .ticker-text p {
white-space: normal;
}
.row--background-marquee .foreground {
position: relative;
}
body:not(.fl-builder-edit) .marquee.background {
position: absolute;
left:0;
right: 0;
z-index: 0;
}
body:not(.fl-builder-edit) .marquee.background > .fl-col-content {
width: max-content;
}
body:not(.fl-builder-edit) .marquee[data-animated="loading"] > .fl-col-content {
/* flex-wrap: nowrap;
width: max-content; */
}
/* MOBILE */
@keyframes scrollmobiletext {
from {
transform: translate(0);
}
to {
transform: translate(-50%);
}
}
@media only screen and (max-width: 768px) {
body:not(.fl-builder-edit) .marquee[data-animated="true"].text > .fl-col-content {
animation: scrollmobiletext
var(--_animation-duration, 18s)
var(--_animation-direction, forwards) linear infinite;
}
.ticker-text p {
font-size: 124px !important;
font-size: 7.75rem !important;
}
.footer .marquee {
--_animation-duration: 18s !important;
}
.footer .ticker-text p {
font-size: 72px !important;
font-size: 4.5rem !important;
font-weight: 450 !important;
}
}
/**************************/
/* END :: Ticker Text */
/**************************/
/********************************/
/* START :: Process Expansion */
/********************************/
.process-img,
.process-img .fl-module-content,
.process-img .fl-photo,
.process-img .fl-photo-content,
.process-img img,
.fl-post .process-img img{
object-fit: cover;
height: 710px;
width: 100%;
@media only screen and (max-width: 1366px) {
height: 640px;
}
@media only screen and (max-width: 992px) {
height: 480px;
}
/* BugHerd #511 - Brie: "Can we change the crop on mobile to be more square or vertical
please?" She is right, and desktop already does it. sustainable_transformation.webp is
natively PORTRAIT at 596x709 (0.841) and renders 601x710 at 1440, i.e. uncropped. The
fixed 260px height here forced that portrait photo into a 342x260 landscape box (1.315)
on a phone, cutting the top and bottom off.
Let each photo keep its OWN ratio rather than pinning one: height:auto on a width:100%
image renders it uncropped whatever its shape, so object-fit:cover becomes a no-op.
Do NOT hardcode 596/709 here. Ten of these rows span nine pages and two of the photos
are landscape - Meet-the-Team-1 (1.51) on /team/ and Careers-1 (1.47) on /careers/ -
so a pinned portrait ratio cropped 44% and 43% off their sides, worse than the 260px
box it replaced. Consequence to know: image heights now vary per photo instead of
sitting in a uniform 260px band. */
@media only screen and (max-width: 768px) {
aspect-ratio: auto;
height: auto;
}
}
.process-expansion-row .fl-accordion-button-icon{
display: none!important;
}
.process-expansion-row .fl-accordion-large .fl-accordion-button-label {
opacity: 0.5;
transition: 0.2s;
color:inherit;
}
.process-expansion-row .light .fl-accordion-button-label {
color:var(--white);
}
.process-expansion-row .fl-accordion-item {
padding-left: 20px;
background-image: linear-gradient(#FF855B 11.54%, #FFE35B 92.79%);
background-size: 2px 0%; background-repeat: no-repeat;
background-position: top left;
transition: all 0.5s ease;
}
.process-expansion-row .fl-accordion-item:last-child {
margin-bottom: 0px;
}
.process-expansion-row .fl-accordion-item-active{
animation: borderleft 0.2s 0.3s forwards;
}
@keyframes borderleft {
0% { background-size: 2px 0%; }
100% { background-size: 2px 100%; }
}
.fl-builder-content .process-expansion-row .fl-accordion-button a.fl-accordion-button-icon{
opacity: 1;
display: none;
}
/* BugHerd 519
The .fl-builder-content prefix is load-bearing. Beaver Builder's Label Text
Color field compiles to
".fl-builder-content .fl-node-ID .fl-accordion-button-label:hover", which is
(0,4,0); without the prefix these three selectors are (0,3,0) and lose, so an
opened panel kept the white hover colour on a touch device, where :hover
sticks after the tap. With the prefix they match at (0,4,0) and win on source
order, because custom.css is enqueued after the per-post BB cache file.
The .dark block directly below is also (0,4,0) and beats this one only by
sitting later in this same file. That is why this edit is made in place -
appending it to the end of custom.css would flip the careers accordion from
#AB5638 to --sun and reintroduce the contrast failure noted below. */
.fl-builder-content .process-expansion-row .fl-accordion-item-active .fl-accordion-button-label,
.fl-builder-content .process-expansion-row .fl-accordion-button-label:focus,
.fl-builder-content .process-expansion-row .fl-accordion-button-label:hover{
color:var(--sun);
opacity: 1;
}
/* The .dark accordion variant sits on the cream panel (#F6F2EF), not on navy.
#FF8054 measured 2.23:1 there, failing WCAG 2.0 AA (3:1 for large text -
these labels are 22.08px/700). Darkened along the same hue (15.4deg) and
saturation to 4.58:1, which clears both the large-text and normal-text
thresholds so it stays compliant if the type ever changes.
Only instance affected: the "A Culture Built to RISE" row on /who-we-are/careers/.
All nine other accordions use --sun on navy at 8.27:1 and are untouched. */
.process-expansion-row .dark .fl-accordion-item-active .fl-accordion-button-label,
.process-expansion-row .dark .fl-accordion-button-label:focus,
.process-expansion-row .dark .fl-accordion-button-label:hover{
color: #AB5638;
opacity: 1;
}
.process-expansion-row .fl-accordion-content > *{
font-family: var(--font-content);
font-size: 16px;
font-size: 1rem;
font-style: normal;
font-weight: 400;
line-height: 26px;
line-height: 1.63rem;
}
.acf-info-col .fl-col-content {
min-height: 720px;
}
@media screen and (max-width: 1366px) {
.acf-info-col .fl-col-content {
min-height: 640px;
}
}
@media screen and (max-width: 992px) {
.acf-info-col .fl-col-content {
min-height: unset;
}
}
/* OUR VALUES image swap - Mission, signed off at standup 16 Aug.
The section is the process-expansion pattern, which normally carries one image for the
whole block. Here each value has its own, so the column holds three photo modules and
the open accordion item decides which is visible.
They share a single grid cell rather than being absolutely positioned, so the column
still takes its height from the artwork and the .process-img sizing above keeps working
unchanged at every breakpoint - absolute positioning would have collapsed the column to
zero and needed its height hardcoding a fourth time.
The first image carries is-active from the layout data, so the section is correct before
any script runs and degrades to a normal single-image block if the JS never loads. */
.row--values-swap .column--values-images > .fl-col-content {
display: grid;
}
.row--values-swap .values-swap-img {
grid-area: 1 / 1;
opacity: 0;
transition: opacity 0.35s ease;
}
.row--values-swap .values-swap-img.is-active {
opacity: 1;
}
@media (prefers-reduced-motion: reduce) {
.row--values-swap .values-swap-img {
transition: none;
}
}
/* Below 768 the process-expansion pattern sets `display: contents` on its columns so the
section reflows as a flat stack. That dissolves the column box, so the grid cell above
does not exist and the three images fall into normal flow one under another - measured
as roughly 1670px of empty space held open by the two transparent ones.
Taking them out of flow instead keeps the stack correct without fighting that reflow.
The cross-fade is lost at this width, since two images can no longer overlap; a hard
swap is the right behaviour on a phone anyway. */
@media only screen and (max-width: 768px) {
.row--values-swap .values-swap-img {
display: none;
}
.row--values-swap .values-swap-img.is-active {
display: block;
opacity: 1;
}
}
/********************************/
/* END :: Process Expansion */
/********************************/
/**********************/
/* END :: Carousel */
/**********************/
/**********************************/
/* START :: Storytelling Feature */
/**********************************/
/* DESKTOP LARGE, and down */
@media screen and (max-width: 1366px) {
.column--storytelling-feature .card .clip-path--ellipsis {
gap: 16px;
}
}
/* TABLET, and down */
@media only screen and (max-width: 992px) {
.column--storytelling-feature .card {
flex-basis: unset !important;
}
.column--storytelling-feature .card .fl-module-heading {
margin-top: 0;
margin-bottom: 14px;
max-width: 300px;
}
.column--storytelling-feature .svg--sun-heart {
margin-top: 42px;
}
}
/* MOBILE, and down */
@media only screen and (max-width: 768px) {
.column--storytelling-feature .card {
padding-top: 68px;
}
.column--storytelling-feature .card .fl-module-heading {
margin-bottom: 28px;
max-width: 240px;
}
}
/**********************************/
/* END :: Storytelling Feature */
/**********************************/
/**************************************/
/* START :: Data Storytelling Columns */
/**************************************/
.row--data-storytelling-column .fl-col-group-equal-height {
--gap: 18px;
gap: var(--gap);
}
.row--data-storytelling-column .column--image,
.row--data-storytelling-column .column--card,
.row--data-storytelling-column .column--slider {
width: calc(33.33% - var(--gap));
}
.row--data-storytelling-column .column--image,
.row--data-storytelling-column .fl-col-group-equal-height > .fl-col:nth-child(2),
.row--data-storytelling-column .column--card,
.row--data-storytelling-column .column--slider {
width: calc(33.33% - var(--gap));
}
.row--data-storytelling-column .column--image,
.row--data-storytelling-column .fl-col-group-equal-height > .fl-col:nth-child(2),
.row--data-storytelling-column .column--image > .fl-col-content,
.row--data-storytelling-column .fl-col-group-equal-height > .fl-col:nth-child(2) > .fl-col-content {
border-radius: var(--border-radius-img);
overflow: hidden;
transform: translate3d(0, 0, 0);
}
.row--data-storytelling-column .column--image .fl-col-bg-video,
.row--data-storytelling-column .fl-col-group-equal-height > .fl-col:nth-child(2) .fl-col-bg-video,
.row--data-storytelling-column .column--image .fl-bg-video,
.row--data-storytelling-column .fl-col-group-equal-height > .fl-col:nth-child(2) .fl-bg-video,
.row--data-storytelling-column .column--image video,
.row--data-storytelling-column .fl-col-group-equal-height > .fl-col:nth-child(2) video,
.row--data-storytelling-column .column--image iframe,
.row--data-storytelling-column .fl-col-group-equal-height > .fl-col:nth-child(2) iframe {
border-radius: var(--border-radius-img);
overflow: hidden;
}
.row--data-storytelling-column .fl-photo-content,
.row--data-storytelling-column .fl-module-photo{
height:100%;
}
.row--data-storytelling-column .column--image img,
.row--data-storytelling-column .fl-col-group-equal-height > .fl-col:nth-child(2) img {
max-height: 467px;
height: 100%!important;
object-fit: cover;
}
.row--data-storytelling-column .column--card > .fl-col-content {
border-radius: var(--border-radius-img);
padding: 52px 36px 36px;
}
.row--data-storytelling-column .column--slider .fl-col-content,
.row--data-storytelling-column .column--slider .statistics_carousel,
.row--data-storytelling-column .column--slider .fl-module-content,
.row--data-storytelling-column .column--slider .fl-content-slider,
.row--data-storytelling-column .column--slider .bx-wrapper,
.row--data-storytelling-column .column--slider .bx-viewport {
height: 100%;
}
/* Desktop */
@media screen and (max-width: 1366px) {
.row--data-storytelling-column .column--image img {
height: 50vw;
}
.row--data-storytelling-column .column--slider {
width: 100% !important;
}
}
/* TABLET, and down */
@media only screen and (max-width: 992px) {
.row--data-storytelling-column .column--image,
.row--data-storytelling-column .column--card {
width: 100% !important;
}
.row--data-storytelling-column .column--card > .fl-col-content {
padding-top: 113px;
}
.column--slider > .fl-col-content {
margin-top: 0 !important;
}
}
/* mobile */
@media only screen and (max-width: 768px) {
.row--data-storytelling-column .fl-col-group-equal-height {
display: flex;
}
.row--data-storytelling-column .column--card > .fl-col-content {
padding-top: 36px;
}
/* BugHerd #512 - Brie asked for this section and the ones like it to read, on mobile:
section title, intro copy, IMAGE, then the dropdown titles and copy. Tia at Loop
confirmed on 9 Aug to do the reorder and disregard the Figma.
The photo lives in a SEPARATE COLUMN from the text, so the image cannot be placed
between the intro copy and the accordion while the column boxes exist. Dissolving the
two columns with display:contents makes all four modules siblings of one flex column,
which can then be ordered. Same technique already used for the phone carousel arrows
in components/carousel/carousel.css (tickets 429 / 431).
Ordered by MODULE TYPE, not position, on purpose: there are ten of these rows across
nine pages and the photo column comes first in five of them and second in the other
five, to alternate the layout on desktop. A position-based rule would reorder half of
them the wrong way round.
The columns carry no padding, margin or background of their own at this breakpoint, so
nothing is lost by dissolving them except the photo column's 36px bottom gap, which is
re-applied to the photo module below. */
.process-expansion-row > .fl-row-content-wrap > .fl-row-content > .fl-col-group {
display: flex;
flex-direction: column;
}
.process-expansion-row > .fl-row-content-wrap > .fl-row-content > .fl-col-group > .fl-col,
.process-expansion-row > .fl-row-content-wrap > .fl-row-content > .fl-col-group > .fl-col > .fl-col-content {
display: contents;
}
.process-expansion-row .fl-module-heading {
order: 1;
}
.process-expansion-row .fl-module-rich-text {
order: 2;
}
.process-expansion-row .fl-module-photo {
order: 3;
/* 36px both sides: the bottom half replaces the gap the photo column's content
wrapper used to provide, and the top half stops the image butting straight into
the intro copy, which it did at 0px once it moved between the two. 36px is the
spacing step this section already uses. */
margin-top: 36px;
margin-bottom: 36px;
}
.process-expansion-row .fl-module-accordion {
order: 4;
}
}
/********************************/
/* START :: Statistics Carousel */
/********************************/
.statistics_carousel .fl-content-slider .fl-slide-bg-photo {
/* BB core's content-slider responsive CSS sets this to position:static below 768px,
which drops the photo into normal flow and pushes the title/text out of the
fixed-height, overflow:hidden slide. Re-assert BB's own desktop values so the
photo stays behind the text at every width. No-op on desktop. (BugHerd 416,
417, 421, 425, 435, 446) */
position: absolute;
top: 0;
right: 0;
bottom: 0;
left: 0;
height: 100%;
margin: 0;
border-radius: var(--border-radius-img);
transform: scale(1.05);
/* BugHerd 163, 176 - the blur(3px) that used to sit here is removed.
The client reported these cards as blurry on two separate pages and
offered to re-supply the photography; the photography was never the
problem, the filter was. Legibility of the white stat and label does not
depend on it: the module paints its own rgba(0, 0, 0, 0.4) scrim on
.fl-slide-bg-photo::after, measured still present with the filter gone.
The scale(1.05) above is kept - it was there to hide the blurred edges
and is harmless without them. */
}
.statistics_carousel .fl-slide {
border:0 !important;
border-radius: var(--border-radius-img);
overflow: hidden;
width: 100% !important;
height: 100%;
}
.statistics_carousel .fl-slide-foreground {
height: 100%;
max-width:100%;
}
.statistics_carousel .fl-slide-content-wrap {
right: initial;
width: 100% !important;
padding: 26px 26px 80px;
top: initial;
text-align: center;
height: 100%;
display: flex;
align-items: center;
justify-content: center;
}
.statistics_carousel .fl-slide-foreground p {
font-family: var(--font-content);
margin-top: var(--Sizing-Units-XS);
text-align: center;
}
.statistics_carousel .fl-slide-title {
margin: 0!important;
font-family: var(--font-headline);
font-size: 90px;
font-size: 5.63rem;
font-style: normal;
font-weight: 500;
line-height: 100px;
line-height: 6.25rem;
}
.statistics_carousel .fl-slide-text {
margin-top: 26px;
}
.statistics_carousel .bx-controls {
position:absolute;
width: 100%;
}
.statistics_carousel .bx-wrapper {
max-width: 100% !important;
margin: 0;
}
.statistics_carousel .bx-wrapper .bx-pager {
padding: 0;
bottom: 50px;
}
.statistics_carousel .bx-wrapper .bx-pager.bx-default-pager a.active {
background:var(--sweet-water);
}
.statistics_carousel .bx-wrapper .bx-pager.bx-default-pager a:focus {
outline-width: 2px;
outline-style: auto;
outline-offset: 5px;
outline-color: var(--brand-focus);
}
.statistics_carousel .bx-wrapper .bx-pager.bx-default-pager a {
background: rgba(255, 255, 255, 0.26);
width: 60px;
}
.statistics_carousel .bx-viewport {border-radius:30px}
.statistics_carousel .fl-content-slider {
min-height:0!important;
min-width: 360px;
}
.statistics_carousel .slide-counter {
bottom: 14px;
color: var(--white);
font-family: var(--font-content);
font-size: 16px;
font-size: 1rem;
font-style: normal;
font-weight: 800;
left: 0;
line-height: 28px;
line-height: 1.75rem;
position: absolute;
text-align: center;
width: 100%;
right: 90px;
z-index: 9;
transition: all 0.25s linear;
}
.statistics_carousel .fl-slide-mobile-photo {
display:none;
}
/* TABLET, and down */
@media only screen and (max-width: 992px) {
.statistics_carousel .bx-viewport,
.statistics_carousel .fl-slide,
.statistics_carousel .fl-slide-foreground {
max-height: 310px !important;
}
.statistics_carousel_wrapper .statistics_carousel .fl-slide-title {
font-size: 66px;
font-size: 4.13rem;
line-height: 66px;
line-height: 4.13rem;
}
}
/* mobile */
@media only screen and (max-width: 768px) {
.statistics_carousel .fl-content-slider {
min-width: unset;
}
.statistics_carousel_wrapper .statistics_carousel .fl-slide-title {
font-size: 56px;
font-size: 3.5rem;
line-height: 60px;
line-height: 3.75rem;
}
.statistics_carousel_wrapper .statistics_carousel .fl-slide-text p {
font-size: 18px;
font-size: 1.13rem;
line-height: 26px;
line-height: 1.63rem;
}
.statistics_carousel .fl-slide {
border-radius: 20px;
}
.statistics_carousel .fl-content-slider .fl-slide-bg-photo {
border-radius: 20px;
}
.statistics_carousel .bx-viewport {
border-radius: 20px;
}
}
/********************************/
/* END :: Statistics Carousel */
/********************************/
/**************************************/
/* END :: Data Storytelling Columns */
/**************************************/
/*****************************************/
/* START :: Wedge row, glow clearance */
/*****************************************/
/* BugHerd 556, 562
The post-wedge row clips its content box with overflow:hidden, and the
See More Stories button sits flush against the top of it, so the hover glow
is sliced off along its top edge. 34px is not a chosen number: it is the blur
radius the glow already uses in .glow a:hover, so it is exactly the clearance
the effect needs and no more.
The negative margin cancels the padding, so nothing moves on the page: the
button keeps its position and only the clipping boundary shifts upward.
Applied by class rather than to .row--post-wedge generally, because that class
is on rows across several pages and only these two were reported. Add
row--wedge-glow-room to another row in Beaver Builder if the same clipping
turns up elsewhere. */
.row--wedge-glow-room > .fl-row-content-wrap > .fl-row-content {
padding-top: 34px;
margin-top: -34px;
}
/*****************************************/
/* END :: Wedge row, glow clearance */
/*****************************************/
/* BugHerd 527 / 580 - the Partner page testimonial cards run longer than the
Careers ones (longest needs 483px at 390w) and the client asked for
left-justified copy there. Scoped to the Partner layout so Careers keeps
the shared 420px above. */
@media only screen and (max-width: 768px) {
.fl-builder-content-2212 .marquee.testimonial .marquee-item {
height: 490px;
}
.fl-builder-content-2212 .marquee.testimonial .marquee-item p {
text-align: left;
}
/* BugHerd 507 - the Donate page stat card was capped at 310px tall and
read squat next to its 1.42 height/width desktop ratio. bx-slider sets
inline heights, hence the importants. Scoped to the Donate layout. */
.fl-builder-content-2161 .row--data-storytelling-column .column--slider .statistics_carousel .bx-viewport,
.fl-builder-content-2161 .row--data-storytelling-column .column--slider .statistics_carousel .fl-slide,
.fl-builder-content-2161 .row--data-storytelling-column .column--slider .statistics_carousel .fl-slide-foreground {
max-height: none !important;
height: calc((100vw - 48px) * 1.42) !important;
}
}
/* BugHerd 584 - iOS intermittently drops the background-clip:text layer on
the continuously-animated footer ticker, blanking the text for a frame or
two. Solid brand yellow on phones; the gradient stays everywhere else and
on all static energy-gradient headings. */
@media only screen and (max-width: 768px) {
.marquee.text .fl-module-rich-text.energy-gradient {
background: none !important;
-webkit-text-fill-color: currentColor;
color: var(--GivePower-Palette-Sun-Yellow) !important;
}
.marquee.text .energy-gradient p {
color: inherit !important;
}
}
/************************************************/
/* START :: 2026 page builds - Sizing Units S */
/************************************************/
/* Figma defines Sizing Units/S as 36px. Verified against the file's own variable
definitions on the Individual Impact page frame, not inferred from one usage.
style.css sets --Sizing-Units-S to 44px, the same value as --Sizing-Units-M,
which reads as S having been copied from M.
The token drives .fl-module-button margin-top and the p + p rhythm, so on these
layouts every button sits 8px lower than drawn and paragraphs run 8px loose.
The Figma is consistent about that button gap across sections:
Gear Up body ends 210 -> button 246 = 36
Hydrate body ends 178 -> button 214 = 36
Treks body ends 148 -> button 184 = 36
Corrected here rather than in style.css because the token is global and the rest
of the site is out of scope for this ticket. Worth raising separately: if the
value is fixed at source this block becomes redundant and should be deleted. */
.fl-builder-content-2943,
.fl-builder-content-2945 {
--Sizing-Units-S: 36px;
}
/* Recognized for Impact is the one section that departs from that. The Figma tightens
both of its gaps to 26 rather than 26-then-36:
heading h=186, body y=212 (gap 26), button y=298 (gap 26)
against Gear Up / Trek / Hydrate / Corporate Treks / Partner hero, which all sit at 36.
Re-scoping the token for this row alone keeps the value legible next to the others
instead of hard-coding a margin onto the button module.
Worth a second opinion from the design side: this may be deliberate for a tighter card,
or it may be a slip in the file. Built to match the Figma as drawn. */
.fl-builder-content-2943 .row--recognized {
--Sizing-Units-S: var(--Sizing-Units-XS);
}
/* Hero. The Figma sizes the three elements explicitly and the site's generic classes do
not match any of them:
heading box 635 (6025:18500) site: .maxwidth800 -> 800
description 519 (6025:18501) site: .maxwidth700 -> 700 via the wrapper box
donation form 519 (6025:18503) site: .html--donate -> 490 above 1367px
The description overrun is why the copy breaks a word later than the design: at 700 it
fits "...supporting our work ensures" on line one, at 519 it breaks after "our" as
drawn. The wrapper box is taken to 635 so it stops clipping the heading, and the
description is constrained separately.
The form width is only overridden above 1367px. Below that the component deliberately
drops to a 400px flex-basis to clear the heading, and that width is left alone. */
.fl-builder-content-2943 .row--hero-donate .row--hero-full--content {
max-width: 635px;
}
.fl-builder-content-2943 .row--hero-donate .fl-module-rich-text {
max-width: 519px;
}
@media only screen and (min-width: 1367px) {
.fl-builder-content-2943 .row--hero-donate .html--donate {
max-width: 519px;
}
}
/* The form is a flex sibling of the text box with a 75px gap, so its LEFT edge is
what the layout positions - taking the text box from 800 to 635 above therefore
dragged the form 65px left with it, and below 1367px (where the form is the
component's 400px and nothing else pinned it) its right edge stopped lining up
with the Donate button in the header. Measured at 1307px: form ended at 1150
against the button's 1219, while the live Donate page ended at 1215.
Anchoring the form to the right margin makes its position independent of the
heading width, which is how the Figma draws it - form right edge and Donate
button right edge both land on the page margin. */
.fl-builder-content-2943 .row--hero-donate .html--donate {
margin-left: auto;
}
/* Responsive pass 17 Aug (Leshan): "centre the form in the header - on most tablets it is
not centred."
The rule directly above is the cause, and it is right for what it was written for. At
993+ the hero is a flex ROW - copy left, form right - and `margin-left: auto` is what
anchors the form's right edge to the page margin so it lines up with the Donate button
in the header, independent of how wide the heading is.
At 992 and below the hero turns into a flex COLUMN and the copy centres itself on
align-items. The form does not, because an auto margin on a flex item beats align-items,
so the same declaration that anchors it correctly on desktop pins it to the right EDGE
once stacked. Measured, form box against its container:
vw 760 left gap 288 right gap 0
vw 820 left gap 348 right gap 0
vw 900 left gap 428 right gap 0
vw 977 left gap 505 right gap 0
- hard right at every tablet width, under centred copy. Restoring the right margin to
auto as well makes the pair split the free space and centre it.
Written as the pair rather than `margin-left: 0` - which would also work, by handing the
job back to align-items - because the two autos say "centre this" on their own, without
depending on a flex property set three files away in animation.css.
Bounded at 992 so the desktop anchoring above is untouched. Verified the form is not
height-clamped while stacked, which was the other thing to check: the component sets
flex-basis 400 / grow 0 / shrink 0 below 1367, and in a column that basis is the HEIGHT,
but flex items keep min-height:auto so it still takes its content's 575. */
@media only screen and (max-width: 992px) {
.fl-builder-content-2943 .row--hero-donate .html--donate {
margin-left: auto;
margin-right: auto;
}
}
/* Responsive pass 17 Aug (Leshan): "Gear Up and Trek - heads cut off on iPad, make sure
nobody's head is cut off."
Only happens once the sections STACK, at 768 and below. Above that the image sits beside
the text in a portrait box and the crop is horizontal, and the full height of both photos
is shown - checked by rendering the actual crops at 331x400 and 440x400, everyone intact.
At 993+ the box matches the file's aspect exactly and nothing is cropped at all.
Stacked, the box is pinned to 260 tall while its width grows to fill the column, so the
crop gets WORSE the wider the screen - which is why iPad Mini is the worst case rather
than the mildest:
768 box 705x260 301px of surplus 150 cut off the top
715 box 652x260 258px 129
615 box 552x260 179px 89
492 box 429x260 81px 40
At 50% 50% that surplus is split evenly, and 150px off the top of a 561px-tall picture is
what takes the girl's forehead and the woman's face off.
The two photographs need different values because they are composed differently - this is
art direction, not a shared constant. Measured as a fraction of each file's height:
gear up girl's hair 22% .. chin 61% = 39% tall
trek helmet 1% .. man's chin 53% = 52% tall
The window at 768 is 46% of the height. Gear Up's subject fits inside it with room, so 35%
centres her in it - verified by cropping the file to exactly what object-fit would show.
Trek does NOT fit: 52% of subject cannot go into a 46% window at any position, so
something is trimmed whatever we do. `top`, the obvious choice, is the wrong one - it cuts
the man's mouth and chin off. 15% keeps BOTH faces whole and spends the shortfall on the
crown of the woman's helmet and her raised arm, which is the least costly thing in the
frame. Confirmed by eye against the generated crop, not just the arithmetic.
If the helmet being clipped is ever raised, the fix is the box rather than the position:
705x320 fits the whole of both people at `top`, at the cost of 60px more height on every
stacked width. Left alone here because it changes a layout nobody complained about. */
@media only screen and (max-width: 768px) {
.fl-builder-content-2943 .row--text-2column-image-left .column--image img {
object-position: 50% 35%;
}
.fl-builder-content-2943 .row--text-2column-image-right .column--image img {
object-position: 50% 15%;
}
}
/* The overlap card component sizes its image from featured-card.css:
--overlap-img-height: 356px; --overlap-img-margin-block: 42px;
The Figma draws every overlap image on this page at 393 x 292 - the signup card
(6025:18614), Hydrate (6025:18762) and Recognized (6025:18603) all agree.
The margin follows from the same frame: Hydrate's card is 357 tall with the image at
y=32.5, and 292 + (32.5 * 2) = 357, which is exactly the min-height the component
derives from these two variables. So both values move together and the card height
lands on the drawn number rather than 64px over.
Re-scoped for this layout only - the same component is used elsewhere on the site and
those pages are out of scope. */
.fl-builder-content-2943 .row--feature-card-horizontal-overlap {
--overlap-img-height: 292px;
--overlap-img-margin-block: 32.5px;
}
/* Same component, same problem, different number on GivePartner. The Corporate Treks card
(6025:18194) is 327 tall with its 393 x 292 image at y 17.5, and 292 + (17.5 * 2) = 327,
which is exactly the min-height featured-card.css derives from these two variables. The
component's own 356 / 42 was producing 440 - measured, card y 2418..2857.
Note this is 17.5, not 2943's 32.5: the two frames draw the same card at different
heights, so the value has to come from THIS frame rather than be carried across. */
.fl-builder-content-2945 .row--corporate-treks.row--feature-card-horizontal-overlap {
--overlap-img-height: 292px;
--overlap-img-margin-block: 17.5px;
}
/************************************************/
/* END :: 2026 page builds - Sizing Units S */
/************************************************/
/**********************************/
/* START :: Make an Individual Impact */
/**********************************/
/* Line breaks. style.css sets text-wrap: balance on every heading level, which evens the
line lengths out instead of filling each line before wrapping. Figma fills greedily, so
the same string breaks in a different place:
balanced GEAR UP TO / GIVE BACK 320 / 290
greedy GEAR UP TO GIVE / BACK 470 / 150 <- as drawn
Measured, not assumed: the heading box renders 578 wide, exactly the Figma's 578, so the
container was never the problem. Same cause behind Recognized breaking at
"IMPACT. TRUSTED" rather than "IMPACT. TRUSTED FOR".
Reverting to normal wrapping on these layouts so the breaks land where they were drawn.
Note this is a deliberate site-wide typographic choice being overridden for these two
pages only - worth confirming the design side wants the drawn breaks over balanced ones. */
.fl-builder-content-2943 h1, .fl-builder-content-2943 .h1,
.fl-builder-content-2943 h2, .fl-builder-content-2943 .h2,
.fl-builder-content-2943 h3, .fl-builder-content-2943 .h3,
.fl-builder-content-2943 h4, .fl-builder-content-2943 .h4 {
text-wrap: wrap;
}
/* Gear Up and Trek centre their copy against the image. Figma: container 460 tall,
content 309 tall at y=75.5, and (460-309)/2 = 75.5 exactly.
The columns carry equal_height + content_alignment, so Beaver Builder prints
.fl-col-group-equal-height .fl-col-group-align-center and its own rule
.fl-col-group-equal-height.fl-col-group-align-center .fl-col-content
{ justify-content: center }
but that never takes effect here, because animation.css does:
.fl-col-content:has(.fl-module-heading.energy-gradient) { display: block; }
Both headings use energy-gradient, so the column stops being a flex container and
justify-content is inert. (Hydrate centres fine - its heading has no gradient.)
Flex is restored with align-items: flex-start, which keeps the gradient heading
shrink-to-fit exactly as display:block did. That matters: a stretched flex item
would spread background-clip:text across the full column and change the ramp.
Scoped to this layout and to the text column of these two rows only. */
.fl-builder-content-2943 .row--text-2column-image-left .column--text > .fl-col-content,
.fl-builder-content-2943 .row--text-2column-image-right .column--text > .fl-col-content {
display: flex;
flex-direction: column;
justify-content: center;
align-items: flex-start;
}
/* Donation page rebuild. The Join The Charge card leads with a yellow panel behind
its heading and intro copy before the signup form, per the Figma (6025:18613).
Painted by filling the whole card yellow and letting the form paint white back over
itself and everything below it, so the panel ENDS WHERE THE FORM BEGINS at every
width. The previous version was a fixed-height pseudo-element stepped 212 / 250 /
275 / 300px at 993 / 769 / 401, which only lines up at the widths those numbers were
measured at: an iPad Pro at 1024 took the desktop 212 and an iPad Mini at 768 took
275, and at both the copy had wrapped onto a different number of lines than the
height assumed, so the panel cut through the paragraph.
The 36 / 14 split below is the Figma's. Panel is 212 tall; content starts at 49,
heading 62, gap 9, body 56 = 176; form at 226. So 36px of yellow follows the
paragraph and 14px of white precedes the form. Desktop renders identically to
before - the panel still ends 212px down - it just is not a fixed number any more.
Double-scoped to this layout and to .row--join-charge, so no other overlap card on
the site is touched. Four classes (0,4,0) beats Beaver Builder's own column
background rule (0,2,0) and its responsive padding rules (0,3,0). */
.fl-builder-content-2943 .row--join-charge .column--text > .fl-col-content {
background-color: var(--GivePower-Palette-Sun-Yellow);
/* Clips the form's bleed to the card's corners. The radius is Beaver Builder's own
column setting - 24px, and 16px top-left below 769 - so clipping inherits it
instead of us restating it. The old panel restated it as --border-radius-img and
was 8px out on mobile as a result. */
overflow: hidden;
}
/* The white is the form module's own background rather than a backdrop behind it, so
there is no stacking order to get wrong - the module's content paints on top of its
own background for free.
The bleed is oversized on purpose: it has to clear the column's padding, which Beaver
Builder sets to 110px and steps to 36px at <=992 and 16px at <=768, and we should not
have to restate any of those. The bottom overhang carries the white down through the
card's bottom padding. Each padding is cancelled by an equal negative margin, so the
module's outer size is unchanged and neither the card's height nor its vertical
centring moves; overflow:hidden above trims the overhang to the card. */
.fl-builder-content-2943 .row--join-charge .newsletter-form {
background-color: #FFF;
/* Figma's 50px body -> form gap, split 36 yellow / 14 white. */
margin-top: 36px;
padding-top: 14px;
margin-left: -400px;
padding-left: 400px;
margin-right: -400px;
padding-right: 400px;
margin-bottom: -1000px;
padding-bottom: 1000px;
}
/* WPForms ships `div.wpforms-container-full { margin: 24px auto }`, which lands on top
of the 36 + 14 split above and makes the body -> form gap 74 where the Figma draws 50.
The split was already correct; it was being measured from the wrong place. Zeroing the
container's own margin is what makes the 50 above actually arrive, and the same 24 at
the bottom is what pushed the card's lower padding to 72 against a drawn 49.5.
Not a design value - a plugin default - so it is removed rather than compensated for. */
.fl-builder-content-2943 .row--join-charge div.wpforms-container-full {
/* `margin`, not just the two vertical sides: WPForms ships `margin: 24px auto`, and the
moment the max-width below starts binding, that `auto` would centre the form inside
the 762 copy measure. The Figma left-aligns it with the heading (6025:18621 sits at
x0 of Content), so the horizontal auto has to go along with the vertical 24. */
margin: 0;
/* The Figma insets the form on its RIGHT only - 724 inside a 762 copy measure. Widening
the column to 762 earlier correctly widened the heading and body and took the form
with it; this puts the form back without undoing that. max-width rather than width, so
it stops binding below 993 where the column is already narrower than 724. */
max-width: 724px;
}
/* Signup disclaimer (6025:18634). Lato Regular 14/28 in Ocean, 724 wide, sitting 16 below
the button - the same 16 that separates every other pair in this form.
No width is set on the paragraph beyond the measure: the Figma's 56px height is two lines
of 28, and which words land on which line has to come from the type and the 724 measure,
not from a hard break. A
here would look right at this width and wrong at every
other one. Verified as 2 lines by measurement rather than by eye. */
.fl-builder-content-2943 .row--join-charge .newsletter-form__disclaimer {
max-width: 724px;
margin: 16px 0 0;
font-family: var(--font-content);
font-size: 14px;
font-weight: 400;
line-height: 28px;
letter-spacing: 0;
color: var(--ocean);
text-align: left;
}
/* Field boxes. Figma draws the input at 56 (6025:18627 / 6025:18632); ours came out 63,
which is entirely padding: 16 + 16 around a 29px line box, plus 2px of border. Height
is set as well as the padding because the box is border-box here (confirmed - the input
fills its 358.5 column exactly at width:100% with 16px padding), so the declared height
is the outer height and the two agree instead of fighting.
Label copy stays with the in-house team; this is the box only. */
.fl-builder-content-2943 .row--join-charge div.wpforms-container-full .wpforms-form input[type="text"],
.fl-builder-content-2943 .row--join-charge div.wpforms-container-full .wpforms-form input[type="email"] {
/* The padding here lands without help but the height does not - measured, not assumed:
the first attempt set both and came back 55, which is 12 + 29 + 12 + 2px of border,
i.e. content-driven. Something in WPForms' own sheet pins it with !important, so this
one needs it too. Padding stays plain so it is obvious which half needed the hammer. */
height: 56px !important;
padding-top: 12px;
padding-bottom: 12px;
}
/* Revision 17 Aug (Leshan): the outline came back too dark - 1px, #C1BFBB, on this form and
on the GivePartner one.
This reverses the 16 Aug standup note ("make it a little thicker / darker, more visible"),
which had put these fields at 2px Ocean 0.55. #C1BFBB is the grey the theme already uses
elsewhere (news.css:480, style.css:240). Written as a literal rather than var(--Gray):
that token is referenced in style.css but never actually defined anywhere in the theme,
so every existing use of it is really relying on the hard-coded fallback.
Recording the trade, because it is a step back from where 16 Aug left it: #C1BFBB over
white is 1.8:1, under the 3:1 WCAG asks for the boundary of a control. That is a call
that was made, not an oversight - and it moves the build towards the frame rather than
away from it, since the drawn stroke on 6025:18627 is a near-white grey too.
border-width and border-color, NOT the `border` shorthand. This selector is (0,5,2) and
the theme's focus ring is (0,4,2), so a shorthand here would quietly take the focus
colour with it; the rule below keeps the focus ring at the restored width.
The width is a no-op against the base rule (form-divider.css:413 is already 1px) - kept
explicit because the ask named it, and so the pair reads as one setting rather than
leaving half of it to be inherited from another file. */
.fl-builder-content-2943 .row--join-charge div.wpforms-container-full .wpforms-form input[type="text"],
.fl-builder-content-2943 .row--join-charge div.wpforms-container-full .wpforms-form input[type="email"] {
border-width: 1px;
border-color: #C1BFBB;
}
.fl-builder-content-2943 .row--join-charge div.wpforms-container-full .wpforms-form input[type="text"]:focus-visible,
.fl-builder-content-2943 .row--join-charge div.wpforms-container-full .wpforms-form input[type="email"]:focus-visible {
border-color: var(--wpforms-button-background-color, var(--sweet-water));
}
/* Submit. Figma's Primary Button - Desktop is px-30 py-20 -> 63 tall (6025:18633), and it
sits 16 below the field row. Ours was 18px padding (59 tall) at a 26px gap.
The !important and the long selector are both earned, exactly as on 2945:
form-divider.css:730 html div.wpforms-container-full button[type=submit]
{ padding: 18px 30px !important } (0,2,3)
Matching !important alone does not move it - among !important declarations the more
specific selector still wins - so this one is (0,4,2). The margin needs neither. */
.fl-builder-content-2943 .row--join-charge div.wpforms-container-full button[type="submit"] {
padding-top: 20px !important;
padding-bottom: 20px !important;
margin-top: 16px;
}
/* Recognized card (6025:18524), drawn 1222 x 493 against ours at 499.58. Two causes, and
the larger one is not the button itself but the gap under it: a.fl-button is
inline-block, so its wrapper reserves a line box with room for descenders and measures
69.19 against the button's 64. Identical to the Trek card on 2945, and the same fix.
The remaining 1px is the text line box - Figma draws the button label at 23 and Lato at
`line-height: normal` gives 24 - so the label is set to the drawn 23 rather than left to
the font's default. Padding goes to the component's own 20/30, which also takes the
button to 204.75 against a drawn 204. Together: 499.58 -> 493. */
.fl-builder-content-2943 .row--recognized .fl-button-wrap .fl-button {
vertical-align: top;
/* inline-flex, not inline-block, so the button's own content box is the label's box
rather than a line box with descender space under it - the same fault as the wrapper
above, one level in. Without this the 20px padding below would ADD to a 28px content
box and make the button 68 where the Figma draws 63.
The padding needs !important because style.css:854 pins it:
.bolt a.fl-button { padding: var(--btn-padding-alt) !important } (0,2,1)
and --btn-padding-alt is `19px 28px 17px` - which is exactly the 19/28/17 measured
on this button, so that rule is confirmed as the one in charge rather than guessed
at. This selector is (0,4,1). Figma's component is px-30 py-20 (6025:18602), and the
30 is what takes the button to 204.75 against the drawn 204. */
display: inline-flex;
align-items: center;
justify-content: center;
padding: 20px 30px !important;
}
/* Both overlap cards draw their copy at 762 wide (6025:18617 and 6025:18598) and both
render at 737. The same 25px, but two different causes, so two different fixes - and in
each case the paddings are already right and must not be touched:
join-charge the panel is 899 and correct (Rectangle 2427, 6025:18616); the column
pads 110 / 52 where the Figma pads 110 / 27, so only the right is out.
recognized pads 36 / 126 already match the Figma exactly - it is the PANEL that is
899 against a drawn 924 (Main Content 6025:18597 spans 0..924 inside the
1222 card). Widening it gives 924 - 36 - 126 = 762 for free.
Desktop-only: below 993 the columns stack and Beaver Builder steps its own padding to 36
and then 16, and both a fixed 924 and a 27px inset would fight that. */
@media only screen and (min-width: 993px) {
.fl-builder-content-2943 .row--join-charge .column--text > .fl-col-content {
padding-right: 27px;
}
.fl-builder-content-2943 .row--recognized .column--text {
flex: 0 0 924px;
width: 924px;
max-width: 924px;
}
}
/**********************************/
/* END :: Make an Individual Impact */
/**********************************/
/****************************************/
/* START :: GivePartner rebuild - Built for Impact */
/****************************************/
/* The accordion in this section reads as a highlighted list rather than a standard
expander: the open item takes brand yellow with a yellow rule down its left edge,
the closed ones sit back at half strength, and there are no plus/minus icons.
Beaver Builder has no open-state label colour, hence the CSS. Scoped to this
layout and its row class so no other accordion on the site is affected. */
/* Worklist request: the testimonial carousel should stop while someone is reading it.
The marquee is a pure CSS animation on the column's content wrapper -
.marquee[data-animated="true"] > .fl-col-content
{ animation: scroll var(--_animation-duration, 60s) ... linear infinite }
- so pausing it is animation-play-state, with no JS and nothing for the scroller script
to fight over.
focus-within is in there deliberately: a keyboard user who tabs into a card would
otherwise have it scroll out from under them, which is worse than no pause at all.
Guarded on (hover: hover) so a touch device, where :hover sticks after a tap, does not
end up with a permanently frozen carousel.
Scoped to this layout AND to .testimonial - the same marquee component runs on other
pages and those are out of scope.
NB the SPEED half of the request is not applied: the ticket asks for a speed change but
names no target, and the Figma cannot draw duration. Current value is the component
default, --_animation-duration: 60s. Needs a number from Leshan. */
@media (hover: hover) {
.fl-builder-content-2945 .marquee.testimonial:hover > .fl-col-content,
.fl-builder-content-2945 .marquee.testimonial:focus-within > .fl-col-content {
animation-play-state: paused;
}
}
/* The hero scroll line's SVG was flipped in the page data so the horizontal now runs along
the TOP of its own box (see fix-2945-heroline.php). animation.css anchors the whole
column with `top: 0`, which was right while the horizontal sat at the BOTTOM of the box
but now pins it against the nav.
Both offsets are MEASURED off the 1:1 export (fig2945-hero.png, 1366 x 895), not read
off the picture - the first attempt used an eyeballed 45% and left the line 145px too
far right:
horizontal y 410 = 45.8% down the frame
vertical x 1193 = 87.3% across the frame
Percentages rather than px so the corner holds its place in the composition as the hero
flexes. right is 12.6%: the svg's vertical sits 1.5px inside its own right edge, so
1366 - 1193 - 1.5 = 171.5, and 171.5 / 1366 = 12.6%. */
.fl-builder-content-2945 .line--column--hero-left {
top: 45.84%;
/* Kept for BELOW 993 only, where it has always been and where the Figma frame says
nothing. The desktop block further down replaces it with a real anchor. Dropping it
outright would have handed the small breakpoints back to animation.css's
`right: 30px`, which is a change to tablet and phone that this ticket never asked
for - the frame is a single 1366 artboard. */
right: 13.53%;
}
/* ...and the horizontal offset is an ANCHOR, not a percentage. The percentage above was
measured correctly and still drifted at every width except the one it was read at,
which is the whole reason this rule exists separately.
In the frame the line does not sit "near" the copy, it BEGINS where the copy ENDS:
Content 6025:18424 x 69, w 707 -> right edge 776
Vector 12 6025:18456 x 776 -> left edge 776
Zero gap, exactly. A viewport percentage cannot express that, because the copy is a
fixed-width block pinned to the grid while the percentage tracks the window - so the
gap grows on every screen wider than the artboard. That is what was showing up as
"the yellow line should be closer".
Rebuilt from the grid instead. The row is Beaver Builder's fixed width (row_width 1366)
with the 72px desktop margin, so the copy's right edge is
half of any overflow past 1366 + 72 margin + 707 content
which is exact at every width from 993 up, and needs no breakpoint of its own.
Size and vertical placement were already right and are untouched - measured against the
export the line is 419 x 427 at y 410 in both, and only x was wrong (763 against 776).
The module has to be re-anchored too. animation.css pins it to the column's RIGHT edge
(`.line--column--hero-left .line--module { right: 0 }`), which suits a column positioned
by `right` but not one positioned by `left`: the module is absolutely positioned so it
gives the column no width, and the line's RIGHT edge landed on the anchor instead of its
left, putting the whole thing 419px too far over at x 360. Anchoring the module by its
left edge is also the truer statement of the design - the line begins here. */
@media only screen and (min-width: 993px) {
.fl-builder-content-2945 .line--column--hero-left {
right: auto;
left: calc(max(0px, (100% - 1366px) / 2) + 72px + 707px);
}
.fl-builder-content-2945 .line--column--hero-left .line--module {
right: auto;
left: 0;
}
}
/* Individual Impact's hero line sat 83px right of where it is drawn.
Layer 6025:18502 puts the vector's left edge at x 684 of 1366 = 50.07%, and
animation.css already anchors the column at left:50% - which is right to within a pixel.
The error was entirely the module's own `left: 74px` inside that column, so it is zeroed
rather than the 50% being re-tuned.
vertical x FIGMA 684 before 767 (-83)
box 121 x 405 was 123 x 238 -> rescaled in fix-2943-heroline.php,
vertical run now 322 against the drawn 324
Scoped to this layout: .line--column--hero-donate is shared with other pages. */
/* Revision 16 Aug (Leshan): "more padding between the hero and Every Dollar for Impact."
Figma frame 11548 (6025:18461), read with get_metadata:
hero 6025:18463 y 0 h 894.43 -> bottom 894.43
cards 6025:18504 y 963 padding-block 66 -> content starts 1029
drawn gap, hero bottom to cards content = 134.57
Measured on the page at 1425: hero bottom 699, cards content 765 = 66. So 69px short.
Tried as a Beaver Builder row setting first, per the standing instruction. It does not
work here and the attempt is worth recording: BB emitted
`.fl-node-ek34jzav5liw > .fl-row-content-wrap {padding-top:245px}` - specificity (0,2,0)
- and the page still rendered 176px, because the theme rule
`body:not(.fl-builder-edit) .clip-path--ellipse + .fl-row > .fl-row-content-wrap` is
(0,4,1) and wins. A builder field showing 245 while the page renders 176 is worse than
no field, so the setting was removed again.
Written as `calc(theme value + 69px)` rather than a flat number so the two custom
properties still do their work: --clip-path-margin compensates the hero's overlap and
--content-padding-block is the section rhythm, and both change per breakpoint. A fixed
px value would freeze that.
Desktop only. The Figma frame is the 1366 desktop board; tablet and phone spacing is a
live-site comparison we have not done yet, so they keep today's value. */
@media only screen and (min-width: 993px) {
body:not(.fl-builder-edit) .fl-builder-content-2943 .clip-path--ellipse + .fl-row > .fl-row-content-wrap {
padding-top: calc(var(--clip-path-margin) + var(--content-padding-block) + 69px);
}
}
/* The line now lives in the Every Dollar row, not the hero - see rev-2943-linemove.php for
why it had to. These three rules re-anchor it there; without them it would hang off the
wrong row's bottom edge.
The row has to be positioned for the absolute column to have anything to measure from -
it ships static - and the column is anchored from the TOP rather than the bottom, because
the Every Dollar row's height varies with its cards while the hero's did not.
-294 is not a guess and does not need a per-breakpoint variant. Both the line and the row
hang off the hero's bottom edge, so the offset between them is fixed: the SVG starts at
hero-bottom minus 404, this row starts at hero-bottom minus 110 (--clip-path-margin), and
the difference is 294 at every desktop width. Verified at 1440, 1300, 1200 and 1024, where
the SVG top measured 295/209/209/279 against row tops of 589/503/503/573.
z-index 2 is needed and is the one thing here that IS about stacking: the hero row sets
z-index 1 on itself, so anything in a later row paints underneath it, and the top of this
line is drawn over the hero. Both sit in the root stacking context - .fl-content is
position:relative with z-index auto, which does not create one - so 2 clears 1. */
.fl-builder-content-2943 .row--data-storytelling-column {
position: relative;
}
.fl-builder-content-2943 .line--column--hero-donate {
top: -294px;
bottom: auto;
/* 17 Aug (Leshan): "the yellow line is overlapping on top of the form - we need it to
go under it."
Correct, and it was this z-index that did it. Between 993 and 1366 the line's ink ends
EXACTLY on the form's left edge - animation.css positions it with
`right: calc(400px + var(--content-padding))`, so flush is the intended relationship,
not an accident - and that only reads properly while the form is painted on top. It
used to be: the line lived inside the hero, at z-index 0 against the form's 1.
Taking the line out of the hero for the clip lost that ordering, and the 2 needed to
clear the hero row put it above the form as well, because the hero row is a single
stacking context - it has BOTH z-index:1 and transform:translateZ(0), and either one
alone is enough - so everything inside it, form included, paints as one unit.
Dropping that context was tried and reverted - see the long note below - because it
is held up by the theme's anti-stutter fix. So the 2 stays: the line has to clear the
hero row, and it is kept off the form by position instead, in the same note. */
z-index: 2;
}
/* THE LINE CANNOT BE PUT UNDER THE FORM, and the reason is worth writing down because the
obvious fixes all look like they should work.
The form is `position: static`, so the `z-index: 1` animation.css gives it has never done
anything - z-index is ignored on an unpositioned element. The line column is `position:
absolute`, and a positioned element paints above static in-flow content whatever its
z-index. So the line has been over the form since long before it was moved; it only got
noticed once the line was lengthened and set to draw on scroll, which dragged a moving
yellow stroke across the form's corner.
Giving the form a position makes its z-index real, but that only helps if the two are in
the same stacking context, and they are not. The hero row is sealed by THREE separate
mechanisms, any one of which is enough:
z-index: 1 with position: relative
transform: translateZ(0) plus backface-visibility: hidden
isolation: isolate
and animation.css is explicit that the transform pair "stay: they were the original
anti-stutter fix" for BugHerd 346/347/33 - intermittent unpainted rectangles on exactly
these hero rows. Dismantling that to win a paint order is the wrong trade, so it was tried
and reverted rather than shipped.
That leaves the line either inside the hero (under the form, but clipped at the curved
edge and unable to reach the card) or outside it (reaching the card, but always on top).
It cannot be both. Since reaching the card is the requirement Leshan set first and twice,
the line stays outside and is instead kept clear of the form.
The clearance is cut out of the DRAWING rather than the position, on Leshan's suggestion,
and it is the better of the two. Between 993 and 1366 animation.css lands the line's box
right edge exactly on the form's left edge - `right: calc(400px + var(--content-padding))`,
the form's own width plus the page gutter - and that alignment is deliberate. Nudging the
box left to make room moved the VERTICAL run with it, which is the part the theme has
positioned on purpose. Trimming the path's top tip instead leaves the box, and so the
vertical, exactly where they were - see rev-2943-linetip.php.
THAT TRIM WAS THEN UNDONE, and the round trip is the useful part of this note. The tip went
119.5 -> 103.5 -> 101.5 chasing an overlap that kept surviving every cut, and the reason it
survived is that it was never where it was being measured. The probe injects a stand-in for
the script-loaded donate form, and it was hard-coded to 400px - correct BELOW 1367, but the
component is 519 above it. So every desktop reading placed the form's left edge 119px too
far right and reported clearance over a real 27.5px overlap. Trimming the path could not
reach it, because the overlap was at widths the trim was not being checked at.
Tip restored to 119.5. The fix belongs in the desktop position rule instead, and is one
number - see the min-width:1367 block below.
993-1366 was nearly right on its own: animation.css lands the line's box right edge on the
form's left edge with `right: calc(400px + var(--content-padding))`, and with the tip at
119.5 of a 121 box the ink arrives 1.5px short of it. The 3.5 below closes that and carries
on 2px, so both ranges meet the form the same way. */
@media only screen and (max-width: 1366px) {
.fl-builder-content-2943 .line--column--hero-donate .line--module {
right: calc(400px + var(--content-padding) - 7.5px);
}
}
/* 6px of contact rather than a butt joint, settled by eye with Leshan. Landing the ink exactly
on the form's edge still read as a hairline gap on screen - the stroke's last pixel is
antialiased against the white, and the form's corner radius pulls its edge away just above
the meeting point - so the line runs onto the form instead. It is the line that paints over
the form rather than the other way round, which the hero's stacking context settles for us,
and at this depth that is the right way round anyway.
THE TWO OFFSETS ARE A PAIR. The form is 519 wide at 1367+ and 400 below, so the same
contact needs a different number either side of that breakpoint. Move them together or the
two ranges stop matching:
1367+ left: -21.5px (this is -27.5 + 6)
993-1366 right: calc(400px + padding - 7.5px) (this is -1.5 + 6)
Both give 6px of overlap, verified at 1920, 1440, 1300 and 1024. To change the contact,
add the same delta to each. */
.fl-builder-content-2943 .line--column--hero-donate .line--module {
top: 0;
bottom: auto;
/* Revision 16 Aug: the line has to reach the Every Dollar for Impact card. It ended at
y=705 and the card's content starts at y=765, so it stopped 60px short. The drawing
itself was lengthened by 60 in the module's SVG (viewBox, height, vertical run and
gradient end all moved together, so the curve at the top is not stretched); this
drops the box by the same 60 so the extra length appears at the bottom instead of
pushing the top up. Was -6px, from animation.css.
17 Aug: short again, by another 76, and worth recording WHY because it was not a new
fault in the line. The "more padding between hero and Every Dollar" revision added 69
to that row's padding-top, which moved the card down while the line stayed where it
was. Anything tuned to the card's top has to be re-checked whenever that padding moves.
Measured, and identical at every desktop breakpoint - the line and the card both hang
off the hero's bottom edge, so the shortfall does not vary:
1440 ink 758 / card 834 1300 672 / 748
1200 ink 672 / card 748 1024 742 / 818
so 76 everywhere. SVG lengthened 465 -> 541 in rev-2943-heroline2.php, both modules,
and the box drops by the same 76: -66 -> -142.
AND IT STILL DOES NOT CONNECT - read this before touching these numbers again.
The geometry is now right and irrelevant. The DOM reports the path reaching exactly
834 against a card at 834, but a render scan of the painted pixels shows the ink
stopping at 887 while the card starts at 1135. The difference is that the hero row
carries BOTH of these:
clip-path: ellipse(110% 100% at 50% 0%) (the curved bottom, theme-wide)
overflow: hidden
and either one alone cuts every descendant at the row's box. That ellipse's lowest
point is the row's own height, which is why the line always stops dead on the hero's
curved edge no matter how long the drawing is. The first pass on this line, which
added 60, was verified against getBoundingClientRect and not against pixels - so it
measured a box that had already been clipped away. Neither pass ever moved the ink.
This cannot be fixed from here. clip-path and overflow both apply to the whole
subtree, there is no opt-out, and the row's z-index:1 additionally paints the hero
above the cards row. The line has to stop being a descendant of the hero: the
column-group that holds it moves into the Every Dollar row, which is not clipped,
and is then offset upwards so the curve still starts inside the hero. The Figma
agrees that is where it belongs - Vector 12 (6025:18502) runs to y 1170.57, which is
141px PAST the cards' content top, i.e. it passes behind the cards rather than
stopping at them.
RESOLVED 17 Aug by moving the line out of the hero altogether - rev-2943-linemove.php
reparents it into the Every Dollar row and takes the `line--row` class with it. The
old `bottom: -142px` that went with the hero-bottom anchor is gone, replaced by the
top-anchored offset above.
The drawing then settled at a 539 box with its run ending at 537.5, which lands the
ink exactly ON the card's content top - 0px, verified at 1440, 1300, 1200, 1024 and
992, the same at each because line and card both hang off the hero's bottom.
It took four goes, and the reason is worth one line: the ink's bottom edge sits half
a stroke-width - 1.5 of the 3px - BELOW the run's end point, so the box always has to
be the run plus 1.5. Sizing the box to the run alone is what put it 2px into the card
to begin with. 541 (2px over) -> 535 (4px short) -> 537 (2px short) -> 539.
Length is adjusted with rev-2943-linenudge.php, which takes a px delta and moves the
box, the run and the gradient's far stop together. Do NOT do it by changing the
offset above - that positions the TOP of the box and would drag the curve up into the
hero, which is already correct. */
}
/* The horizontal offset is desktop-only, and that bound is new. It used to be unscoped,
which was wrong and had been wrong for a while: below 1367 animation.css anchors this line
from the RIGHT instead - `left: unset` on the column with `right: calc(400px + padding)`
on the module, so it clears the donate form - and an unscoped `left: 0` here overrode that
`unset` and dragged the line to the page's left edge. Measured at 1300, 1200, 1024 and
992: the SVG sat at x 0..121 against 720..841 at 1440. Caught while checking the move, not
caused by it.
1367 is the boundary animation.css itself uses to switch anchoring. */
@media only screen and (min-width: 1367px) {
.fl-builder-content-2943 .line--column--hero-donate .line--module {
/* Was 0, which drove the line 27.5px INTO the donate form at every width from 1367 up.
The overlap is the same at 1382, 1455, 1615 and 1935, and that constant is the tell:
line ink right = vw/2 + 119.5 column sits at left:50% of the row
form left = vw/2 + 92 container's right edge, minus the form's 519
Both move with the viewport at the same rate, so the overlap never varies and no
width was ever going to be the one that looked right.
It hid for several rounds because the probe injected a 400px stand-in for the
script-loaded form. 400 is correct BELOW 1367; above it the component is 519, so
every desktop reading placed the form's left edge 119px too far right and reported
clearance over an overlap - which is why trimming the path by a pixel at a time
never touched it. The stand-in now takes its width from the module's own max-width.
-27.5 would land the tip exactly ON the form's left edge - vw/2 + 119.5 - 27.5 =
vw/2 + 92 - and that still read as a hairline gap, so -25.5 carries it 2px onto the
form. It connects rather than clears, which is what the Figma shows: it runs the
line behind the form, and "behind" and "2px over" look the same at this scale.
Behind itself is not available - it needs the form painted over the line, which the
hero's stacking context rules out (see the long note above). */
left: -21.5px;
}
}
/* REMOVED 17 Aug (Leshan): "we need it to fill up as we scroll down, like how we did for the
last page's hero - currently it's just solid."
This block used to pin the hero line's stroke complete - dasharray none, dashoffset 0,
opacity 1, all !important - which was the 15 Aug decision that the hero is the first thing
on screen and a scroll-driven reveal would play where nobody can watch it. That is now
reversed: the draw range in animation.js runs from the page top to the hero's bottom
passing 30% up the screen, so it is watchable from the moment the page loads.
The pin has to go rather than just be overridden. It carried !important specifically to
beat the inline `stroke-dashoffset` that GSAP writes on every scroll tick, so leaving it in
place would silently defeat the animation no matter what animation.js does.
Do NOT re-do this by dropping the `line--draw-me` class if it is ever wanted solid again:
that class is also what reveals `.line--path` at all (animation.css sets it
`visibility: hidden`), so removing it leaves only the 0.15-opacity ghost. */
/* Speed, the other half of the same request. The component default is 60s for a loop;
90s per Leshan on 15 Aug 2026. The duration is the only lever - the keyframe always
travels the same distance (-50% minus half the gap), so raising the time is what slows
it, and nothing about the layout moves.
The theme sets the default on `body:not(.fl-builder-edit) .marquee` (0,2,1); this is
(0,3,0) and wins on class count without needing !important. */
.fl-builder-content-2945 .marquee.testimonial {
--_animation-duration: 90s;
}
.fl-builder-content-2945 .row--partner-bfi .fl-accordion-button-label {
color: var(--GivePower-Palette-White, #fff);
opacity: .5;
transition: opacity .2s ease, color .2s ease;
}
.fl-builder-content-2945 .row--partner-bfi .fl-accordion-item-active .fl-accordion-button-label {
color: var(--GivePower-Palette-Sun-Yellow);
opacity: 1;
}
.fl-builder-content-2945 .row--partner-bfi .fl-accordion-button:hover .fl-accordion-button-label {
opacity: 1;
}
/* Yellow rule beside the open item, spanning its label and content. */
.fl-builder-content-2945 .row--partner-bfi .fl-accordion-item {
padding-left: var(--Sizing-Units-2XS);
border-left: 2px solid transparent;
}
.fl-builder-content-2945 .row--partner-bfi .fl-accordion-item-active {
border-left-color: var(--GivePower-Palette-Sun-Yellow);
}
.fl-builder-content-2945 .row--partner-bfi .fl-accordion-content {
color: var(--GivePower-Palette-White, #fff);
}
/* Icons are absent in the design; clearing the setting can leave an empty box. */
.fl-builder-content-2945 .row--partner-bfi .fl-accordion-button-icon {
display: none;
}
/* TABLET, and down - the columns stack, so the rule reads better tightened up. */
@media only screen and (max-width: 992px) {
.fl-builder-content-2945 .row--partner-bfi .fl-accordion-item {
padding-left: var(--Sizing-Units-3XS);
}
}
/****************************************/
/* END :: GivePartner rebuild - Built for Impact */
/****************************************/
/**********************************************************/
/* START :: 2026 page builds - Figma spec pass */
/**********************************************************/
/* Values below are read from the auto-layout of the Pre-Launch Changes frames
(Individual Impact 6025:18461), not measured off a screenshot. Everything is
scoped to .fl-builder-content-2943 / -2945.
That scoping is load-bearing, not tidiness: 2943 was built by duplicating rows
from /join/donate/ and the two layouts still share 32 Beaver Builder node IDs,
so any rule keyed to a bare .fl-node-XXXX would land on the live Donate page as
well. Nothing here is keyed to a node ID. */
/* ---------------------------------------------------------------------------
DESKTOP-ONLY BLOCK.
The Figma frame is a single 1366 desktop artboard - it says nothing about
tablet or phone. Everything in here is therefore a fixed desktop measurement
and must not reach the smaller breakpoints, where the theme has its own
responsive behaviour that already works.
This needs a media query rather than trusting the cascade: these selectors run
to four classes, the theme's mobile rules are two or three, and a media query
adds no specificity. Without the wrapper a desktop value simply wins at every
width - which is exactly what happened here. The Gear Up and Trek images held
height:460px down to 390px wide, filling a phone screen and overflowing it.
--------------------------------------------------------------------------- */
@media only screen and (min-width: 993px) {
/* Buttons. Figma draws every primary button 63px tall: 20px padding, a 23px
19/normal label, 20px padding. The theme's --btn-padding is 19px 28px, which
lands at 61. Font, weight, 0.57px tracking and the 20px radius already match,
so only the padding moves. Below 993 the theme swaps in --btn-padding-mobile,
which this must not override. */
.fl-builder-content-2943,
.fl-builder-content-2945 {
--btn-padding: 20px 30px;
}
/* Section block padding. The theme default is 66/66 (--content-padding-block),
which is already what the Cards section wants, so only the two sections that
depart from it are listed.
Gear Up / Trek 6025:18744 / 6025:18752 pt 36 pb 66
Hydrate 6025:18760 pt 66 pb 120
The theme steps --content-padding-block down to M then S on smaller screens;
a 120px gap under a phone-width section would be absurd, so this stays here. */
.fl-builder-content-2943 .row--text-2column-image-left > div,
.fl-builder-content-2943 .row--text-2column-image-right > div {
padding-top: var(--Sizing-Units-S);
}
.fl-builder-content-2943 .row--individual-impact.row--feature-card-horizontal-overlap:not(.row--join-charge):not(.row--recognized) > div {
padding-bottom: var(--Sizing-Units-3XL, 120px);
}
/* REVISION 16 Aug (Leshan, standup): "Hydrate with Purpose - more spacing between the
button and text."
Measured first, and we were already correct: 36px at 1425, 1200, 992 and 768, which
is the frame's own figure - 6025:18760 draws Content gap 36 (S), and the SPEC records
the same 36 on Gear Up and Trek. So this is a departure from the Figma, asked for,
not a miss.
Why 36 reads tight here even though it is the drawn value: the text block above uses
XS / 26 between heading and body, so 36 to the button is only 10px more than the gap
INSIDE the copy. The button therefore reads as a third paragraph rather than as the
card's action. L / 66 is the next step on the system's own scale (26 / 36 / 44 / 66)
and is the first one that separates them clearly - M / 44 is +8px, and this file has
already recorded that an 8px shift on these buttons is barely legible.
Kept as the token rather than a literal, so it stays in step with the scale.
Consequence, measured rather than predicted: at the drawn width the card does not
change height at all. Its 357 is set by the IMAGE column - 292 of photo inside 32.5
top and bottom - not by the copy, which only stacks to 327. The extra 30 is absorbed
by slack that was already there, so the image keeps the drawn 32.5 margin.
1425 357 -> 357 no change
1200 357 -> 383 the body wraps to 3 lines here, so the copy is what sets it
992 441 -> 471
Nothing else moves - the row's own padding is set above and is untouched.
Gear Up and Trek still sit at 36. They were not mentioned and they are a different
shape - full-width two-column, no card edge for the button to float inside - so they
are deliberately left. If the wider gap is wanted there too it is the same rule with
their two row classes added.
NOT done in Beaver Builder, and this one was close. The theme's own comment on the
rule says "can be overridden individually in BB", and it is a plain module margin, so
BB is the natural home. What stops it is the breakpoints: BB writes a base value that
applies at ALL widths, and its tiers are medium and small against 992 / 768, while the
theme steps this gap 36 -> 26 somewhere below 768 (measured 36 at 768, 26 at 400).
A BB base of 66 would carry to the phone, and a BB small override would flatten the
theme's own step. Scoped to 993+ here so tablet and phone keep exactly what they
have, for the mobile pass against the live site. */
.fl-builder-content-2943 .row--individual-impact.row--feature-card-horizontal-overlap:not(.row--join-charge):not(.row--recognized) .fl-module-button {
margin-top: var(--Sizing-Units-L, 66px);
}
/* Gear Up / Trek images are 578 x 460 in the Figma (6025:18746 / 6025:18759) but
render 500 tall. Two global rules disagree about .mediumheight:
image-video.css .fl-post .mediumheight img max-height: 460px
post-grids.css .mediumheight min-height: 500px
min-height always wins over max-height, so 500 is what ships - and post-grids.css
reaches this photo through a bare, unscoped .mediumheight. The min-height has to be
released explicitly or the height below cannot take effect.
Measured before: image occupied y 2376..2875 = 500. Figma: 460.
Below 993 the theme's own 70vw/max-360 and 80vw/max-280 sizing takes over. */
.fl-builder-content-2943 .row--text-2column-image-left .column--image .mediumheight,
.fl-builder-content-2943 .row--text-2column-image-right .column--image .mediumheight,
.fl-builder-content-2943 .row--text-2column-image-left .column--image .mediumheight .fl-photo-content,
.fl-builder-content-2943 .row--text-2column-image-right .column--image .mediumheight .fl-photo-content {
min-height: 0;
}
.fl-builder-content-2943 .row--text-2column-image-left .column--image .mediumheight img,
.fl-builder-content-2943 .row--text-2column-image-right .column--image .mediumheight img {
min-height: 0;
height: 460px;
max-height: 460px;
object-fit: cover;
}
/* Line breaks in the body copy. The Figma fills "...that turns one" onto line 1 and
starts line 2 at "unforgettable"; ours pushed "one" down. Not a wrapping mode and
not the column width - the text box is 578.5 here against the Figma's 578. It is
the type being 0.44% too large:
style.css p, .p, ul, ol font-size: 18px; font-size: 1.13rem;
The second declaration wins, and 1.13rem is 18.08px at the 16px root, not 18. Over
this 575px line that is +2.5px, and the Figma leaves exactly 3px of slack after
"one" - so the rounding alone is what moves the word. Measured: our line ran 546
against the Figma's 542 for the same words, with the drift accumulating steadily
(+1px by word 3, +2px by "GivePower", +4px by the end).
Pinned to the integer the theme itself asks for on the line above its own rem.
Scoped to these two rows on this layout - the 1.13rem rounding is site-wide and
not ours to change. */
.fl-builder-content-2943 .row--text-2column-image-left .column--text .fl-rich-text p,
.fl-builder-content-2943 .row--text-2column-image-right .column--text .fl-rich-text p {
font-size: 18px;
}
/* Cards row, middle card. Figma 6025:18507 is padding 36 on all four sides; the
shared component uses 52px 36px 36px, which pushes the heading down 16px.
Bottom is 27 rather than 36 because the GoodLeap logo is drawn as a separate
layer sitting over the card (6025:18604), so it does not respect the card's own
padding - it lands 27px above the bottom edge.
The theme sets padding-top 113 at <=992 and 36 at <=768 to clear the stacked
image; both must survive, hence the wrapper. */
.fl-builder-content-2943 .row--data-storytelling-column .column--card > .fl-col-content {
padding: var(--Sizing-Units-S) var(--Sizing-Units-S) 27px;
}
}
/* The GoodLeap logo lives inside the rich-text as an aligncenter image and is
attached at 322 x 78; the Figma draws it 196.78 x 48.02. At 62% oversize it
added ~30px of height, and its surrounding space another ~46, which together
were the entire reason this card ran 555 tall against the Figma's 469 - and,
because the row is equal-height, why all three cards did. */
.fl-builder-content-2943 .row--data-storytelling-column .column--card .fl-rich-text img {
display: block;
width: 196.78px;
height: auto;
margin: 10px auto 0;
}
/* The logo sits in its own after the body copy, so the paragraph margins add a
second gap on top of the 10px above. Zeroing them leaves the image's own margin
as the single source of that spacing. */
.fl-builder-content-2943 .row--data-storytelling-column .column--card .fl-rich-text p:last-child {
margin-top: 0;
margin-bottom: 0;
}
.fl-builder-content-2943 .row--data-storytelling-column .column--card .fl-rich-text p:first-child {
margin-bottom: 0;
}
/* Its body copy is P Regular BOLD (Lato Heavy) in the Figma, not P Regular.
Beaver Builder puts .fl-module-rich-text and .fl-rich-text on the SAME element, so
these must be chained, not written as a descendant pair.
The site loads Lato at 400/700/900, with no 800 cut, so 800 resolves to 900 - which
is what the theme's own buttons already declare for this token, so the page stays
consistent with the rest of the site rather than inventing a weight. */
.fl-builder-content-2943 .row--data-storytelling-column .column--card .fl-rich-text,
.fl-builder-content-2943 .row--data-storytelling-column .column--card .fl-rich-text * {
font-weight: 800;
}
/* Hero text carries Drop Shadow Main (0 0 20px #00000033) in the Figma. Applied
to the text wrapper so the heading and description share one shadow, the way a
single Figma effect on the Text frame behaves - per-element shadows would double
up where the two blocks are close. */
.fl-builder-content-2943 .row--hero-donate .row--hero-full--content {
filter: drop-shadow(0 0 20px rgba(0, 0, 0, 0.2));
}
/* Recognized band. The theme's rounded-corner utility masks with an SVG sized by
--border-radius-size, default 30px; the Figma band 6025:18523 is 50px. */
.fl-builder-content-2943 .row--recognized {
--border-radius-size: 50px;
}
/* Join The Charge card interior, from 6025:18617:
heading -> body 9px (the theme default for rich text is XS / 26px)
body -> form 50px
body width 591 of the 762 content column
The 9px goes on the module only, and the inner wrapper is pinned to 0. Setting both
to 9px does NOT collapse to 9 here: the column carries equal_height, so Beaver Builder
makes .fl-col-content a flex container, every module is a flex item, and a flex item
establishes its own formatting context - which is exactly the condition under which a
child's top margin stops collapsing through its parent. The two stacked to 18 and put
the intro copy 9px below where the Figma draws it (measured against the 1:1 export:
body ink top 138 from the card top against the Figma's 128). */
.fl-builder-content-2943 .row--join-charge .fl-module-rich-text {
margin-top: 9px;
/* Body measure. The Figma draws 591 and we ran 585 for a while, the 6px shaved off on
purpose to reproduce the frame's own break after "and" - our spaces set about half a
pixel narrower than the export's, which left just enough room for " clean" to creep
up onto line 1 where the Figma breaks before it.
REVISION 16 Aug (Leshan, standup): that break is not wanted. "clean" belongs next to
"and" on the top line, which is what the wider box was doing by accident before it
was tuned out. So the shave comes off - but 591 is not the number to go back to.
Measured at the rendered 20/28, from the paragraph's own text:
..."and" ends at 539.2
..."clean" ends at 589.2 <- line 1 must be at least this wide
..."energy" ends at 653.7 <- and narrower than this, or the next word joins
so any measure in 589.2 .. 653.7 gives the break asked for. The Figma's 591 sits
1.8px inside that window; half a pixel per space is precisely the size of error this
file has already recorded once, so 591 would be one font-metric wobble away from
flipping back. 620 is the middle of the window - 31px of clearance on one side, 34 on
the other - and no plausible rendering difference reaches either edge.
Still two lines, so the yellow panel's 212 and everything below it are unmoved.
Nothing visible shifts: the copy is left-aligned and the box has no fill. */
max-width: 620px;
}
/* This card's intro is NOT the P-Reg 18/30 token every other body on the page uses - it is
drawn larger and tighter, and section 3 of SPEC-2943.md recorded the card's geometry
without its type, so we shipped 18/30 and the copy wrapped a word late ("...and clean
energy" on line 1 instead of breaking after "and").
Line-height is certain: the SPEC's own "Body ... h 56" over two lines is 28, and the
1:1 export measures line-to-line at exactly 28 where Trek's measures 30.
Size is 20px, from three independent reads of the export, all agreeing:
shared substring "Subscribe ... and" 544 against our 487 at 18px -> 20.1
cap height 'S' 15 against our 13 -> 20.8
ink height 19-20 against our 16 -> ~20.5
and 487 x 20/18 = 541 against the measured 544, where 19px gives 514 and 21px gives 568.
The wrap point itself is the confirmation: at 20px the line has to break after "and". */
@media only screen and (min-width: 993px) {
.fl-builder-content-2943 .row--join-charge .fl-rich-text,
.fl-builder-content-2943 .row--join-charge .fl-rich-text p {
font-size: 20px;
line-height: 28px;
}
}
/* REVISION 16 Aug (Leshan, standup): "and clean on line one, but not too far past the
title." The intro was overhanging the heading by 98px. The intro is not the fault - the
HEADING IS UNDERSIZED, and by the same mechanism as the body above: section 3 of
SPEC-2943.md recorded this card's geometry without its type, so the heading took the
theme's H2 token while the frame draws something larger.
Measured, not inferred. Ink width is the comparison, because a Range gives the ADVANCE
width (side bearings included) which is not what Figma reports; canvas
actualBoundingBoxLeft/Right gives true ink and is directly comparable:
Figma 6025:18619 render bounds 558.0 wide
ours at the H2 token, 62.08px 491.1 wide
size needed to reach 558 70.47 .. 70.53
Cap height agrees independently - 51px drawn against our 45 is the same 1.13 ratio - so
this is size, not tracking. (Ink HEIGHT is not usable here: Futura's capital J drops
below the baseline, so the drawn 53 is cap height plus that hook, not cap height.)
line-height deliberately left on the token's 62. The frame does the same - a 762 x 62
text box carrying ~70px type - so the heading's ink grows inside a line box that does
not, and nothing below it moves. Verified: card height unchanged.
With the title at its drawn 558, the intro's first line at 589 clears it by 31px rather
than 98 - out a little, which is what was asked for, and close to the frame's own
relationship where the intro sits just inside the title.
NOT done through Beaver Builder, and the reason is a real limit rather than a
preference: BB's typography fields are tiered desktop / medium / small against its own
992 and 768 breakpoints, and BB "desktop" therefore means everything above 992. Setting
it there would carry 70.5px down to 1024, where the heading's box is only 420 and 558 of
ink wraps to two lines over a 62px line-height. There is no BB field that can say
"1367 and up".
Which is also why this is scoped to 1367+: that is where the theme's base H2 applies and
the Content box is the drawn 762, with 200px of clearance. Below it the theme steps H2
to 52 and the box narrows to 596 then 420; those widths keep today's type and belong to
the mobile pass against the live site.
Worth a second opinion before launch: a text node scaled by hand in Figma produces
exactly this - an off-token size like 70.5 where the system says 62. If the designer
meant H2, this block comes out and the overhang comes back. */
@media only screen and (min-width: 1367px) {
.fl-builder-content-2943 .row--join-charge .fl-module-heading .fl-heading,
.fl-builder-content-2943 .row--join-charge .fl-module-heading .fl-heading span {
font-size: 70.5px;
}
}
.fl-builder-content-2943 .row--join-charge .fl-module-rich-text > div {
margin-top: 0;
}
/* The body -> form gap is set with the yellow panel above, where it has to be split
36 / 14 across the panel's bottom edge. */
/* Recognized row padding NOW LIVES IN BEAVER BUILDER, on the row itself, at all four of
its tiers. There is deliberately no rule here - this comment is the record of how the
numbers were arrived at, because a BB field cannot carry one.
tier top bottom
default >1366 98 140
large <=1366 98 140
medium <=992 44 110
responsive <=768 36 102
TOP - revision 16 Aug (Leshan, standup), "add more padding to top of section, 164px I
think ours is 66". The 164 is right and the 66 was half the story: the drawn 164 is two
paddings, and we have both.
Figma band 6025:18522 top 3880 -> card 6025:18524 top 3978 = 98 above the card
card -> Content 6025:18598 y 66 = 66 inside it
= 164 to the ink
ours row 66 + card 66 = 132
So 32 short, not 98. Row padding 66 -> 98 puts the heading at 164 exactly; measured
after the change at 3821 against a row top of 3657.
BOTTOM - "more padding between Donate Now and the curved blue line on the footer." This
one was not a missing gap, it was an overlap. Measured at 1425 before:
button bottom 4152 -> card bottom 4218 = 66, already the drawn figure
footer top 4184 = 34px ABOVE the card's bottom edge
The footer carries a deliberate margin-top of -100px, and 66 of row padding does not pay
for it, so the curve was pulled up INTO the card. The Figma starts the footer frame
6025:18635 at 4471, which is exactly the card's bottom edge. Cancelling that margin
exactly puts the curve where the card ends and leaves Donate Now the card's own 66.
That cancellation was 100 against the footer's -100 until the footer curve was deepened
to the drawn 126 (interface.css). A 126px arc runs 26px PAST a band that stops at 100,
and below the band the page is the same navy as the footer - so the last stretch of the
curve had nothing to show against and each corner ended in a flat horizontal cut.
Reported by Leshan with screenshots of both corners.
Fixed by moving BOTH numbers together, which is the only way: the band's bottom and the
footer's position are locked to each other by that margin, so padding alone just moves
both and keeps the same 26px shortfall. 140 is the pair now, against an arc that is a
flat 126 deep at every desktop width - the SVG mask that draws it fixes the depth in px,
where the ellipse it replaced varied it with the footer's height (126 at 851 tall, 134
between ~993 and ~1366 where it is 905). So there is 14px of clearance at every width
rather than 6 at the worst one, and any cream below the arc is painted over by the footer,
so the overshoot costs nothing. The footer's own -140 is immediately below and page-scoped.
Measured after: footer top = card bottom, unchanged, so the button still has its 66.
MEDIUM AND RESPONSIVE are not new. They hold what this file used to compute here -
calc(--content-padding-block + --Sizing-Units-L), i.e. 44+66 and 36+66 - so nothing below
993 moves. That rule existed because the curve is drawn from the viewport width and does
not shrink as the screen narrows, while --content-padding-block steps L -> M -> S, and
below 993 the button lost its clearance and the curve cut across it (measured at 390:
button top 5879, curve top 5921 at the centre where it peaks, 5947 at the edges). Note
the footer's own margin also changes to -66px below 769, which is why the two tiers keep
different numbers.
It was moved into BB rather than extended here for two reasons. The row had no padding
settings at all, so it was taking the theme's `.fl-row > div` at (0,1,1) and BB's
`.fl-node-X > .fl-row-content-wrap` at (0,2,0) beats it - unlike the hero gap earlier on
this page, where a (0,4,1) theme rule made the builder field a lie. And leaving this rule
in place would have made it beat BB at (0,2,1), so the in-house team would have seen 110
in the builder while the page took its number from here.
The cost of the move is that the four numbers no longer track the tokens. If the sizing
scale is ever retuned, these are hand-set and will need revisiting. */
/* The other half of the pair above. The footer's -100px margin is a site-wide constant and
is deliberately NOT changed at source: it is the distance every page's last section gives
up to the footer, and shortening it by 40 everywhere would pull the curve 40px closer to
the content on pages nobody has looked at - which is the exact failure QA #98 was raised
for. So it moves on this page only, where the row padding has been raised to match.
-140 with padding-bottom 140 leaves the footer's top edge exactly where it was, on the
card's bottom edge. Nothing moves; the band simply now extends far enough down for the
whole arc to be drawn against it.
993+ only, matching the row's own tiers. Below that the theme uses -100 and then -66, and
swaps the curve for 200vw / 250vw ellipses that are far shallower than the band - measured
29px deep at 992 against 110 of padding - so the arc is already fully on cream there and
there is nothing to fix.
WORTH RAISING FOR THE FOOTER PASS: the underlying rule is that the footer's negative
margin has to be at least as large as the curve's depth, or the arc runs past whatever
section it is drawn against. That held by luck while the curve was 65 deep. It is now a
real constraint and it applies site-wide, not just here - every other page currently hides
the overshoot only because its last section happens to be the same navy as the footer. */
@media only screen and (min-width: 993px) {
body.page-id-2943 .fl-page-footer-wrap {
margin-top: -140px;
}
}
/* ---------------------------------------------------------------------------
GivePartner hero (frame 11544, Banner 6025:18417) - the bottom curve.
The theme cuts every ellipse hero with
body:not(.fl-builder-edit) .clip-path--ellipse { clip-path: ellipse(110% 100% at 50% 0%) }
and that class is on 43 rows, so it cannot be retuned globally.
The drawn shape is NOT that ellipse. Traced off the 1:1 export of the Union
boolean-operation (6025:18418, 1366 x 894.43) by scanning each column up from the
bottom for the Ocean plate, the navy rises to y 768 at both frame edges and meets
the frame bottom (894) at the centre - a depth of 126. The theme's ellipse only
reaches 797 at the edges, so ours renders 26px shallower and reads as too flat.
No single ellipse reproduces it. Three were fitted against the trace:
rx only, centre pinned at 0% rms 5.44 worst 17.6
general 3-parameter ellipse rms 2.83 worst 16.0
half-ellipse, rx = half width - worst 16
Each lands ~16px out somewhere, because the real edge is flatter across the middle
and turns harder at the shoulders than an ellipse can be. So the curve is given
explicitly. Points come from the trace, symmetrised about the centre and simplified
to a 1px tolerance (gen-clip.php); max deviation from the traced edge is 0.93px.
Percentages, not pixels, so it scales with the row exactly as the ellipse it
replaces did - and the row is already the right height (measured 894.2 against the
drawn 894.43), which is why only the shape is touched.
Desktop only: the Figma frame is a single 1366 artboard and says nothing about
tablet or phone, where the theme's own ellipse still applies. --clip-path-margin is
deliberately left alone - it controls the pull-up of the following row, not the
curve, and the deepest point of both shapes is still the row's bottom edge. */
@media only screen and (min-width: 993px) {
.fl-builder-content-2945 .row--hero-full.clip-path--ellipse {
-webkit-clip-path: polygon(
0% 0%, 100% 0%, 100% 86.01%, 98.46% 87.43%,
96.34% 89.07%, 91.5% 91.96%, 86.45% 94.23%, 79.41% 96.58%,
71.72% 98.29%, 64.69% 99.32%, 56.78% 99.94%, 50.04% 100%,
49.96% 100%, 43.22% 99.94%, 35.31% 99.32%, 28.28% 98.29%,
20.59% 96.58%, 13.55% 94.23%, 8.5% 91.96%, 3.66% 89.07%,
1.54% 87.43%, 0% 86.01%
);
clip-path: polygon(
0% 0%, 100% 0%, 100% 86.01%, 98.46% 87.43%,
96.34% 89.07%, 91.5% 91.96%, 86.45% 94.23%, 79.41% 96.58%,
71.72% 98.29%, 64.69% 99.32%, 56.78% 99.94%, 50.04% 100%,
49.96% 100%, 43.22% 99.94%, 35.31% 99.32%, 28.28% 98.29%,
20.59% 96.58%, 13.55% 94.23%, 8.5% 91.96%, 3.66% 89.07%,
1.54% 87.43%, 0% 86.01%
);
}
/* Hero copy column: Content 6025:18424 is 707 wide, the site utility is 700.
The 7px does not move where the description wraps - both break after
"Partner" and after "creates", confirmed against the 1:1 export - but it is
what the scroll line is anchored to below, so it has to be the drawn number. */
.fl-builder-content-2945 .row--hero-full--content.maxwidth700 {
max-width: 707px;
}
/* Built for Impact starts 44px lower than the theme puts it.
In the frame the sections are stacked with a 44px gap between frames, ON TOP of
each section's own 66 padding:
Banner 6025:18417 y 0 h 894.43 -> ends 894.43
Built for Impact 6025:18398 y 938.43 -> 44 gap
Container 6025:18399 y +66 -> content at 1004.43
so the drawn distance from the hero's bottom edge to the heading is 110.
The theme gives 66. It pulls the following row up by --clip-path-margin and hands
it back as padding:
.clip-path--ellipse + .fl-row > .fl-row-content-wrap {
padding-top: calc(var(--clip-path-margin) + var(--content-padding-block)) }
which lands the content at hero-bottom + --content-padding-block, i.e. 66.
Measured before this rule: our image top and heading ink both sat at 960 against
the drawn 1004.43 - one 44px offset moving the whole section, not two faults.
Added to the theme's own calc rather than replacing it, so the row stays in step
with --clip-path-margin and --content-padding-block if either is ever retuned.
The 44 is not a spacing token (the frame's scale runs 4/8/16/26/36/66/88), it is
the gap between the frames themselves, and it repeats: Built for Impact ends
1770.43 and the carousel starts 1814.43.
The selector has to carry 5 classes: the theme's is
body:not(.fl-builder-edit) .clip-path--ellipse + .fl-row > .fl-row-content-wrap,
which is already (0,4,1), so a three-class page-scoped rule would silently lose. */
.fl-builder-content-2945 .clip-path--ellipse + .fl-row.row--partner-bfi > .fl-row-content-wrap {
padding-top: calc(var(--clip-path-margin) + var(--content-padding-block) + 44px);
}
/* Section rhythm below Built for Impact. Every number here is a measured gap between
drawn edges, not a token:
Built for Impact 6025:18398 ends 1770.43
Carousel 6025:18405 1814.43 .. 2330.43, tiles 1814 .. 2287
Card 6025:18194 2395 .. 2722
Join the Charge 6025:18202 2828 ..
so the drawn gaps are 44 above the tiles, 43 below them, and 64.57 from the carousel
to the card, then 106 from the card to the form. Ours were 0 / 66 / 66 / 66, which
put the tiles hard against Built for Impact and left 136 where the frame draws 108.
The carousel row is only ever classed `nopadding`, so it is reached as the row
following Built for Impact rather than by a class of its own - that is also the
relationship the spacing actually describes.
Beaver Builder writes this row's own padding as `.fl-node-XXXX > .fl-row-content-wrap`
at (0,2,0); these are (0,4,0) and (0,3,0) and clear it without !important. Node IDs
are deliberately not used - 2945 shares IDs with other layouts. */
.fl-builder-content-2945 .row--partner-bfi + .fl-row > .fl-row-content-wrap {
padding-top: 44px;
padding-bottom: 44px;
}
.fl-builder-content-2945 .row--corporate-treks > .fl-row-content-wrap {
padding-top: 64px;
padding-bottom: 106px;
}
/* The Corporate Treks card came out 332.42 tall against the drawn 327. Measured from
the DOM, every part of it is already correct:
heading 62.08 (drawn 62) gap 26 (drawn 26)
body 60.16 (drawn 60) gap 36 (drawn 36)
a.fl-button 63 (drawn 63) padding-block 40 + 40
but the button's MODULE WRAPPER is 68.19 against the button's own 63. The extra
5.19 is the inline-block baseline gap: `a.fl-button` is inline-block, so the line
box reserves descender space beneath it. The identical button in the hero measures
exactly 63 because it sits in a flex box module, where no line box is created.
vertical-align removes the gap without changing the button's own layout - display:
block would also fix it but would stretch a width:auto button. This is why the card
overflowed its own correct `min-height: 327px`, and why the overlap image sat at 20px
from the top instead of 17.5: (332.42 - 292) / 2 = 20.2, i.e. a symptom, not a
second fault. */
.fl-builder-content-2945 .row--corporate-treks .fl-button-wrap .fl-button {
vertical-align: top;
}
/* Join the Charge form - DESIGN ONLY. Labels, options and placeholder copy belong to
the in-house team and are not touched here; everything below is a size or a colour.
Most of this section already matches and is deliberately left alone: the card is
578 wide with radius 24 and 26 padding, the two columns sit 66 apart, the field
pitch is 127 (30 label + 8 + 63 input + 26), and the text inputs are radius 8 with
16px padding on white. Only four values are off.
1. The Message field. Drawn as a Long Field with an input HEIGHT of 174
(6025:18235); ours renders 76.78, because WPForms sizes a textarea from its rows
attribute and a 43px min-height, neither of which knows about the design. Set on
the textarea itself, which is border-box, so 174 is the drawn outer height.
2. That same textarea takes 14px padding where every text input on the form
correctly uses 16 - an inconsistency inside the form, not just against the frame.
3. The submit button is 18px top and bottom against the drawn 20. Horizontal padding
is already 30 and the radius already 20, so only the block padding moves; 20 + 23
+ 20 returns the 63 every other primary button on the page measures.
4. The checkboxes render 22 x 22 with square corners. Drawn 26 x 26, radius 8, 2px
Sweet Water border on white. */
/* The first two need !important and a long selector, and both are earned rather
than reached for. The theme already pins these values with !important of its own,
so nothing weaker can move them - confirmed by measuring: the checkbox and the
textarea padding below took effect on the first attempt with ordinary selectors,
while these two did not budge at all.
form-divider.css:369 .wpforms-container .wpforms-form textarea
{ height: initial !important } (0,2,1)
form-divider.css:730 html div.wpforms-container-full button[type=submit]
{ padding: 18px 30px !important } (0,2,3)
Matching !important is not enough on its own - among !important declarations the
more specific selector still wins - so each rule below also has to out-specify the
theme's, at (0,3,2) and (0,3,2) respectively. */
.fl-builder-content-2945 div.wpforms-container-full .wpforms-form textarea {
height: 174px !important;
padding: 16px;
}
.fl-builder-content-2945 div.wpforms-container-full button[type="submit"] {
padding-top: 20px !important;
padding-bottom: 20px !important;
}
/* Corrected 17 Aug (Leshan): "the boxes are like doubled and overlapping, they need to be
flat like normal boxes."
The drawn 26x26 / radius 8 was right; the ELEMENT it was put on was not. The real
`input[type=checkbox]` is not what you see - form-divider.css:532 strips its border and
parks it absolute, and the visible control is `input::after` (22x22, radius 6, 2px
--checkbox-stroke at left -4 / top -2), which is also what fills and shows the tick on
:checked. Sizing the INPUT gave it a border and a white background, so it painted as a
second box UNDER the pseudo-element and 4px out of register with it - hence two
offset rounded squares. Measured: input 26x26 radius 8 at x1023, ::after 22x22 radius 6
at -4/-2, plus a 16x16 ::before that ::after's white background had always covered.
Same numbers, moved onto ::after, with the offsets recentred so the box grows around
its old centre rather than down and to the right: the 22x22 sat at -4/-2, centre 7/9,
so 26x26 about the same centre is -6/-4. The input goes back to the theme's invisible
state - nothing here restyles it - so exactly one box paints.
Border colour is left alone: --checkbox-stroke already computes to #4ABFBF. */
.fl-builder-content-2945 div.wpforms-container-full .wpforms-form .wpforms-field-checkbox input[type="checkbox"]::after {
width: 26px;
height: 26px;
border-radius: 8px;
left: -6px;
top: -4px;
}
}
/* Revision 17 Aug (Leshan), second pass: the form at the foot of this page goes to 1px
#DDDDDD. So the override that used to sit here is deleted rather than retuned - #DDDDDD is
already what `--secondary-light` (form-divider.css:11) resolves to, and the base rule
(form-divider.css:408) is already 1px. Restating it here would only pin the page to a
value it would otherwise inherit, and would quietly stop tracking the token if that ever
moves. The fields now take the theme default for width, colour, radius and focus ring, and
there is nothing page-specific left on them to maintain.
Kept as a note rather than dropped silently, because this is the third setting in two days
and the next person should not have to re-derive the path: 16 Aug standup put the fields at
2px Ocean 0.55 ("thicker / darker"), the first pass on 17 Aug moved them to 1px #C1BFBB,
and this reverts both.
Worth flagging: the Individual Impact card above was NOT part of this second pass and is
still on #C1BFBB. That is what was asked for, but it does mean the two forms no longer
match each other - if they are meant to, this is the block to bring back. */
/**********************************************************/
/* END :: 2026 page builds - Figma spec pass */
/**********************************************************/
/**********************************************************/
/* START :: Pre-Launch QA (Aug 10) */
/**********************************************************/
/* QA #47 (KD) - text on the yellow card should be centre aligned. The card is the
#FEC000 column on Meet The Team. Neither module carries an alignment setting -
BB's rich-text module has no alignment control at all, its alignment comes from
the HTML - so setting one would have looked applied and changed nothing.
Scoped to the two text modules rather than the column, so the button below them
keeps its own alignment. Scoped to the page too: 2026 shares node ids with other
layouts and a bare .fl-node- selector would leak. */
.fl-builder-content-2026 .fl-node-opfwngtyk04d,
.fl-builder-content-2026 .fl-node-opfwngtyk04d .fl-heading,
.fl-builder-content-2026 .fl-node-w6dm4fjv5ep1,
.fl-builder-content-2026 .fl-node-w6dm4fjv5ep1 .fl-rich-text {
text-align: center;
}
/**********************************************************/
/* QA #119 (BS) - Privacy Policy: navy strip removed so the intro copy sits on the white
body. BS asked for "a small line for division" in its place. A hairline under the copy,
held to the content measure rather than bleeding full width, which divides the intro
from the policy body without reintroducing a band. Scoped to the page: node ids are not
unique across layouts. */
.fl-builder-content-2198 .fl-node-n1mez9siwjch .fl-row-content-wrap {
padding-bottom: 28px;
position: relative;
}
.fl-builder-content-2198 .fl-node-n1mez9siwjch .fl-row-content-wrap::after {
content: "";
position: absolute;
left: 50%;
transform: translateX(-50%);
bottom: 0;
width: min(1000px, calc(100% - 48px));
height: 1px;
background: rgba(26, 50, 66, .18);
}
/* QA #114 (BS) - GivePartner testimonials: "Possible to slow these down so people can
read them or maybe we do pull quotes?" Settled in the doc's own comments - "slow down
speed and make them pause on hover for launch", agreed by two reviewers - so pull
quotes are off the table and this is the whole change.
The testimonials are the CSS marquee (.marquee.testimonial), not a slick carousel, so
speed is the animation duration. The theme already defines .slow as 140s; reusing that
value rather than inventing one keeps it consistent with the logo marquee. Pause on
hover also covers keyboard focus, so a reader tabbing through can stop it too. */
body:not(.fl-builder-edit) .marquee.testimonial {
--_animation-duration: 140s;
}
body:not(.fl-builder-edit) .marquee.testimonial:hover > .fl-col-content,
body:not(.fl-builder-edit) .marquee.testimonial:focus-within > .fl-col-content {
animation-play-state: paused;
}
/* Anyone who has asked the OS for less motion should not get a moving wall of text at
all; the theme honours that elsewhere via [data-animated]. */
@media (prefers-reduced-motion: reduce) {
body:not(.fl-builder-edit) .marquee.testimonial > .fl-col-content {
animation-play-state: paused;
}
}
/* QA #98 (BS) - What's New: "this section gets cut off by the bottom footer halfmoon
shape. Could we allow for more padding please?"
Measured at vw1382 with the probe root widened to body (the default root excludes the
footer, so the overlap is invisible otherwise):
News last heading bottom 4863, footer top 4855 -> -8px OVERLAPPED
Live Impact 3860, 3961 -> 101px
Treks 9384, 10180 -> 796px
News is the outlier, so 110px extra brings it to roughly Live Impact's clearance
rather than a number picked out of the air. The footer's own -100px margin is
deliberate and left alone.
Done here rather than in the row's padding_bottom setting, because that value saved to
the DB and the stylesheet came back byte-identical at the old 26px.
CORRECTION (16 Aug): that diagnosis was wrong. BB regenerates row padding perfectly
well - FLBuilderModel::delete_asset_cache() silently does nothing when called through
wp-cli, so the cached stylesheet was simply never rebuilt and the old file kept being
served. Deleting the cache files directly and re-rendering produces the new value.
Proved on this same page by item 97, which set padding_top on the newsletter row and
came back correct at every breakpoint.
This override is left in place because it works and is measured, but it duplicates
what should be a row setting. Worth moving into the row's padding_bottom after launch,
at which point this block should be deleted rather than left to fight with it.
Desktop only. The row already carries its own padding_bottom_responsive of 44 for
small screens, and no ticket in this batch asks for a change below 993. */
@media only screen and (min-width: 993px) {
.fl-builder-content-2136 .fl-node-p1l5vmnbsd3w > .fl-row-content-wrap {
padding-bottom: 136px;
}
}
/* QA #120 (BS) - "Make copy on all legal pages smaller and simplify the title treatment."
Privacy Policy (2198), Accessibility Statement (2572), Terms & Conditions (2578).
Measured at 1425, identical on all three: H1 80px/89, H2 62px, H3 46px, body 18px/30.
Those are the global brand sizes from style.css - right for a marketing page, and the
reason a privacy policy currently opens at the same scale as the homepage hero.
The theme already contains a simplified version of its own scale: below 768px the
globals drop to 40 / 36 / 30, and h4 is 32px. So rather than invent a set of numbers,
the legal pages take H1 40 (the theme's own small h1), H2 32 (its h4) and H3 24, which
restores a clear three-step hierarchy that 40/36/30 does not have. Body goes to 16/26,
which is the "smaller copy" half of the ticket - it was 18px, not 16 as first recorded.
Uppercase is dropped on H2 only. Section headings inside a long legal document are
markedly harder to scan in caps, and that is the "simplify" half. H1 keeps its caps so
the page title still reads as part of the brand. Reverse by deleting one line.
Scoped by page id: the pages carry no distinguishing body class - note that the
`.privacy-policy` rules in form-divider.css match nothing at all and are dead code.
`body.page-id-X` gives (0,1,2), which beats the globals regardless of load order.
769px and up only. Below that the globals already render this simplified scale, and
18px body copy is reasonable on a phone. */
@media only screen and (min-width: 769px) {
body.page-id-2198 h1,
body.page-id-2572 h1,
body.page-id-2578 h1 {
font-size: 40px;
line-height: 48px;
}
body.page-id-2198 h2,
body.page-id-2572 h2,
body.page-id-2578 h2 {
font-size: 32px;
line-height: 40px;
text-transform: none;
}
body.page-id-2198 h3,
body.page-id-2572 h3,
body.page-id-2578 h3 {
font-size: 24px;
line-height: 32px;
}
/* :not(.large) protects the intro paragraph under the title, which is a deliberate
24px lede and not body copy. */
body.page-id-2198 .fl-rich-text:not(.large) p,
body.page-id-2572 .fl-rich-text:not(.large) p,
body.page-id-2578 .fl-rich-text:not(.large) p,
body.page-id-2198 .fl-rich-text:not(.large) li,
body.page-id-2572 .fl-rich-text:not(.large) li,
body.page-id-2578 .fl-rich-text:not(.large) li {
font-size: 16px;
line-height: 26px;
}
}
/* END :: Pre-Launch QA (Aug 10) */
/**********************************************************/
/**********************************************************/
/* START :: Individual Impact - background glow placement */
/**********************************************************/
/* 17 Aug (Leshan's lead) - the orange glow on the page background follows the viewport
down the page instead of sitting at one place in the layout, so it is still lit behind
Gear Up To Give Back and Experience A Trek, which the design has as plain ocean blue.
WHAT IT IS. animation.css paints the wash on the body of any page containing a row
tagged `row--glow-background`:
body:not(.fl-builder-edit):has(.row--glow-background) {
background: border-box var(--body) no-repeat fixed center -100px / cover,
var(--ocean) !important;
}
`fixed` is the defect. It makes the background positioning area the VIEWPORT rather
than the page, so `cover` scales the 2500x2500 source to 1920x1920 and only ever shows
a 749px-tall slice of it - the same slice, at the same screen position, at every scroll
offset. That slice happens to contain the olive blob, which is why the glow appears
welded to the right-hand side and tracks the reader all the way to the footer.
WHAT THE DESIGN HAS. Frame 11548 draws the wash as Rectangle 2383 - a 1364x4290 rect
parented to the page at y=259 in a 5021.67 frame. It scrolls with the content. Scanning
that rect for yellowness ((R+G)/2 - B, the one axis that separates the glow from the
26/50/66 ocean) puts the lit band at:
glow peak 32% of the rect = frame y 1632 = the top of Join The Charge
glow band 16% - 46% = frame y 945 - 2232
second, faint 59% - 66% = frame y 2790 - 3090
against sections at Cards 963-1564, Join The Charge 1627-2151, Gear Up 2227-2789 and
Experience A Trek 2789-3351. So the glow starts as the Cards row starts, peaks exactly
where Join The Charge begins, and has died out by the time Gear Up starts - and the
faint second one sits on Experience A Trek. That is the brief, to the pixel.
THE ASSET MATTERS. `--body` is `givepower-test-80pc` - a 2500 SQUARE whose blob is cut
off by its own top edge (already at peak yellowness on row 0) and which has no second
glow at all below 46%. That is fine while `fixed` hides every edge, and unusable once
the wash is anchored to the page: the top edge would show as a hard horizontal line and
Experience A Trek could never get its faint pass. `body-placeholder` is the tall artwork
the original (now dead) `main.fl-main-content` rule referenced - 1366x3432, both blobs,
soft top - and its profile matches the Figma rect's structure. The -scaled crop is the
same image at 1019x2560 and 56KB rather than 562KB, which for a 400px blur is free.
THE NUMBERS. Source blobs sit at 17.5% (main) and 60% (faint) of the artwork's height;
they have to land at page y 1658 and 2985 on this 5100px page. Two points fix the
scale and the offset: drawn height 3140px, top edge at page y 1130. Expressed as
percentages so it holds at any page height and any viewport width:
size 100% 61.6% 3140 / 5100
position center 57.7% a percentage position aligns the same percentage point of
image and box, so the offset is P x (5100 - 3140) = 1130
Not doable in Beaver Builder: the wash runs continuously across five separate rows, and
a BB row background stops at the row.
THE EDGES. Anchoring the wash to the page means its top and bottom edges are now on the
page too, and the artwork does not begin at ocean: a row scan across the background strip
found a single 15.3 step at the top edge, rgb(26,50,66) to rgb(34,55,64), against a mean
step of 0.43 over every other row. Lighter and warmer, but almost the same YELLOWNESS -
which is why the first scan of this passed it as clean, and why the seam has to be looked
for on brightness rather than on the axis being placed. The bottom edge goes the other way
(the artwork ends bluer than ocean); it currently lands behind the opaque cream Recognized
row, so it is invisible today and would not stay that way at another page length.
Both are feathered with an ocean-to-transparent gradient laid over the image, 3.5% of page
height each - about 180px here, which spreads an 8/255 step thin enough to be well under
any banding threshold. The transparent stops are written as `rgba(26, 50, 66, 0)` rather
than `transparent`, which is the same colour at zero alpha: it makes the intent explicit
and rules out any interpolation through transparent BLACK greying out the ramp. The fade
overlaps where the glow starts to lift, which softens its rise as well as hiding the edge
- that is the Figma behaviour anyway, where the wash ramps in over ~4% of the rect.
Scoped to this page deliberately. The shared rule is used by 28 posts, and re-anchoring
the background of the whole site is the lead's call, not a QA fix - lifting it is a
matter of dropping `.page-id-2943` from the selector. The `:has()` is carried over so
the override cannot outlive the rule it corrects, and it also settles specificity:
(0,3,1) against the theme's (0,2,1), so this wins regardless of stylesheet order. */
/* REVISED 17 Aug (Leshan): "the Figma has it between the Experience A Trek title and the
image" - ours had it hard against the left edge.
SAME FAULT AS THE PARTNER PAGE: the wrong image. Everything above this comment reasons
carefully about where to put `body-placeholder-1-scaled.jpg`, and that file is a placeholder,
not what frame 11548 draws. Measured on the two files, the design's lower blob peaks at
x41%; the placeholder's peaks at x15%. The left-hand glow was the placeholder's blob, and no
repositioning could ever have moved it - only the asset could.
Rectangle 2383 is now exported from the frame at full size, 1364 x 4290, and installed as
`individual-impact-background-wash.png` (attachment 2971). Scanned on the artwork itself:
main blob 33% of the wash, x99% -> frame y1632, the top of Join The Charge
lower blob 62% of the wash, x41% -> frame y2919
Experience A Trek is drawn at frame y2789, 562 tall, with its text at x72-650 and its photo
at x716-1294. So the lower blob sits 23% down that section and at x562 - in the gap between
the heading and the photograph, which is the note, exactly.
ANCHORED FROM THE BOTTOM OF THE PAGE, and that is the whole reason this rule looks different
from the 2945 one. Two things on this page do not render headless, and both are ABOVE
Experience A Trek, so every absolute Y measured from the top is wrong by an unknown amount:
the Donately embed reports height 0, so the hero measures 613 against a real ~1000
the impact tickers the data-storytelling row measures 1231 against a real ~711
Everything BELOW the Trek section measures identically either way, because nothing down
there depends on JS. Anchoring the wash to the bottom edge makes its position invariant to
whatever those two do above it - the same reasoning as pixels-from-the-top on 2945, applied
from the other end because on this page it is the top that cannot be trusted.
target blob at 23.1% down Trek = page y 3078, i.e. 2550 up from the page bottom
the blob sits 38% up from the wash's own bottom = 0.38 x 4290 = 1630
so bottom offset = 2550 - 1630 = 920
920 was the arithmetic; 871 is what it measures to. The two disagree because page height and
section tops drift 30-40px between identical headless runs on this page, so any figure
derived by subtracting one run's numbers from another's inherits that. The correction was
read off a SINGLE render instead, using the Trek photograph as the landmark - it measures
460 tall there against a drawn 460, so it can be trusted to place the row. Blob peaked 49px
high of target in that render, and a bottom offset moves the image down as it shrinks.
No gradient layer: the fade to ocean is baked into the PNG (180px at each end, measured to
land on #1A3242 exactly). A CSS gradient could not be anchored to the same origin as a
bottom-positioned image, and baking it in also makes the asset independent of page height.
Longhand rather than the `background` shorthand: a four-value position with a size after it
is legal but historically brittle in the shorthand, and each longhand here beats the theme's
!important shorthand on specificity anyway - (0,3,1) against (0,2,1).
Still scoped to this page. 28 posts carry `row--glow-background`; re-anchoring the whole
site is the lead's call, not a QA fix. */
body.page-id-2943:not(.fl-builder-edit):has(.row--glow-background) {
background-image: url(/wp-content/uploads/individual-impact-background-wash.png) !important;
background-repeat: no-repeat !important;
background-attachment: scroll !important;
background-position: left 50% bottom 871px !important;
background-size: 100% 4290px !important;
background-color: var(--ocean) !important;
}
/**********************************************************/
/* END :: Individual Impact - background glow placement */
/**********************************************************/
/**********************************************************/
/* START :: GivePartner 2026 - revisions 17 Aug */
/**********************************************************/
/* ---- background glow ------------------------------------------------------------------
Revised 17 Aug (Leshan): "the blurred circle is positioned above Corporate Treks" in the
frame, and on ours it sat out at the left edge.
THE PAGE WAS RUNNING THE WRONG IMAGE, and that is the whole fault. It used
`body-placeholder-1-scaled.jpg` - the filename is honest, it is a placeholder, and it is
NOT the artwork the design draws. Rectangle 2383 in frame 11544 and that JPEG are two
different pictures: measured on the files themselves, the design's lower blob peaks at
x41%, the placeholder's at x15%. The left-hand glow being reported was the placeholder's
blob, sitting where the placeholder happens to put it.
That also explains why the previous pass ended up squashing the rectangle to 2020px at
y1260. With the wrong artwork, no single placement can put both blobs where the frame puts
them, so one was lined up onto Built for Impact and the other went wherever it landed.
Fitting a rectangle to artwork that does not match the design is unwinnable; the fix is the
asset, not the arithmetic. Exported from the frame at full size and installed as
`givepartner-background-wash.png` (1366 x 2846, attachment 2969).
PLACEMENT - the frame states y674 and a 2846 height, but our build is not on the frame's
vertical rhythm below the carousel, so the drawn y cannot be used raw. Measured at a true
1366 viewport, with the marquee forced to one row (see below):
frame ours delta
carousel 1814 1678 -136
Treks card 2395 2305 -90
form 2828 2738 -90
From the carousel down the build runs a consistent 90px early, so the wash moves with it:
674 - 90 = 584. Checked against the artwork rather than assumed - its lower blob peaks at
62.1% of the wash, so 584 + 0.621 x 2846 = 2351, which is 14% down our card, exactly where
the frame puts it (2441 against a card at 2395, also 14%). The upper blob lands at 1153 and
its warm lobe at 1466, both inside Built for Impact (692-1678), which is where the earlier
revision asked for them.
MEASURING THIS PAGE AT ALL NEEDS TWO WORKAROUNDS, both of which fail silently:
- the testimonial row is a JS marquee that never initialises headless, so its items stack
and the row reports ~1575 instead of 563. Every absolute Y below it is then ~1000 out.
Force `.fl-col.marquee > .fl-col-content` to a nowrap flex before measuring.
- `--window-size=1366` reports a 1350 viewport, which is UNDER the 1366 breakpoint and
measures a different stylesheet entirely. Frame the page in an iframe of the exact
width and read the width back before trusting anything.
Edges feathered 180px into --ocean: measured, the artwork's own top row averages #1D3C4B
and its bottom #1B3544 against an ocean of #1A3242, so both would show as a seam. */
body.page-id-2945:not(.fl-builder-edit):has(.row--glow-background) {
background:
linear-gradient(to bottom,
var(--ocean) 584px,
rgba(26, 50, 66, 0) 764px,
rgba(26, 50, 66, 0) 3250px,
var(--ocean) 3430px),
url(/wp-content/uploads/givepartner-background-wash.png)
no-repeat scroll center 584px / 100% 2846px,
var(--ocean) !important;
}
@media only screen and (min-width: 993px) {
/* ---- Built for Impact -> Become a GivePartner ------------------------------------
The expandable list opens flush against the body copy: description ends 1336, the
accordion starts 1336. The frame puts Frame 11342 at y1402 against a description
ending at 1336.43, so the drawn gap is 65.57 - which is the 66 sizing unit, not a
loose number. Stated on the accordion rather than as a bottom margin on the rich
text, so it cannot also push the paragraph around inside its own module. */
.fl-builder-content-2945 .row--partner-bfi .fl-module-accordion {
margin-top: var(--Sizing-Units-L, 66px);
}
/* ---- video corner radius ---------------------------------------------------------
The poster image already carries 24 (`.fl-photo-img`, measured). What does not is the
player the Play Video button opens - `.uabb-video-wrap` and the modal inside it both
measure 0 - so that is what this rounds. The iframe needs it too: it is a separate
element and its own corners paint over a rounded parent unless the parent clips. */
.fl-builder-content-2945 .row--partner-bfi .uabb-video-wrap,
.fl-builder-content-2945 .row--partner-bfi .uabb-modal-iframe,
.fl-builder-content-2945 .row--partner-bfi .uabb-video-player {
border-radius: 24px;
overflow: hidden;
}
.fl-builder-content-2945 .row--partner-bfi .uabb-video-wrap iframe,
.fl-builder-content-2945 .row--partner-bfi .uabb-video-wrap video {
border-radius: 24px;
}
/* The photo's square bottom corners were fixed here first, page-scoped. The same fault
turned out to be QA #31 on /who-we-are/mission/ and to be present on /what-we-do/
approach/ as well, and its cause is one line in the component: the scrim carries
`border-radius: inherit` but the radius lives on the IMG, so it inherited 0. That is
now corrected at source in image-video.css, next to the scrim rule, conditioned on the
same classes that round the image - so this page-scoped copy is redundant and gone.
Verified after removal: photo-content 24px / overflow hidden on all three pages. */
/* ---- partner form, two columns ---------------------------------------------------
Drawn: card 578, padding 26, so 526 of content carrying two 250px columns with a 26
gap - Name | Email, then Organization | Job Title, with Website and Message running
the full measure. Ours renders all seven fields at the full 526.
A grid on the field container rather than WPForms' own `wpforms-one-half` classes,
which would be the builder-native answer but stack at WPForms' own 600px breakpoint.
The container is 526 at both 1920 and 1366 and drops to 339 at 992, so 993 is where
two columns stop fitting - which is also where the rest of this page's CSS is scoped.
`1fr 1fr` rather than the literal 250px: it resolves to exactly 250 at the drawn 526
and does not break if the card is ever re-measured.
Everything spans both columns by default and only the four paired fields opt out, so
a field added later inherits the safe full-width behaviour instead of silently
pairing with its neighbour.
FIELD IDS ARE LOAD-BEARING. Organization, Job Title and Website are all
`wpforms-field-text`, so class alone cannot tell them apart, and :nth-child cannot
either - field_2 is the anti-spam honeypot and WPForms MOVES IT AROUND THE DOM
between page loads (measured between Email and Organization at 1366, after Website at
1920). It is `position: absolute`, so it takes no grid cell wherever it lands, but any
positional selector here would be wrong on roughly every other load. If the form is
ever rebuilt these ids change with it. */
.fl-builder-content-2945 .row--form .wpforms-field-container {
display: grid;
grid-template-columns: 1fr 1fr;
column-gap: 26px;
}
.fl-builder-content-2945 .row--form .wpforms-field-container > .wpforms-field {
grid-column: 1 / -1;
}
.fl-builder-content-2945 .row--form #wpforms-2326-field_1-container,
.fl-builder-content-2945 .row--form #wpforms-2326-field_3-container,
.fl-builder-content-2945 .row--form #wpforms-2326-field_16-container,
.fl-builder-content-2945 .row--form #wpforms-2326-field_17-container {
grid-column: auto;
}
}
/**********************************************************/
/* END :: GivePartner 2026 - revisions 17 Aug */
/**********************************************************/