/** * Dealer-FX Brand Base / Global Overrides * ----------------------------------------------------------------------------- * Applies the brand tokens to global elements on top of the parent theme. Component- * level styling (specific modules, headers, footers) should live in their own * enqueued stylesheets that also depend on brand-tokens. * * Depends on: brand-tokens.css (CSS custom properties) * Note: the parent theme carries high selector specificity, so a few rules use targeted * overrides. These are intentionally conservative global foundations. */ /* --- Layout: content container width ---------------------------------------- */ /* THE CONTAINER WIDTH IS SALIENT'S TO DECIDE NOW. Theme Options › General Settings › Functionality › "Max Website Container Width" sets it, and this file no longer argues with the result. WHAT USED TO BE HERE, AND WHY IT WENT. Three rules pinned the container to a 1280px token: an override of Salient's own `--container-width`, a `max-width` on `.container` prefixed with `html body` to outrank `body[data-header-format="left-header"] .container`, and the block editor's content size. The reason was sound — Salient's slider floor is 1425px, so a narrower site genuinely cannot be set in the UI — but the consequence was that the Theme Options field did nothing, silently, from four files away. A setting that looks live and is inert costs more than the 145px it was buying. ONE LINE SURVIVES, and it is not an override: the block editor's content size has no Salient equivalent, so it is pointed at the token, which now reads Salient's value. Blocks therefore stay aligned with the container instead of ignoring it. TO GO NARROWER AGAIN, put a length back in --dfx-container-width rather than restoring these rules. One value, one place, and the Theme Options field is then knowingly inert rather than accidentally so. */ html body { --wp--style--global--content-size: var(--dfx-container-width); } /* --- Typography: body -------------------------------------------------------- */ body, .container-wrap, p, .wpb_text_column, input, textarea, select, button { font-family: var(--dfx-font-body); } body { font-weight: var(--dfx-weight-body); line-height: var(--dfx-line-height-body); color: var(--dfx-color-body); } /* --- position: sticky, made possible --------------------------------------------- `body { overflow: hidden }` arrives from the parent theme, which needs it to stop full-bleed rows widening the document. The side effect is that it makes BODY a scroll container, and a scroll container that never scrolls — `html` is the scroll port here. Every `position: sticky` inside body therefore resolves against a box that has no scroll position, so it pins to nothing and behaves as `static`. MEASURED, NOT REASONED: a sticky probe at body level sat at -1297px with the parent theme's value and at 72px with the two below. `clip` RATHER THAN `visible` ON THE X AXIS, so the containment survives. `clip` does not create a scroll container, which is the whole difference, and it is the one value that legally pairs with `overflow-y: visible` — `hidden` would force the y axis back to `auto` and put us where we started. WHAT THIS FIXES BEYOND THE TABLE: `.dfx-integrations-grid__filter` has been declared sticky since the integrations wall was built and has never held, for this reason. It was written as "pins under whatever the header leaves" and pinned to nothing. THE FALLBACK IS TODAY'S BEHAVIOUR. A browser without `overflow: clip` — Safari before 16 — drops both declarations as invalid and keeps the parent theme's `hidden`: containment intact, sticky inert, exactly as now. */ body { overflow-x: clip; overflow-y: visible; } /* --- Typography: heading hierarchy ------------------------------------------ */ /* NOTE — OF THE THREE PROPERTIES BELOW, ONLY font-family LANDS ON H4–H6 FROM THIS RULE. All three are re-declared at higher specificity further down. Salient's generated `body h4` (salient-dynamic-styles.css) is specificity 0-0-2 and beats the bare `h4` here at 0-0-1, so anything this rule alone declares for h4–h6 is overruled. LINE-HEIGHT escalated — see the block three below. FONT-WEIGHT escalated — see the block immediately below. LETTER-SPACING escalated at ALL SIX levels — see the block two below, and read it before trusting anything about tracking. This was documented for a long time as a single CONCESSION affecting h4–h6, on the reasoning that h1–h3 already got the token and 0.01em is not visible anyway. Measuring the rendered page showed the token was live on none of the six: h1 came out at Salient's -0.015em, h3 at ZERO, and h2 at -0.01em only because Salient's h2 value happens to equal ours. That coincidence is what kept the concession looking half as large as it was. All three properties are still declared here, harmlessly, so this rule reads as the whole heading treatment anywhere Salient's generated file is absent — the editor, an unstyled context, or a future theme swap. Flagged here so the next person does not spend an afternoon proving the tokens are being ignored. */ h1, h2, h3, h4, h5, h6, .nectar-fancy-heading, .nectar-fancy-box h2, .wpb_wrapper h1, .wpb_wrapper h2, .wpb_wrapper h3, .wpb_wrapper h4, .wpb_wrapper h5, .wpb_wrapper h6 { font-family: var(--dfx-font-heading); line-height: var(--dfx-line-height-heading); letter-spacing: var(--dfx-letter-spacing-heading); /* Color is NOT set here — see the heading-color block below. It cannot be a flat declaration on this rule, for the reason the previous comment gave. */ } /* ============================================================================ HEADING COLOR — the one place a heading gets a color, and it is indirect. ============================================================================ THE PROBLEM THIS SOLVES. Headings used to declare no color at all and simply inherit from body, which is why they were the same ink as body copy: there was no heading color to be inconsistent with. The comment where this rule now sits said "headings inherit their context", and that was load-bearing, not lazy — a dark full-width section sets `color` on its wrapper and every heading inside goes light for free. SO WHY NOT JUST DECLARE A COLOR. Because inheritance loses to any direct declaration, always, at any specificity. `body h2 { color: … }` on the heading beats a `color` set on the section wrapper the heading sits inside — so a flat heading color turns every heading on a dark band graphite-on-obsidian. On the homepage alone that is 14 headings: 11 under Salient's `.light` marker and 3 under a column carrying an inline color from the page builder. THE INDIRECTION. The color is read from --dfx-heading-ink, a custom property, and custom properties DO inherit. Any context that owns its text color re-points the property for everything beneath it, and the heading rule below picks that up without knowing the context exists. `currentColor` INSIDE THE color PROPERTY MEANS "the inherited color" — that is the spec behavior, not a trick — so re-pointing the property at currentColor restores exactly the old inherit-from-context result. THE THREE ESCAPE HATCHES, and why each is needed: .light Salient's marker for a section with LIGHT TEXT (the name describes the text, not the background — it is the dark-band class). 11 of the 14 homepage cases. .dfx-band This theme's own dark band; already sets --dfx-band-heading, so headings track that instead. [style*="color"] A page-builder column with an inline color. This DELIBERATELY over-matches — `background-color` contains the substring too — and over-matching is the safe direction: a false positive means the heading inherits, i.e. the behavior that shipped for the last year. A false negative would be a silent contrast regression on a dark band. When the inline colors are stripped from builder content this hatch stops firing on its own and can be deleted. SPECIFICITY MIRRORS THE WEIGHT AND LINE-HEIGHT BLOCKS BELOW, and for the same reason: salient-dynamic-styles.css ships `body, body h1, … body h6 { color: var(--nectar-page-text-color, #525967) }` at 0-0-2 from its Typography options. #525967 is not in the Dealer-FX palette at all. A bare `h2` at 0-0-1 loses to it; `body h2` ties at 0-0-2 and wins on load order. `.row .col h*` is included because Salient ships the same value three ways and `body h4` alone leaves every heading inside a builder column untouched — the size scale already works around exactly this. Salient's own Text Color option should also be set to #424752 in Theme Options so the generated file agrees with the token instead of being overridden. That is a database change, not a code one; it is tracked with the builder cleanup. */ :root { /* SALIENT'S OWN LIGHT-TEXT COLOR, SET FROM THIS FILE RATHER THAN FOUGHT. The parent theme paints every element inside a `.light` section — its dark-band marker — with `color: var(--nectar-font-light-color, #fff)` at 0-1-1, which outranks the heading and label rules below. The variable is populated from Theme Options and resolves to Steel Gray #9AA0A6 here, so "light" text on a dark band was a mid gray: legible at 6.35:1, but it also sat DIMMER than the muted labels beside it, inverting the one relationship the label ink exists to express. DEFINING THE PARENT THEME'S OWN CUSTOM PROPERTY IS THE CHEAP WAY IN. Salient's rule already reads it, so pointing it at Signal White makes that rule produce the right answer — no escalation, no new selectors, no !important, and the 0-1-1 rule that used to be a problem becomes the thing doing the work. Headings on a dark band now render Signal White at 15.5:1 and labels sit behind them at 8.16:1. AND IT IS DELIBERATELY NOT A THEME OPTIONS CHANGE. The obvious fix is to set the light font color in the options panel, and this project has already learned why not: those values live in the WP database, are invisible to git, differ per environment, and do not survive a Kinsta rebuild. The footer background was moved out of Theme Options into CSS for exactly this reason, and the footer heading color shipped wrong on staging twice because it was left to the database. The rule this file states elsewhere applies here too — if the design decides a property, this file states it. */ --nectar-font-light-color: var(--dfx-signal-white); --dfx-heading-ink: var(--dfx-color-heading); /* The label step's ink, indirect for exactly the same reason and re-pointed by the same list below. h6 is muted secondary rather than heading ink, because a label annotating a set should sit under its contents rather than compete with them. */ --dfx-label-ink: var(--dfx-color-text-muted); /* THE COLUMN-HEAD INK, SPLIT OFF FROM --dfx-label-ink AT DAVE'S DIRECTION 2026-08-12. Two consumers only: the footer widget titles and the megamenu column heads — the caps labels that sit above a list of links. Everything else reading the label role (.dfx-eyebrow, the "Trusted by" separator) stays on Pewter via --dfx-label-ink, which is what "it can stay pewter by default" means. THIS IS A KNOWN AA FAILURE AND IT IS DELIBERATE. Steel Gray is 2.64:1 on white against the 4.5:1 that WCAG AA requires for normal text — and these do not qualify for the 3:1 large-text allowance either, since that needs 24px, or 18.66px at bold, and these are 13px. So they fail both bars. Pewter, which they read until today, is 5.11:1 and passes. Dave was shown these numbers and chose Steel for the quieter look; recording the trade here rather than in a ticket so the next person to measure the footer finds the reason instead of re-reporting the bug. IT IS ALSO A REGRESSION OF A FIX MADE EARLIER THE SAME DAY, which is worth being plain about: the megamenu heads had just moved off Salient's Steel Gray onto Pewter, which is what retired the long-standing "column heads under AA" item. That item is open again by choice. The difference from before is that the value is now stated here, in git, identically on both environments, rather than arriving from the database — so it is a decision instead of an accident. INDIRECT, NOT A HEX ON THE RULES, so the dark-band list below can re-point it and so reverting is one line. To go back to a passing ratio, point this at var(--dfx-label-ink); Nickel #6F7688 at 4.54:1 is the lightest step on this hue that still clears AA, if something between the two is ever wanted. */ --dfx-column-head-ink: var(--dfx-steel-gray); } .light, .dfx-band, /* The product card is a dark context of its own — see .dfx-card--product in components.css, which sets a dark fill and a light `color`. Without this entry the `body h3` rule below would paint its title Graphite #2B2F36 on Obsidian #141E2C at 1.25:1, because that rule is 0-0-2 and the card's own `color` is 0-1-0 on an ancestor. Joining this list is the fix rather than overriding the title, so the badge and any future heading inside the card inherit the same way. */ .dfx-card--product, [style*="color"] { --dfx-heading-ink: currentColor; } /* THE LABEL INK ON DARK SURFACES, AND IT IS NOT A MIX OF currentColor — THAT WAS TRIED AND IT FAILED IN THE BROWSER. The reasoning behind the first attempt was sound: a heading on a dark band should take the band's full text color, so currentColor is right for --dfx-heading-ink, but a label should stay SUBDUED relative to that text, so 70% of it seemed like the same idea one step back. WHAT THAT MISSED is that currentColor is only the band's text color if nothing between the band and the element has changed it. On the homepage something has: the "Trusted by" separator sits under a builder column carrying an inline `color:#9AA0A6`, so currentColor was ALREADY a muted gray and taking 70% of it composited down to 1.19:1 on Obsidian. Measured, not predicted — the rule looked correct and rendered unreadable. SO THE MIX KEYS OFF THE BAND'S OWN TOKEN INSTEAD, with Signal White as the fallback. That is the same `--dfx-band-heading` pattern the band components in components.css already use for subdued text, and it cannot be polluted by an inline color halfway down the tree. On Obsidian it lands at 7.7:1. THE INLINE-COLOR HATCH IS SPLIT OUT BELOW because it is the one case where the surface is genuinely unknown — [style*="color"] deliberately over-matches and catches `background-color` too, so it can fire on a light surface as easily as a dark one. A light-on-light label would be the same bug in the other direction. */ .light, .dfx-band, .dfx-card--product { --dfx-label-ink: color-mix(in srgb, var(--dfx-band-heading, var(--dfx-signal-white)) 70%, transparent); } /* UNKNOWN SURFACE: INHERIT EXACTLY, and give up the step-back rather than guess. A label the same color as its heading is a missed nuance; a label the same color as its background is a bug. This rule comes after the one above so an element carrying both .light and an inline color takes this safer branch. */ [style*="color"] { --dfx-label-ink: currentColor; } /* ============================================================================ .dfx-accent — BRASS, OPT-IN, AND DARK SURFACES ONLY. ============================================================================ WHY THIS EXISTS. .dfx-eyebrow used to declare `color: var(--dfx-brass)` as its DEFAULT, which had it backwards twice over. Brass is 2.29:1 on Signal White, so the default state of a label utility was a contrast failure on the site's base surface. And the brand reserves Brass for premium, high-emphasis moments at "maximum restraint" — a color you are told to use sparingly cannot also be what you get by not choosing. Now the default is --dfx-label-ink (Pewter, 4.72:1) and Brass is something you ask for. IT RE-POINTS THE INK RATHER THAN SETTING color, which is the whole reason it is worth having as its own class. `color: brass` would only ever fix the one element it is on. Re-pointing --dfx-label-ink means this works on .dfx-eyebrow, on h6 and .dfx-h6 labels, on the separator, and on anything added later that reads the label role — and because custom properties inherit, it can go on a wrapper and take everything beneath it with it. DARK SURFACES ONLY, AND THAT IS NOT A STYLE PREFERENCE. Measured against the two base surfaces: Brass #B5A46A 2.29:1 on Signal White 6.78:1 on Obsidian Gold #C5A84D 2.14:1 7.26:1 Amber #C47E3A 3.04:1 5.11:1 Sienna #A0522D 5.19:1 2.99:1 The premium family is a dark-surface family. Sienna is the only member legible on light and it is the only one that fails on dark, so there is no accent that works everywhere — which is why this class does not try to be surface-aware. Resolving to a different hue per surface was considered and rejected: gold on dark and burnt orange on light reads as two brands, and a class that silently changes color is harder to reason about than one that is simply documented. Use it on bands, cards and imagery. On Signal White it will fail AA, visibly and predictably. LAST IN THE INK RULES ON PURPOSE. It sits after the dark-band hatches and the inline-color hatch, all at 0-1-0, so an explicit opt-in beats an automatic re-point when both land on one element. Asking for accent should win. */ .dfx-accent { --dfx-label-ink: var(--dfx-brass); } /* SALIENT'S .light MARKER OUTRANKS BOTH LABEL RULES, AND THAT MADE .dfx-accent INERT WHERE IT MATTERS MOST. Found by measuring, not by reading. The parent theme's style.css ships `.light h1, … .light h6, .light p { color: var(--nectar-font-light-color, #fff) }` at 0-1-1. That beats `.dfx-eyebrow` at 0-1-0 and `body h6` at 0-0-2, so on any section carrying .light — Salient's dark-band marker, and 11 of the 14 dark headings on the homepage — the label's color came from the parent theme and NOTHING in the label-ink system applied. THE CONSEQUENCE WAS NOT A CONTRAST FAILURE, WHICH IS WHY IT WOULD HAVE SURVIVED A CASUAL CHECK. Salient's light-font color resolves to Steel Gray here, 6.35:1 on Obsidian, perfectly legible. Two real things were still broken: labels and headings both rendered the same gray, losing the step-back the muted ink exists to draw; and .dfx-accent did nothing at all on .light bands, i.e. the opt-in was dead in precisely the place it is documented as being for. THE ESCALATION IS THE SAME SHAPE THIS FILE USES FOR SIZE, WEIGHT AND LEADING. `.light .dfx-eyebrow` is 0-2-0 and beats `.light p` outright; `.light h6` and `.light .dfx-h6` tie Salient's 0-1-1 and win on load order, as this file already relies on elsewhere. Three selectors, and they restore the whole ink system — including the accent — inside dark bands. */ .light .dfx-eyebrow, .light h6, .light .dfx-h6 { color: var(--dfx-label-ink); } body h1, body h2, body h3, body h4, body h5, body h6, .row .col h1, .row .col h2, .row .col h3, .row .col h4, .row .col h5, .row .col h6, .wpb_wrapper h1, .wpb_wrapper h2, .wpb_wrapper h3, .wpb_wrapper h4, .wpb_wrapper h5, .wpb_wrapper h6 { color: var(--dfx-heading-ink); } h1, h2, h3 { font-weight: var(--dfx-weight-heading); } h4, h5 { font-weight: var(--dfx-weight-heading-light); } /* h6 IS NOT IN THAT SECOND LIST ANY MORE. It is the label step and takes 600 from the label block at the bottom of this section, not 500 from the small-heading pair. */ /* H4–H6 WEIGHT, ESCALATED TO 0-0-2 / 0-2-1 FOR THE SAME REASON AS LINE-HEIGHT. Salient's generated file sets `body h4` and `.row .col h4` to 500 while setting h5 and h6 to 600, all of which outrank the bare rule above. The result was three sibling levels running two different weights, neither of them the token's — a 24px H4 at 500 sitting under a 40px H2 at 600, and h6 heavier than the h4 above it. THE RULE IS STILL REQUIRED THOUGH THE SPLIT IS OFF. --dfx-weight-heading-light points at --dfx-weight-heading as of 2026-08-14, so all six levels are 600 — but Salient still ships 500 on `body h4`, so removing this would put h4 back to 500 while h5 sat at 600. The rule fights the parent theme; the token decides the value. NO .dfx-h* CLASSES IN THIS LIST, DELIBERATELY. Weight follows the LEVEL in this theme — the pairing table's job is size — so `h2.dfx-h4` is 20px at its own h2 weight. With both tokens at 600 that distinction is invisible again, as it was before the split; the h3.dfx-h5 / h4.dfx-h5 collision the split produced is gone. No !important needed — Salient declares none on these, unlike the vc_custom_heading line-height below. */ body h4, body h5, .row .col h4, .row .col h5, .wpb_wrapper h4, .wpb_wrapper h5 { font-weight: var(--dfx-weight-heading-light); } /* HEADING TRACKING, ESCALATED AT ALL SIX LEVELS — and the audit that produced this rule is the reason it covers six rather than the three it started as. WHAT THIS WAS MEANT TO FIX. --dfx-letter-spacing-heading was believed live on h1–h3 and conceded on h4–h6, where Salient's generated -0.02em beat the bare grouped selectors in the heading block above. So the first version of this rule escalated h4–h6 only, to close what looked like a half-applied token. WHAT MEASURING THE RENDERED PAGE FOUND. The token was live on NONE of the six. Salient's generated file ships three different tracking values, each at a specificity the bare `h1`–`h6` rule cannot reach: #page-header-bg h1, body h1, body .row .col.section-title h1, … -0.015em #page-header-bg h2, body h2, … -0.01em body h3, .row .col h3, … 0 h1 rendered -0.015em. h3 rendered ZERO — no tracking at all, on the step that carries most section headings. And h2 rendered -0.01em, which IS the token's value, so h2 looked like proof the token was working. It was a coincidence, and it is why the concession was believed to stop at h4 for as long as it did. One level accidentally correct is worse than none correct, because it makes the other five look deliberate. SO THIS COVERS THE WHOLE LADDER. Three levels are the fix that was asked for and three are the correction the measurement forced; there is no version of this that only needs half. If a future value is ever split by size the way leading is, split this rule then — not now, on the assumption that h1–h3 are already fine. THE SELECTOR LIST IS THE WEIGHT RULE'S, EXTENDED — not a new pattern. Same three families, same 0-0-2 / 0-2-1 ties, same reliance on this file loading after the generated one. Nothing here needs !important; Salient declares none on tracking. The page-header h1 needs one further escalation, for exactly the reason size and leading already do — see the block below. NO .dfx-h* CLASSES, MATCHING THE WEIGHT RULE RATHER THAN THE LINE-HEIGHT ONE. Tracking is a property of the type at a given size, so an argument exists for the other choice — but the token is a single value across all six steps, so a borrowed size gets the same tracking either way and adding the classes would buy nothing while implying the value varies. SUPERSEDED — the token is no longer a single value and the classes are now in the list. Left here because the reasoning is still the right reasoning for a flat token, and the condition it depended on is named in it. See the band split below. ONE CONSEQUENCE WORTH NAMING: .dfx-hero__eyebrow in components.css already computed -0.01em from this token, and a real h4 beside it computed -0.02em. That mismatch was documented there as invisible-but-known; it is now simply gone. */ /* SPLIT BY SIZE NOW, WHICH IS THE THING THE PARAGRAPH ABOVE SAID TO DO WHEN THE VALUE STOPPED BEING SINGLE. Three bands: h1, then h2+h3, then h4+h5. h6 is absent from all of them because it is the caps label step and carries +0.14em of its own. THE .dfx-h* CLASSES ARE NOW IN THIS LIST, WHICH REVERSES THE NOTE ABOVE, and the measurement is what reversed it. The old note left them out because one flat value made a borrowed size track identically either way — true then, false the moment the value split by band. My first version of this rule kept them out anyway and argued the mismatch was negligible: 0.01em on a 20px heading, a fifth of a pixel per character. THEN I MEASURED A PRODUCT PAGE AND IT IS NOT AN EDGE CASE, IT IS THE DOMINANT CASE. Of 13 visible headings on /products/scheduling-package, TEN wear a borrowed size — seven `h3.dfx-h5` card titles at 18px and three `h2.dfx-h4` section headings at 20px, which is the pairing table's standard product-page shape. All ten were taking h2/h3's -0.02em while rendering at h4/h5 sizes. So the "negligible mismatch" was the tracking that nearly every heading on every product page actually got. SO THIS RULE NOW MIRRORS THE LINE-HEIGHT RULE, NOT THE WEIGHT RULE. That is the right parent to copy: tracking, like leading, is a property of the type at its rendered size, whereas weight follows the outline level by deliberate design. The classes sit at 0-1-0 and beat `body h3` at 0-0-2, so a borrowed size now gets its own band — same mechanism and same justification the leading block already relies on. .dfx-h6 IS STILL ABSENT, and that is not an oversight: h6 is the caps label step and carries +0.14em from its own block. Adding it here would fight that. */ body h1, .row .col h1, .wpb_wrapper h1, .dfx-h1 { letter-spacing: var(--dfx-letter-spacing-h1); } body h2, body h3, .row .col h2, .row .col h3, .wpb_wrapper h2, .wpb_wrapper h3, .dfx-h2, .dfx-h3 { letter-spacing: var(--dfx-letter-spacing-heading); } body h4, body h5, .row .col h4, .row .col h5, .wpb_wrapper h4, .wpb_wrapper h5, .dfx-h4, .dfx-h5 { letter-spacing: var(--dfx-letter-spacing-heading-small); } /* ============================================================================ h6 IS THE LABEL STEP — the one level that is not a heading. ============================================================================ h6 is 16px, the same as body copy, and that only works because nothing else about it looks like body copy: uppercase, 0.14em tracking, weight 600, muted ink. Those four properties are the role. The size is incidental to it, which is exactly why sharing 16px with a paragraph costs nothing. THIS FILE HAS MADE THE OPPOSITE MISTAKE, so the distinction is worth stating. h5 used to sit at 16px on the argument that weight 600 was enough to separate a card title from the copy beneath it. It was not, because both were sentence case and weight alone cannot carry a hierarchy across two sentence-case lines. Case and tracking can. That is the whole difference between this rule and the thing it learned from. IT IS A PROMOTION, NOT AN INVENTION. All four places the h6 step was used already wrote these same four declarations by hand — .dfx-product-group__title, the product feature list's group labels, the "Trusted by" separator and the footer widget titles. The role was already agreed; it was just stated four times. Those components now inherit it and keep only what is genuinely theirs. (The feature list's labels since became Salient toggle titles and left this step behind; the other three still take it.) THE .dfx-h6 CLASS IS IN THIS RULE, WHICH BREAKS THE "SIZE ONLY" INVARIANT the size-scale block below sets out — deliberately, and it is the one exception. The reasoning: for h1–h5 the class borrows a SIZE, so carrying anything else would be overreach. h6 is not a size, it is a ROLE, so a component reaching for `.dfx-h6` is asking for the label treatment and not for 16px — 16px it could have had from body. An `h2.dfx-h6` section label therefore looks like every other label on the site, which is the point of the pairing table's "small label beside a rule" row. If .dfx-h6 carried size alone, that row would produce an h2 indistinguishable from a paragraph. COLOR IS INDIRECT, FOR THE REASON THE HEADING-COLOR BLOCK ABOVE GIVES AT LENGTH. Pewter is 4.72:1 on Signal White and unreadable on a dark band, so a flat muted color here would break every label on an inverted section. The escape-hatch list re-points --dfx-label-ink alongside --dfx-heading-ink, and on a dark context it resolves to 70% of the inherited text color — the same subdued-on-band treatment the band components already use. SPECIFICITY MATCHES THE OTHER ESCALATIONS because it has to fight the same generated file: Salient sets tracking and weight on `body h6` and `.row .col h6` and would otherwise flatten two of the four properties. */ body h6, .row .col h6, .wpb_wrapper h6, .dfx-h6 { font-weight: var(--dfx-weight-emphasis); letter-spacing: 0.14em; text-transform: uppercase; color: var(--dfx-label-ink); } /* HEADING LINE-HEIGHT, AT 0-0-2 SO IT SURVIVES SALIENT'S GENERATED FILE. The one value from the block above that is escalated rather than conceded. salient-dynamic-styles.css ships `#page-header-bg h1, body h1, … { line-height: 1.094 }` and the equivalent for h2 (1.094) and h3 (1.3), built from Salient's typography options. `body h1` is 0-0-2 and the grouped bare selectors above are 0-0-1, so every heading on the site was running Salient's leading while wearing this theme's sizes — a 56px h1 with 61px of leading instead of 70px, which reads as cramped at display sizes and was reported as "tight" more than once. WHY THAT KEPT COMING BACK. Salient regenerates that file whenever its options are saved or its cache is cleared, so any fix made by editing or clearing it is undone by the next person who touches Theme Options. Winning on specificity from the child theme is the only version of this fix that stays fixed. THE SELECTOR LIST MIRRORS THE SIZE SCALE BELOW, INCLUDING `.row .col h*`, and it has to. Salient ships the same value three ways — `body h4` at 0-0-2, `.row .col h4` at 0-2-1, and `.row .vc_col-sm-4 h3` — so `body h4` alone fixes a heading in a template and leaves every heading inside a builder column untouched. That is exactly the split the size scale already worked around, which is why it reads `body h3, .row .col h3, .dfx-h3`: same problem, same shape, one property over. The ties at 0-0-2 and 0-2-1 fall to this file because it loads after the generated one. The .dfx-h* classes are included at 0-1-0 so a level wearing a borrowed size gets that size's leading with it. That is load-bearing now the value differs by size: an `h2.dfx-h4` section title gets 0-0-2 from `body h2` and 0-1-0 from `.dfx-h4`, so the class wins and the leading follows the SIZE it renders at rather than the level it claims in the outline. Which is the whole point — leading is a property of the type, not of the document structure. SPLIT AT THE h4 BOUNDARY, one value for display sizes and one for small. 1.25 across the whole scale gave a small wrapped title four pixels of air between two lines of 600-weight type, which reads as a single block. See the token definitions for the arithmetic. The boundary is the same one --dfx-weight-heading-light already switches at, so the scale changes character in one place rather than two. No !important here. Specificity is enough against these rules, and a section that genuinely needs different leading — .dfx-display reads --dfx-line-height-display — should still be able to say so. The one place !important IS required is below. */ /* NOW SPLIT THREE WAYS ABOVE THE h4 BOUNDARY TOO, one selector list per level. This block was h1+h2+h3 sharing 1.25. It is three blocks because the three levels now hold three values — h1 fluid, h2 1.3, h3 1.35 — for the reason the token definitions set out: 1.25 across a 24→64px range is right at one point on the ramp. Same selector families, same specificity story, same reliance on this file loading after Salient's generated one. Nothing about the cascade changed; only the count. */ body h1, .row .col h1, .wpb_wrapper h1, .dfx-h1 { line-height: var(--dfx-line-height-h1); } body h2, .row .col h2, .wpb_wrapper h2, .dfx-h2 { line-height: var(--dfx-line-height-h2); } body h3, .row .col h3, .wpb_wrapper h3, .dfx-h3 { line-height: var(--dfx-line-height-heading); } /* THE PAGE-HEADER TITLE AGAIN, for the reason set out in the size scale below. Salient carries size AND leading on the same over-specific selector list, so `.row .col h1` at 0-2-1 lost the 1.094 on the page title even while winning it everywhere else — the 64px headline was rendering with 70px of line box, and once the size was corrected to the ramp's h1 that same 70px became visibly tight against it. Fixing the size without this would leave the title at the ramp's size and the parent theme's leading, which is the pairing that reads as cramped. */ html body .row .col.section-title h1, html body .row .col.section-title.span_12 h1, html body #page-header-bg h1, html body #page-header-bg .span_6 h1 { /* Reads the h1 band, not the old shared value — this IS an h1, and it is the one most likely to be the fluid clamp's whole point: a long page title at the 34px floor on a phone. */ line-height: var(--dfx-line-height-h1); /* TRACKING RIDES ALONG, THIRD PROPERTY ON THE SAME SELECTOR LIST. Salient carries size, leading AND tracking for the page title on one over-specific list — `body .row .col.section-title h1` at 0-3-2 for the -0.015em — so the all-levels rule above at 0-0-2 reaches every h1 on the site except this one. Adding it here rather than a fourth block: the selectors, the reason and the fix are identical, and three properties in one place is the thing that stops the next property being forgotten. `html body …` at 0-3-3 outranks Salient's 0-3-2 without !important. */ letter-spacing: var(--dfx-letter-spacing-h1); } body h4, body h5, body h6, .row .col h4, .row .col h5, .row .col h6, .wpb_wrapper h4, .wpb_wrapper h5, .wpb_wrapper h6, .dfx-h4, .dfx-h5, .dfx-h6 { line-height: var(--dfx-line-height-heading-small); } /* WPBAKERY CUSTOM HEADINGS — THE ONE CASE THAT NEEDS !important. Salient's generated file declares `.wpb_wrapper h3.vc_custom_heading { line-height: 1.3 !important }` and the equivalent for the other levels. Nothing short of !important at equal-or-greater specificity beats that, so this matches it rather than losing quietly — which matters because vc_custom_heading is what the page builder emits for most headings on the homepage, i.e. the majority of headings a visitor actually sees. Verified before writing this: no per-element line-height is generated for these elements today, inline or in a