/* ========================================================================== Graintree Product Pages -------------------------------------------------------------------------- Every visual decision lives in the token block below. When the design lands, the expected change is: edit :root, swap the image sizes, adjust a handful of spacing values. Structure and behaviour do not move. Class prefix is gt- throughout so nothing collides with the theme. ========================================================================== */ /* -------------------------------------------------------------------------- 1. TOKENS Colours sampled directly from the designer's 2x Figma exports, 27 Aug 2026. Geometry measured off the same files. Type sizes are measured from ink extents and are accurate to about 2px; confirm against the designer's file on handoff. -------------------------------------------------------------------------- */ :root { /* ---- colour: exact, sampled ---- */ --gt-navy: #122B34; /* hero band, footer */ --gt-navy-2: #263846; /* underwriting band, accordion bars, ink */ --gt-paper: #F8F4F1; /* page background */ --gt-panel: #F5F5F5; /* open accordion panel, card fill */ --gt-card: #FFFFFF; /* underwriting + audience cards */ --gt-tile: #BDC6C4; /* Why Graintree tiles. Sampled from the final desktop export: mist tiles on a #F5F5F5 section. All four the same colour, confirmed 1 Sep. */ --gt-sage: #A7A499; /* mid-page CTA band */ --gt-mist: #BDC6C4; /* Built Around Relationships band */ --gt-bronze: #7E6D59; /* closing CTA band */ --gt-ink: #263846; --gt-on-dark: #F8F4F1; --gt-line: #263846; /* hairlines are the ink colour, not a grey */ /* legacy aliases so older rules keep resolving */ --gt-teal: var(--gt-navy); --gt-teal-2: var(--gt-navy-2); --gt-paper-2: var(--gt-panel); --gt-slate: var(--gt-navy-2); --gt-slate-lt: var(--gt-sage); --gt-muted: var(--gt-ink); /* ---- type ---- */ /* The theme registers the brand faces under generic @font-face names in landing-page-theme/style.css, not under their real names: MyCustomFont = TYSerif-D (The Youngest Serif) MyCustomFont2 = Aktiv Grotesk (regular / bold / italic) MyCustomFont3 = SweetSansProBold (declared at weight 400) The alias has to come first or the whole page silently falls back to Georgia and a system sans. Real names are kept after it so this still works if the theme is ever tidied up. */ --gt-serif: "MyCustomFont", "The Youngest Serif", Georgia, "Times New Roman", serif; --gt-sans: "MyCustomFont2", "Aktiv Grotesk", -apple-system, "Segoe UI", Helvetica, Arial, sans-serif; --gt-label: "MyCustomFont3", "Sweet Sans Pro", var(--gt-sans); /* Type is FIXED, not fluid. The 1440 and 1024 exports carry byte-identical type: eyebrow 182px wide, h2 602.5px, lede lines 705 / 727.5 / 696, tiles 715.5px. The design does not scale between those two frames, it re-centres. Sizes below are solved from the exports: the string is measured in the export, the same string is measured live at a known size, and the ratio gives the size. That is far more reliable than reading cap heights. The mobile step is at 600px, matching the theme's own breakpoint. */ --gt-h1: 76px; --gt-h1-lh: 82.2px; /* KENDRA'S TYPESCALE, sent 2 Sep 18:34. This is the authority now. The designer's first email said H2 36/38.2; the correction explains why: the designer's Figma scale had a "Display" row at the top that has no HTML equivalent, so every name was off by one. 36/38.2 is H3. It also validates the string-measurement method: every solved value came in within about a pixel of the designer's spec. */ --gt-h2: 52px; --gt-h2-lh: 53.2px; --gt-h3: 36px; --gt-h3-lh: 38.2px; --gt-h4: 24px; --gt-h4-lh: 38.2px; --gt-body-lg: 19px; /* section and hero ledes */ --gt-body: 16px; --gt-body-lh: 25.5px; /* Body 1 */ --gt-caption: 14px; --gt-caption-lh: 19.9px; --gt-small: 16px; --gt-lbl: 16px; /* Eyebrow 1. Eyebrow 2 is 13px, used below 600 */ --gt-lbl-ls: .2em; --gt-base: 17px; /* ---- geometry: measured ---- */ /* The theme's header is `.top-band { padding-left: 5vw }`, flush left with no max-width. Matching it is what puts our copy on the same line as the logo, which is what the design shows and what every other page does. At 1440 this gives a 1296px content width against the export's 1320. */ --gt-max: none; --gt-gut: max(20px, 5vw); /* The HERO's left edge, which is not the body gutter. Julian, 9 Sep: "in all the pages the main heading aligns left with the logo except for Residential Lending". He is right, and the site has a convention we were not following. Measured on /about-us/ at 1512: logo left 56.0 hero heading "About" left 56.0 <- flush with the logo body headings, Our Mission left 75.6 <- the 5vw gutter So the hero heading aligns with the logo and everything below it sits on the wider gutter. Our hero used --gt-gut for both, which put the h1 at 75.6 and 19.6px right of the logo. The gap grows with the window, because 56px is fixed and 5vw is not: 40px out at 1920. 56px because that is the horizontal padding in the designer's header CSS (`.top-band { padding: 16px 56px }`, 24px 16px on mobile). THIS VALUE HAS TO TRACK THAT ONE. If the header padding changes, change this with it or the hero drifts off the logo again. */ --gt-edge: 56px; --gt-band: 72px; /* Designer, 2 Sep: 72 top and bottom on all components */ --gt-row-h: 70px; /* accordion bar height, measured 69–70 */ --gt-btn-h: 47px; /* measured 286 x 47 */ --gt-btn-px: 32px; --gt-radius: 2px; /* Designer, 4 Sep: 2px on all buttons. Only the buttons use this token; every other corner in the design is square or has its own value. */ --gt-gap: 24px; --gt-nav-h: 58px; /* Card width lives here because the row's side padding is derived from it: the padding has to be half the row minus half a card, or the first and last card can never reach the centre. */ --gt-uwc-w: clamp(260px, 29vw, 428px); /* ONE GRADIENT FOR EVERY WIDTH, anchored in px rather than percentages. Julian, 5 Sep: he wants it to reach 0 at the right edge, and it does. The percentage version could not: the copy takes a bigger share of a narrow window, so a 45% midpoint left the text sitting in the faded part. Measured with the last stop at 0: the h1 fell to 1.59:1 at 1024 and the lede to 2.49:1, both far under AA. Anchoring the midpoint at 1000px instead means the strong part always covers the measure, whatever the window, and the fade happens in the right-hand third where no text ever goes. Composited against the real photograph at nine widths from 393 to 2560: the h1 never drops below 8.2:1 and the lede never below 8.4:1. That is better than the three separate gradients it replaces, so the tablet and mobile overrides are gone too. Re-measure if the photograph is ever swapped. SUPERSEDED 8 Sep on the call. The designer asked for a flat overlay at 40% and no gradient: "instead of a gradient that like 70% of the image is darkened, the whole thing is darkened, but only to like 40% opacity", and "if we have to darken it more, then we can show Ashley what it looks like with a slightly darker opacity". So flat it is, and the number below is the one to argue about, not the shape. MEASURED ON THE REAL FILE, and 40% does not pass. Compositing the photograph Ashley licensed under a flat overlay, headline against background, at 393 / 768 / 1024 / 1512 / 1920: SHIPPING 45%, Julian's call on 8 Sep. Below is what that costs, measured, so the decision is on the record rather than assumed. The first pass of this measurement applied 4.5:1 to everything, which was wrong. WCAG splits the threshold by type size, and the two pieces of hero copy land on opposite sides of it: h1 76px regular -> LARGE text -> 3.0:1 lede 19px regular -> normal text -> 4.5:1 Re-measured against the licensed photograph at six widths, 393 to 2560, reporting both the worst pixel and how much of each text area misses: overlay h1 worst h1 under 3.0 lede worst lede under 4.5 40% 2.22 0.75% 2.35 25.7% 45% 2.52 0.02% 2.63 19.4% 55% 3.31 0.00% 3.37 3.3% 66% 4.59 0.00% 4.52 0.0% So at 45% THE HEADLINE IS EFFECTIVELY FINE. 0.02% of its area misses 3:1, which is a handful of pixels against the brightest part of the sky, not something a reader meets. The failure is the LEDE, and it is not marginal: about a fifth of that paragraph sits under 4.5:1. No type change rescues it. Taking the lede to 24px would make it large text at a 3:1 threshold, but 45% only reaches 2.63, so it still misses. The two things that would actually fix it at 45%: 1. Regrade the photograph to 65% brightness or darker. Measured: the lede then reaches 4.79:1 at 45%. This is the option that gives the designer the light overlay she wanted AND passes. 2. Back the copy column only, which means a second scrim, which is the gradient she asked us to remove. Left as a live decision rather than quietly fixed. tools/scrim.py and tools/correct.py reproduce all of the above. Re-measure if the photograph is ever swapped or regraded. */ --gt-hero-scrim: linear-gradient(rgba(18,43,52,.45), rgba(18,43,52,.45)); --gt-ease: cubic-bezier(.4, 0, .2, 1); /* Accordion motion. Read by product-page.js, so the pace is a CSS decision and the designer can retune it without touching the JavaScript. These match the site's existing motion vocabulary rather than a number I invented. From the theme, 7 Sep: headline-reveal.js 1.6s, GSAP power3.out, 0.18s stagger animation.js CROSSFADE_MS = 1100, ease customizer-additional.css, the
rule 1s ease Everything on this site moves slowly and decelerates. Our first pass ran the accordion at .55s on --gt-ease, which is a symmetric in-out curve at roughly half the site's duration, and it read as snappy against the rest of the page. The .55s came from the anchor-link pace the designer asked for on 4 Sep, applied to the accordion by me. She has never actually seen this animate, because until v0.4.4 it did not. The ease is easeOutQuart, which is the CSS equivalent of the theme's power3.out: quick to start, long slow settle. The fade outlasts the height by design, so the panel finishes moving before it finishes arriving. */ --gt-acc-dur: .8s; --gt-acc-fade: 1s; --gt-acc-ease: cubic-bezier(.165, .84, .44, 1); /* In-page anchor scrolling, read by initSmoothAnchors in product-page.js. Julian, 9 Sep: the hero buttons should scroll "aligned with animation timing of other items". Same duration as the accordion, and the JS uses easeOutQuart, which is the curve --gt-acc-ease approximates. Kept as its own token because a long page may want a longer travel than a panel. */ --gt-scroll-dur: .8s; /* floor: short hops move at the accordion's pace */ --gt-scroll-max: 2.2s; /* ceiling: the full-page trips, #contact included */ } /* -------------------------------------------------------------------------- 2. SCOPE + RESET Only applies inside .gt-page so the rest of the site is untouched. -------------------------------------------------------------------------- */ /* SCOPE. .gt-page sits on , so anything scoped to it also restyles the theme's header, nav and footer. That is how the site nav lost its serif and picked up our body sans. Our own section roots are the correct scope; the editor canvas contains only our content, so it can stay broad. */ :is(.gt-hero, .gt-band, .gt-close, .gt-cta-band, .editor-styles-wrapper) { color: var(--gt-ink); font-family: var(--gt-sans); font-size: var(--gt-base); line-height: 1.6; } /* Scoped to our own sections, not the whole body. .gt-page sits on , so a blanket reset here also reaches the theme's header, nav and footer. */ :where(.gt-hero, .gt-band, .gt-close, .gt-cta-band) :is(*, *::before, *::after) { box-sizing: border-box; } :is(.gt-hero, .gt-band, .gt-close, .gt-cta-band, .editor-styles-wrapper) img { max-width: 100%; height: auto; display: block; } :is(.gt-hero, .gt-band, .gt-close, .gt-cta-band, .editor-styles-wrapper) :is(h1, h2, h3, h4) { font-family: var(--gt-serif); font-weight: 400; margin: 0; letter-spacing: -.005em; /* explicit: the theme sets a bare `h2 { color: #000 }`, which beats the colour inherited from .gt-page */ color: var(--gt-ink); } :is(.gt-hero, .gt-band, .gt-close, .gt-cta-band, .editor-styles-wrapper) p { margin: 0; } :is(.gt-page, .editor-styles-wrapper) section { scroll-margin-top: calc(var(--gt-nav-h) + 10px); } /* This theme is classic, with no theme.json, so WordPress serialises every core/group as
and the editor bakes that wrapper into the post content on save. Without this rule every grid and flex container below sees exactly one child and collapses: the four tiles stack, the card row becomes one column, the audience cards go full width. display:contents takes the wrapper out of layout while leaving it in the DOM. It carries no background, border or padding of its own, so nothing is lost. Selectors below use descendant combinators rather than `>` so the same CSS is correct whether the wrapper is there or not. */ :where(.gt-hero, .gt-band, .gt-close, .gt-cta-band) .wp-block-group__inner-container { display: contents; } /* THE CLIPPED LOGO AND THE 18px GAP WERE ONE THEME RULE. Found 4 Sep, in themes/landing-page-theme/customizer-additional.css: body:not(.home) .wp-block-group.top-band { padding-bottom: 0vw !important; } Every page except the home page has its header band's bottom padding zeroed. The band then sizes to the nav row alone (76.4px), while the site logo is absolutely positioned and runs to 94.3px, so it hung 18px out of the band on every inner page. That overhang WAS the "18px gap": measured band bottom 76.4, hero top 94.4, and the body's cream showing through between them. Giving the padding back fixes both at once. Measured after: 36px of clear navy below the logo and a gap of exactly 0. The navy cover strip that used to paint over the gap is gone with it, since there is no longer a gap to cover. The selector has to match the theme's specificity to beat its !important: `body:not(.home) .wp-block-group.top-band` is (0,3,1), so ours is too and wins on order, this stylesheet being the later one. Delete both rules from the theme file and this can go. SUPERSEDED 8 Sep, by the designer's own Customizer CSS: .custom-logo { width: 12em } body.gt-page .wp-block-group.top-band { padding: 16px 56px !important } Identical selector to ours, therefore identical specificity, and the Customizer prints after this stylesheet, so her shorthand wins and our padding-bottom never applies. That is fine, because it is no longer needed: measured on dev 8 Sep, band 80px tall, logo 192 x 46 sitting at top 16 and bottom 62, entirely inside the band. **The clipping is gone because the logo is smaller now, not because of the padding.** Our rule is removed rather than left in to look like it is doing something. THE DEPENDENCY, worth knowing: the two halves of her block travel together. Remove `.custom-logo { width: 12em }` without also restoring padding and the 275px logo overhangs an 80px band again. */ /* The designer, 4 Sep: "cannot tell what is producing that cream spacing between the brown container and the footer?". It is this page's Spectra block custom CSS, `footer { position: relative !important; bottom: -20px !important }`. The footer is pushed down 20px and the body's cream shows through behind it. (Deleted by accident in v0.4.1 along with the top-band block, and the gap came straight back. Restored in v0.4.2.) */ .gt-page footer { bottom: auto !important; } /* -------------------------------------------------------------------------- FOOTER LICENSING DISCLOSURE. Ashley, 9 Sep: required by compliance, this page only for now. The markup lives in the theme's footer.php behind a `gtpp_is_product_page()` guard, not here. A legal notice has to render server-side with the page, so it cannot be injected by script, and putting it INSIDE