carries a browser default margin-inline-start of 40px. Reset it, or
every description hangs off the right of its own card. */
.svc-item__desc {
margin: 0.45rem 0 0;
}
/* Sections with a paper background need the cards to stay distinguishable. */
.section--promise .svc-item,
.section--bundle .svc-item {
background: var(--white);
}
/* ---------------------------------------------------------- pull quote -- */
.pull-quote {
margin: 1.5rem 0;
padding: 0.25rem 0 0.25rem 1rem;
border-left: 6px solid var(--orange);
font-family: var(--font-head);
font-size: 1.1rem;
color: var(--navy);
}
.pull-quote p {
margin: 0;
}
/* ------------------------------------------------------------ tag list -- */
/* The commercial page's industry lists: plain, dense, no bullet art. */
.tag-list {
list-style: none;
margin: 0;
padding: 0;
}
.tag-list li {
padding: 0.3rem 0;
border-bottom: 1px solid var(--pale);
}
.tag-list li:last-child {
border-bottom: 0;
}
/* OPT-IN BULLETS, per User request 2026-09-08 (items 3.3, 3.8, 4.2, 4.7 and
4.9 -- five lists on the IAQ and duct pages that the User asked to be "in a
bullet list format"). Those lists render with no markers at all because the
base class above is `list-style: none`.
A MODIFIER, NOT AN EDIT TO `.tag-list`. The base class has five more users
the request never mentions -- the commercial page's five industry lists
inside `.card` boxes -- and the comment above records that those are
deliberately bullet-free. Changing the base would silently reverse that.
`outside` (the initial value, restated because it is a decision, not a
default we inherited): every one of these items wraps to two or three lines
at 360px, and `inside` would run the wrapped lines back under the marker
instead of aligning them with the first word.
The indent is `padding-left` ON THE UL, which is what restores the `padding:
0` the base class sets. Chromium draws an `outside` marker to the left of
the li's BORDER box, not inside the li's padding, so putting the indent on
the li instead was measured to hang the bullets at x=8 on a 360px screen --
12px to the LEFT of the 20px `.wrap` gutter every other element on the page
starts at, and 8px from the viewport edge. On the UL the markers land at
x=28: inside the gutter, and in the same place `.icon-list`'s inline icons
sit, which is the site's existing pattern for a marker-then-text row. The
li's `border-bottom` separators indent with the list rather than staying
flush at 20px, which is the deliberate trade -- each rule then spans
exactly the text column it separates. */
.tag-list--bulleted {
list-style-position: outside;
padding-left: 1.25rem;
}
.tag-list--bulleted li {
list-style-type: disc;
}
/* Orange for the IAQ page's "Does this sound familiar?" list (item 3.3, "the
list following it should be orange"). Same --orange-cta token as
`.icon-list--accent-orange li` and `.price-list__combo`, deliberately: this
site has exactly one accent orange. The ::marker inherits `color`, so the
bullets go orange with the text. Only this one list is accented; the other
four bulleted lists get markers and nothing else.
RESOLVED BY THE sec.7 PASS (2026-09-11). This used to be --orange-dark
(#D1520E), 4.26:1 against the white .section background -- BELOW WCAG AA's
4.5:1 for normal-size text, recorded here as a known defect rather than
silently re-coloured. sec.7 retired that token; --orange-cta is
4.85:1 and passes, without forking the one accent orange this site has. */
.tag-list--accent-orange li {
color: var(--orange-cta);
}
/* Orange for the duct page's "Interested in a full system refresh?" sentence
(spec §4.8, 2026-09-08 User request -- "a like break" is the User's typo
for "a line break"; the split into its own `` provides that break).
Colour only: the User asked for orange, not bold, so this does not reuse
`.lead--combo`'s `font-weight: 700`. Same --orange-cta token as the rules
above, deliberately -- one accent orange sitewide. The contrast shortfall
noted above was fixed by the sec.7 pass (2026-09-11). MEASURED HERE, NOT
ASSUMED: this sentence renders 16px/400 on --paper, NOT on white -- it sits
in a --paper section band -- where --orange-dark was 4.00:1 and --orange-cta
is 4.55:1. It passes AA for normal-size text by 0.05, which is precisely why
--orange-cta is set for --paper rather than for white. */
.text--accent-orange {
color: var(--orange-cta);
}
.tag-list--bulleted + p {
/* Same 0px-gap defect as `.svc-list + .subhead` above, on the User's item
4.10 ("more space between that list and the text under it"). Keyed on the
BULLETED modifier rather than on `.tag-list`, which both keeps it off the
commercial industry lists by construction and confines it to the three
places it can currently land -- item 4.10's pair plus the duct
Test/Clean/Compare and IAQ "who is this for" lists, which are the same
list-then-paragraph shape and are lists THIS change puts bullets on.
Spacing only 4.10 would leave the other two flush against a list that
just grew markers, i.e. worse than before this commit. 1.5rem, not the
2rem used for `.svc-list` above: a `.tag-list` has no card shadow under
it, and at 2rem the paragraph measured as drifting away from the list it
belongs to. */
margin-top: 1.5rem;
}
/* --------------------------------------------- Phase 1b breakpoints -- */
/* Its own block, deliberately. See the banner at the top of this section. */
@media (min-width: 48rem) {
.svc-list {
grid-template-columns: 1fr 1fr;
}
/* About Us step 7 (spec §2.4, 2026-09-08 User request) -- a seventh
`.svc-item` that must not land alone in the left column once the grid
above goes two-up. Modifier on the one item rather than a change to the
base `.svc-list` grid, which serves 15 instances sitewide. */
.svc-item--full {
grid-column: 1 / -1;
}
}
/* ================================================================
* Phase 1b round 2 components.
*
* APPENDED, NEVER EDITED IN PLACE, exactly as round 1 was: nothing above this
* banner changed, so the Phase 1a header/nav rules and round 1's components
* stay byte-identical. Desktop overrides go in the media block at the very
* end of this file, not spliced into an earlier one.
*
* These classes serve /duct-cleaning-arvada and
* /indoor-air-quality-testing-arvada. Round 2 landed the duct page only and
* noted here that `.photo--hero` and `.tag-list--sub` were not yet used by
* any built page; round 2b built the IAQ page, so every rule in this section
* went live and that caveat stopped applying. `.photo--hero` has since been
* deleted by the 2026-09-06 hero unification -- see the note where it stood.
* Round 3 reuses this section; add here, do not fork.
* ================================================================ */
/* ---------------------------------------------------------- photographs -- */
/* The first real photographs on the site. Deliberately NOT `.hero__art`:
that class sets `image-rendering: pixelated`, which is right for the
pixel-art banners and wrong for a camera photo.
`aspect-ratio` + `object-fit: cover` rather than an intrinsic width/height
pair, because the sources are a mix of landscape (3630x2160) and portrait
(1216x2160) and a portrait photo at 100% width would otherwise run nearly
two screens tall on a phone. The box is fixed, the photo is cropped to it,
and there is no layout shift while it loads. */
.photo {
margin: 0 0 1.25rem;
}
.photo img {
display: block;
width: 100%;
height: auto;
object-fit: cover;
object-position: center;
background: var(--pale);
}
/* `.photo--hero` WAS HERE and is deleted, not deprecated. It was the second of
three hero variants; the hero is now one shared box (see `--hero-banner-h`
in the hero section above) and the two photo pages reach it through
templates/_hero.html.j2's `photo_name=` argument like everyone else. Left in
place it would have kept fighting the shared box: its `aspect-ratio` and
`max-height` sit at the same specificity as `.hero__media img`. Its desktop
`max-height` override in the round 2 breakpoint block below is gone for the
same reason. */
/* In-body photographs get the same frame as a card so they read as part of
the same kit. The 6px shadow sits inside `.wrap`'s gutter, so it never
causes horizontal overflow at 360px. */
.photo--framed img {
aspect-ratio: 3 / 2;
max-height: 22rem;
border: 3px solid var(--ink);
border-radius: var(--radius);
box-shadow: 6px 6px 0 var(--shadow);
}
/* Worn WITH `.photo--framed`, for a source that is taller than it is wide
(currently one photo: the IAQ page's technician kneeling at a return vent
with a meter, 1216x2160). In the shared 3/2 box `object-fit: cover` keeps
only the middle ~37% of a portrait frame's height, which on that photo is a
band of blank wall -- it throws away the one image on the site that shows
the work actually being done. A 3/4 box keeps 75% of the height, trimming
the window above and the carpet below while the technician, the vent and
the meter all stay in frame.
The cap is on WIDTH, not height. `.photo--framed`'s `max-height` exists to
stop a tall image running two screens down a phone, but applied to a
portrait box it does the cropping all over again: the height clamp
silently widens the effective ratio back into a letterbox on a wide
screen. Capping the width bounds the height by the aspect ratio instead,
so the crop is the same at every viewport. */
.photo--portrait img {
aspect-ratio: 3 / 4;
max-width: 22rem;
max-height: none;
margin-inline: auto;
}
/* --------------------------------------------------- headings with art -- */
/* A pixel icon set beside a section title, the way `.svc-group__icon` sits
beside a service-group title. Inline rather than flex so the title still
wraps as one paragraph of text when the heading is long. */
.section-title__icon {
width: 2rem;
height: 2rem;
margin-right: 0.5rem;
vertical-align: -0.3em;
image-rendering: pixelated;
}
/* The residential "Level Up" section title (residential-arvada-hvac.html.j2,
#second-opinion-heading) treats `text-bar-level-up.png` as a decorative
banner sitting on its own line above the heading text, per 2026-09-08
User decision -- the `.section-title__kicker` "Level Up" stays as real,
selectable text; the art is not a replacement for it.
The PNG's canvas is 1600x1050 (1.5238:1) but the opaque "LEVEL UP" bar
inside it is only 1408x407 (~3.46:1), centred with large transparent
bands above and below -- only ~39% of the canvas height is visible
artwork. Sizing this like the square `.section-title__icon` (height-only)
would leave the visible bar tiny, so it is sized by width instead, with
height:auto to preserve the true aspect ratio. At width 11rem: canvas
height = 11rem * (1050/1600) = 7.22rem, and the visible bar within that
canvas = 7.22rem * (407/1050) = ~2.8rem tall. */
.section-title__icon--bar {
display: block;
width: 11rem;
max-width: 100%;
height: auto;
margin-right: 0;
margin-bottom: 0.5rem;
vertical-align: baseline;
}
/* The live IAQ and duct heroes both close with a line of copy that is a
heading on the live page ("Schedule an Air Quality Assessment:", "Ready to
See What's Hiding in Your Ducts? Call Today!"). It stays a heading here,
one level below the hero's h1, and is sized to sit under it rather than
compete with it. */
.hero__cta-title {
margin: 1.5rem 0 0.5rem;
font-size: 1.2rem;
color: var(--pale);
}
/* ------------------------------------------------------ nested tag list -- */
/* The IAQ page's pollen-season bullet carries three sub-bullets. They are
indented and unruled so the parent list's rules still read as the list. */
.tag-list--sub {
margin: 0.35rem 0 0.15rem 1.1rem;
}
.tag-list--sub li {
padding: 0.15rem 0;
border-bottom: 0;
}
/* The sub-list's markers, per item 3.8. `.tag-list--bulleted li` is a
DESCENDANT selector, so the three pollen seasons already take the parent's
bullets through it -- the sub-list needs no extra class in the markup,
which is why none was added. Two things still have to be said here:
1. `disc` inside `disc` is not legible as nesting. `circle` (hollow) is the
conventional second level and is the visual distinction the item asks
for. Verified in Chromium at both widths: filled outer, hollow inner.
2. The sub-list carries neither `--bulleted` nor `.tag-list`'s indent, so
it needs its own `padding-left` to give its markers room. 1rem, slightly
tighter than the parent's 1.25rem, because `.tag-list--sub` above
already offsets the whole list by a 1.1rem left margin.
Both selectors are `.tag-list--bulleted .tag-list--sub ...` rather than
bare `.tag-list--sub ...` so that a future un-bulleted nested list keeps
the existing marker-free treatment. */
.tag-list--bulleted .tag-list--sub {
padding-left: 1rem;
}
.tag-list--bulleted .tag-list--sub li {
list-style-type: circle;
}
/* ----------------------------------------------------------- flow line -- */
/* The duct page's "Testing -> Inspection -> Cleaning -> ..." summary, with the
live layout's pixel health-bar art either side of it. Wraps to as many rows
as it needs on a phone instead of overflowing. */
.flow-line {
display: flex;
flex-wrap: wrap;
align-items: center;
justify-content: center;
gap: 0.75rem;
margin: 0 0 1.5rem;
font-family: var(--font-head);
font-weight: 700;
color: var(--navy);
text-align: center;
}
.flow-line__rule {
width: 100%;
max-width: 12rem;
height: auto;
image-rendering: pixelated;
}
/* ---------------------------------------- Phase 1b round 2 breakpoints -- */
/* Its own block, deliberately. See the banner at the top of this section. */
@media (min-width: 48rem) {
.photo--framed img {
max-height: 26rem;
}
/* Re-stated because the `.photo--framed` rule above has the same
specificity and would otherwise re-impose the height clamp here. */
.photo--portrait img {
max-height: none;
}
.hero__cta-title {
font-size: 1.35rem;
}
}
/* ================================================================
* Phase 1b round 3.
*
* APPENDED, NEVER EDITED IN PLACE, exactly as rounds 1 and 2 were: not one
* line above this banner is changed. Desktop overrides go in a media block
* down here, not spliced into an earlier one.
*
* TWO PARTS, unlike rounds 1 and 2. First the two components that serve
* /about-us-hvac, the sixth and last Phase 1 page. Then -- and this is the
* departure from "components only" -- extra DECLARATIONS on the Phase 1a
* header selectors, fixing a wrapping defect that has shipped on every page
* since Phase 1a. They are declarations, not edits: the rules they land on
* are untouched where they stand, and no gate, no `.is-nav-open` rule and no
* `flex-wrap` is among them. See the note above that block for why the
* existing tests could not catch it.
* ================================================================ */
/* Worn WITH `.photo--framed`, for a source that is as tall as it is wide.
Both About-page photographs are 2160x2160. `.photo--framed`'s 3/2 box would
keep only the middle two thirds of a square frame, and its `max-height`
makes that worse rather than better: with `width: 100%` the height clamp
widens the EFFECTIVE ratio on a big screen (a 1088px-wide box clamped to
26rem tall is 2.6:1), so a wide viewport crops harder than a narrow one.
Same reasoning, and the same fix, as `.photo--portrait` above: cap the
WIDTH, let the aspect ratio bound the height, and the crop is then identical
at every viewport. */
.photo--square img {
aspect-ratio: 1 / 1;
max-width: 24rem;
max-height: none;
margin-inline: auto;
}
/* A piece of illustrative pixel art set inside a section's flow, the way
`.hero__art` sits at the top of a hero. Centred and width-capped so it
reads as an illustration beside the copy rather than a full-bleed band, and
`image-rendering: pixelated` because it IS pixel art -- the same reason
`.photo` deliberately does not set it. */
.section-art {
margin: 0 0 1.25rem;
text-align: center;
}
.section-art img {
display: inline-block;
width: 100%;
max-width: 22rem;
height: auto;
image-rendering: pixelated;
}
/* ------------------------------------------------- desktop header fit -- */
/* A PHASE 1A DEFECT, fixed here because the header is shared and it therefore
shipped on every page. At 1280 the header phone broke across THREE lines
("(720)" / "445-" / "5532") and the "Contact Us" label across two, which
pushed the bar to 109px tall. The layout tests could not see it: they assert
RELATIONSHIPS ("the nav is on the logo's row") on purpose, so they survive
font-metric drift -- and a relationship assertion cannot tell a phone number
on one line from the same number on three.
NOTHING ABOUT THE WRAP ARCHITECTURE CHANGES HERE. No `:where(.js)` gate, no
`.is-nav-open` rule and no `flex-wrap` declaration is touched; the
`min-width: 48rem` block above still owns the one-row pin. These are extra
declarations on the same selectors, in a later block, so source order
settles them at equal specificity -- except `.site-nav__actions .btn`, which
is (0,2,0) deliberately so it outranks the bare `.btn` padding it replaces.
The break was mid-number and mid-word, so `nowrap` is the fix, and it is
NOT gated to desktop: at 360 with JavaScript off the same two buttons are in
flow, `.site-nav__actions` wraps, and they stack instead of overflowing. */
.site-nav__actions .btn--phone span,
.site-nav__actions .btn--primary {
white-space: nowrap;
}
/* THE NAV FITS ONE ROW ONCE THE HEADER IS WIDE ENOUGH. The 2026-08-27 note
that used to stand here concluded the opposite -- "six nav links do not fit
one row at 1280, and cannot be made to without shrinking the text past
legibility" -- and its arithmetic was right for the box it measured: the
header bar was a plain `.wrap`, so its content box was 68rem - 2 gutters =
1048px at EVERY viewport from 1280 to 1920, and one row needed more than
that. What that note got wrong was the conclusion it drew, that the deficit
was unfixable. The deficit was the 68rem cap itself, and the User settled
the design question it was deferring on 2026-09-06: widen the header, keep
body prose at 68rem. `--header-wrap` does that; the block at the end of this
file has the re-measured budget. DO NOT restore the old numbers -- 1048px
is not this header's content box any more.
What the tightening below is still worth, and why it stays: it is what got
one row within reach at all. It drops the 768 band from four nav rows /
168px (where `nowrap` alone lands it, worse than the 128px it started at)
to three rows / 118px, and it is what makes the six links measure 1019.8px
on one row instead of 1201px. 0.875rem link text is a 1.2px reduction from
0.95rem, not a legibility change. */
@media (min-width: 48rem) {
.site-header__bar {
gap: 0.75rem;
}
.site-header__logo img {
/* 2.5rem, not 3rem: under `flex-wrap: nowrap` the flex line was already
squeezing the lockup to 38px tall to make room, so this is a hair
LARGER than what shipped -- it just stops being an accident.
THIS IS A CAP, NOT THE RENDERED SIZE. The logo is a shrinkable flex
item on an over-full line, so between 768 and 1023 it renders well
BELOW this cap -- 26.8px at 768, 31.6px at 1023 -- and never touches
40px. Raising this number alone therefore does not resize anything by
the amount it appears to; what sets the size in this band is the
`min-width` FLOOR in the header-width block at the end of the file.
Governs 48rem-64rem only; 64rem up raises the cap to 3.65rem. */
max-height: 2.5rem;
}
.site-nav {
gap: 1rem;
}
.site-nav__list {
gap: 0.85rem;
/* The list still wraps -- `flex-wrap` is untouched -- but its lines now
pack toward the buttons instead of toward the logo, so the sixth link
lands directly under the fifth and the nav reads as one right-aligned
block rather than as a full row plus an orphan on the far left. */
justify-content: flex-end;
}
.site-nav__link {
font-size: 0.875rem;
}
.site-nav__actions .btn {
padding: 0.55rem 0.8rem;
font-size: 0.9rem;
}
.site-nav__actions .btn__icon {
width: 1.25rem;
height: 1.25rem;
}
}
/* A pixel icon trailing a run of body-copy text (16px, not a flex parent),
per 2026-09-08 User request (spec §2.2) moving the About Us clock out of
the section title and into the story paragraph, right after "Urgent." None
of the other three inline-icon rules fit: `.section-title__icon` (2rem) is
sized against a heading and would read as twice the line's cap height next
to 16px text; `.lead__icon` and `.icon-list__icon` both assume a flex
parent, which a plain trailing `
` icon does not have. Sized down from
`.section-title__icon`'s 2rem to 1.5rem so it reads as part of the
sentence, with margin on the left (not right) since it trails the text
instead of leading a heading. Lives here, in Phase 1b round 3, rather than
up in Phase 1a where it first shipped: `.body-icon` serves /about-us-hvac,
the page round 3 is the designated home for, and Phase 1a above this file's
first banner is APPENDED, NEVER EDITED IN PLACE. */
.body-icon {
width: 1.5rem;
height: 1.5rem;
margin-left: 0.35rem;
vertical-align: -0.3em;
image-rendering: pixelated;
}
/* ================================================================
* Hero unification breakpoint (2026-09-06).
*
* The desktop half of `--hero-banner-h`, in its own block at the end of the
* file for the same reason rounds 1-3 put theirs here: the breakpoint lives
* in exactly one place per round and is never spliced into an earlier query.
* ================================================================ */
@media (min-width: 48rem) {
/* 20.8rem = 332.8px = 80% of the 26rem box `.photo--hero` declared from
this breakpoint up. Written as the arithmetic, not as 332.8px, so the
baseline and the User's 80% are both readable in the value itself and
neither can be silently re-derived. */
:root {
--hero-banner-h: calc(26rem * 0.8);
}
}
/* ================================================================
* Header width, and the logo that lives in it (User, 2026-09-06).
*
* WHAT WAS ACTUALLY WRONG: the logo was never too small -- THE HEADER WAS TOO
* NARROW. `.site-header__bar` is a `.wrap`, so it was capped at `--wrap`
* (68rem = 1088px, a 1048px content box). On a 1990px window that is ~470px
* of unused space down each side, and inside that squeeze the nav had already
* wrapped to two rows while the logo -- a shrinkable flex item on an
* over-full line -- was crushed to 33.7px against a declared 2.5rem cap it
* never reached. Scaling the logo inside that box could not work: the space
* it needed was sitting beside the header, not inside it. So the fix is the
* container, and the logo is then sized against the room that frees up.
*
* The three declarations below are one mechanism, in the order the browser
* applies them: give the bar a wider ceiling, floor the logo so it can never
* be crushed again, raise its cap so it can use the new room, then stop the
* nav shrinking once there is provably space for it on one row.
*
* THE BUDGET, MEASURED IN CHROMIUM ON THE BUILT TREE, 2026-09-06. Every
* number here is a `getBoundingClientRect` reading, not a stylesheet value:
*
* Six links on one row .................... 633.8px (+ 16px nav gap)
* Phone button + CTA, `nowrap` ............ 370.0px
* => `.site-nav` at max-content .......... 1019.8px
* Logo at its 3.65rem cap ................. 304.7px (+ 12px bar gap)
* => one-row content box needed .......... 1336.7px
* + 2 x 20px `.wrap` gutters ............. 1376.7px of BORDER box
*
* 88rem = 1408px clears that by 31.3px, which is the safety margin: this site
* ships NO webfont (see the top of this file), so a visitor with Montserrat
* or Poppins actually installed measures different link widths than the
* fallback stack does here. 87rem would leave only 15.3px of that margin and
* 86rem = 1376px is 0.7px short outright.
*
* WHY THE ONE-ROW GATE IS 88rem AND NOT 80rem/1280. It is the same number on
* purpose: THE NAV GOES TO ONE ROW EXACTLY WHEN THE BAR REACHES ITS FULL
* WIDTH, and below that it is not a free choice but a trade. At 1280 the bar
* is viewport-bound to a 1240px content box, 96.7px short of the 1336.7px
* above, so a one-row nav there forces the logo down to 39.9px -- 1.18x the
* 33.7px baseline, i.e. SMALLER than the 54.1px it gets by leaving the nav on
* the two rows it already had. Both were measured. Widening gutters, gaps and
* button padding recovers at most ~48px of the 96.7px, and the rest would
* have to come out of the link text the 48rem block above already tightened
* to 14px. So 1280-1407 spends the space on the logo, which is what the User
* asked to grow, and nothing there is worse than what shipped.
*
* A media query cannot read a custom property, so the `88rem` in the gate
* below and `--header-wrap` at the top of this file are ONE NUMBER written
* twice. Change them together.
*
* RENDERED LOGO HEIGHTS, before -> after (Chromium, both JS states):
* 768 .... 23.3 -> 26.8px four nav rows, header 153.5px: both unchanged
* 1024 ... 31.6 -> 42.8px two nav rows, header 81.6px: both unchanged
* 1280 ... 33.7 -> 54.1px two nav rows, header 81.6px: both unchanged
* 1920 ... 33.7 -> 58.4px nav 2 rows -> ONE, header 81.6px unchanged
* The header is never taller than it was at any width, and no width overflows
* the viewport. 58.4px is the cap for exactly that reason: it is the height
* the bar already had (the old two-row nav's 58.4px), so the logo grows into
* space the header was already paying for and the bar stays 77.6px + 4px
* border. Anything above 3.65rem makes the header taller, which the User
* ruled out.
* ================================================================ */
.site-header__bar {
/* Later in source order than `.wrap` at equal (0,1,0) specificity, so this
wins without an `!important` and without touching `.wrap`, which still
governs every other block on the page. `width: 100%` is unchanged, so
below 1408px the bar is viewport-bound and this is inert -- the widening
only ever happens where there was empty space to reclaim. */
max-width: var(--header-wrap);
}
@media (min-width: 48rem) {
.site-header__logo {
/* THE FLOOR, AND THE ONLY THING STOPPING THE CRUSH. `max-height` on the
img is advisory here: the flex line is over-full, the logo is
shrinkable, and it lost -- 23.3px rendered against a 40px cap. A
`min-width` on the flex ITEM is what flex-shrink is not allowed to go
past, and the img's `max-width: 100%` then carries the height with it.
8.75rem = 140px wide = 26.8px tall at 768, up from 23.3px. It is a
floor and not a pin (`flex-shrink: 0`) on purpose, so that 1024 and up
still grow past it instead of being frozen at the tablet size.
WHY IT IS NOT LARGER: 768 has a 728px content box, and after the bar
gap, the nav gap and the 370px phone+CTA pair the link list is left
with 330px - the logo's width. The list must stay at least 184px wide
or "Indoor Air Quality Testing", the longest link, breaks across two
lines and the header grows a row. Measured: 9rem still renders four
rows / 149.5px, 9.25rem tips it to 171.9px. 8.75rem sits 8px inside
that cliff -- deliberate headroom, for the same no-webfont reason as
the 88rem above. */
min-width: 8.75rem;
}
}
@media (min-width: 64rem) {
.site-header__logo img {
/* 3.65rem = 58.4px, the enlarged cap. Reached at 1408 and above; between
1024 and 1407 the line is still over-full so the logo renders below it
(42.8px at 1024, 54.1px at 1280) and grows smoothly with the viewport.
GATED AT 64rem, NOT 48rem, AND THIS IS NOT COSMETIC: the cap sets the
flex BASE size, so raising it at 768 makes the logo shrink to a larger
final width, which steals from the link list and takes the header to
five nav rows / 211.9px (measured). 768-1023 keeps the 2.5rem cap and
gets its enlargement from the floor above instead. */
max-height: 3.65rem;
}
}
@media (min-width: 88rem) {
.site-nav {
/* SIX LINKS, ONE ROW -- the User-visible point of the widening. The nav
is a flex item whose base size is its max-content width (1019.8px, the
list unwrapped); refusing to shrink it therefore hands the list exactly
the width it needs and the wrap never happens. The logo stays
shrinkable and absorbs whatever is left, which is why it and not the
nav is what gives way if this ever gets tight again.
Pinned by test_nav_links_are_one_row_once_the_header_is_full_width,
together with an overflow assertion: the failure mode of
`flex-shrink: 0` is a nav that pushes past the viewport instead of
re-wrapping, and there is 196px of slack before that can happen
(1368px content box, 140px logo floor, 12px gap). */
flex-shrink: 0;
}
}
/* ================================================================
* Phase 1b round 4 -- PER-PAGE HERO ART FRAMING (User, 2026-09-09).
* Spec: docs/spec/website-content-updates.md sec. 1.1, extended by sec. 0.2
* item 1 (which folds sec. 2.1 and sec. 3.1 in: "fix the hero image" on
* /about-us-hvac and /indoor-air-quality-testing-arvada means the CROP, not a
* new photograph).
*
* APPENDED, NEVER EDITED IN PLACE, exactly as rounds 1-3 were. That matters
* more than usual here, because the rule this round reframes -- `.hero__media
* img` at the top of this file -- sits in the Phase 1a region. It is NOT
* edited. Nor is it shadowed by a same-specificity copy down here that would
* depend on source order to win: every rule below is written in the COMPOUND
* form `.hero__media.hero__media-- img` -- two class selectors plus a
* type selector, (0,2,1), against the base rule's (0,1,1) -- so it wins on
* SPECIFICITY. Move this block anywhere in the file and the rendering is
* identical. That is deliberate: a cascade-order dependency is invisible in a
* diff and this is the file where that has bitten before.
*
* WRITE THE MODIFIER TWICE, AND HERE IS WHY. `.hero__media--about img` on its
* own is (0,1,1), not (0,2,1): a BEM `--modifier` is still exactly ONE class.
* That TIES the base rule `.hero__media img` and wins on source order alone.
* The tie is not academic for the two `object-position` rules below, which
* override a property the base rule actually sets (`object-position: center`,
* with it at the top of this file). Move a single-class version of this block
* above that rule and the About/IAQ framing silently reverts to centred --
* nothing in the diff, nothing in the test run, just a wrong-looking page.
* (The home/residential rules set `transform`, which nothing else sets, so
* they would survive either form; the claim above has to hold for all four.)
* The compound form is what makes the paragraph above TRUE rather than merely
* intended. It shipped single-class once, in this block, and was corrected
* the same day -- verified by moving the whole block above the base rule,
* rebuilding, and confirming the computed `object-position` did not move.
*
* WHAT IS AND IS NOT FORKED. The shared box is untouched: `--hero-banner-h`
* (10rem / calc(26rem * 0.8)) and the 0.2 opacity are exactly the values the
* User fixed on 2026-09-06, and NOTHING here selects `.hero__media` itself --
* only the img inside it. The 2026-09-06 rationale block above warns "Do not
* 'fix' the mobile growth by special-casing commercial-hvac-arvada"; that
* warning is about the box's HEIGHT, and no height is forked here. What is
* forked is how the art sits inside a box whose size never changes, which is
* the part `templates/_hero.html.j2` has always called the per-page part.
*
* ------------------------------------------------------------------
* WHY object-position ALONE CANNOT DO THE HOME AND RESIDENTIAL PAGES.
*
* Measured in Chromium against the built tree, 2026-09-09, `object-fit:
* cover` as shipped:
*
* page 360px band 1280px band
* home 100%x / 98.8%y 100%x / 57.8%y of the source visible
* residential 100%x / 98.8%y 100%x / 57.8%y
*
* 100% of the source WIDTH is visible at both widths on both pages, because
* the band is wider-ratio (2.25:1 at 360, 3.85:1 at 1280) than the art
* (2.222:1), so `cover` is width-bound. With no horizontal slack there is
* nothing for `object-position`'s x to pan across: on these two pages it is
* INERT at every width, and the y slack only moves an already-centred
* subject. Neither `contain` nor `fill` helps -- `contain` scales the art
* DOWN (the subject would shrink from 77.6% of the band to 44.8% at 1280,
* the opposite of "closer in"), and `fill` stretches pixel art 1.7:1.
*
* So the request is not reachable on the `object-fit` axis, and the reason is
* the art, not the rule. Measured with PIL against the committed sources:
*
* art (10000x4500) ink bbox of the frame
* hero-banner.png (home) 4977 x 2016 49.8%w 44.8%h
* hero-banner-vector-20260412...(resi) 3114 x 2016 31.1%w 44.8%h
*
* Half to two thirds of each file is EMPTY MARGIN, and that margin is
* rgb(30, 58, 95) -- byte-identical to `--navy: #1E3A5F`, the colour `.hero`
* is already painted. So the band was spending most of its area drawing navy
* onto navy, and the drawn subject sat at x=74.2% / 72.6% of the frame:
* jammed against the right edge with the left half empty. That is what
* "double cropped ... should be closer in" and "needs to be filled and closer
* in on the house icon" describe.
*
* THE FIX IS TO FRAME THE BAND ON THE INK, and because the discarded margin
* is the hero's own navy, clipping it costs nothing visible.
*
* transform: scale(S) translateX(T) -- translate applies FIRST
*
* T moves the ink's centre to the band's centre: T = 50% - .
* The whole source width is on screen (above), so source-x% and band-x% are
* the same axis and one T holds at every width. S then zooms about the band
* centre, which the translate has just put the ink on, so S and T are
* independent -- change one without recomputing the other.
*
* S IS 90% OF THE LARGEST ZOOM THAT STILL CLIPS NOTHING, per breakpoint:
*
* S = 0.9 * min(100 / ink-width-as-%-of-band, 100 / ink-height-as-%)
*
* The 10% is headroom, and it is why the User's "not cropped" survives being
* zoomed: at every width below the subject ends up at exactly 90% of
* whichever band axis binds first, so no part of the artwork can reach an
* edge. The two breakpoints need different S because the band's aspect ratio
* changes (2.25:1 vs 3.85:1) while the art's does not -- the same reason
* `--hero-banner-h` itself is forked at 48rem.
*
* page width ink in band (before) S ink in band (after)
* home 360 49.8%w 45.4%h 1.81 90.0%w 82.1%h
* home 1280 49.8%w 77.5%h 1.16 57.7%w 89.9%h
* residential 360 31.1%w 45.4%h 1.98 61.7%w 89.8%h
* residential 1280 31.1%w 77.5%h 1.16 36.1%w 89.9%h
*
* Both pages share S at 1280 because both inks are 2016px tall and the
* height binds there; they differ at 360 because the width binds for home
* (its ink is 4977px wide) and the height still binds for residential.
*
* NO VERTICAL TRANSLATE. Both ink boxes are already centred vertically in
* their source (y centre 49.7% and 49.5%), which is under 3px of band at
* 1280. Correcting that would be noise dressed up as precision.
* ------------------------------------------------------------------ */
.hero__media.hero__media--home img {
/* ink centre x = (4928 + 9904) / 2 / 10000 = 74.2%, so T = 50 - 74.2. */
transform: scale(1.81) translateX(-24.2%);
}
.hero__media.hero__media--residential img {
/* ink centre x = (5702 + 8815) / 2 / 10000 = 72.6%, so T = 50 - 72.6. */
transform: scale(1.98) translateX(-22.6%);
}
@media (min-width: 48rem) {
/* The 48rem half, gated on the same breakpoint as `--hero-banner-h` itself
and for the same reason: the band goes from 2.25:1 to 3.85:1 there while
the art's ratio does not move, so the axis that binds the zoom changes
from width to height. Both pages land on the same S because the height
binds for both and both inks are exactly 2016px tall. T is unchanged --
the whole source width is on screen at every width, so the translate that
centres the ink is breakpoint-independent. */
.hero__media.hero__media--home img {
transform: scale(1.16) translateX(-24.2%);
}
.hero__media.hero__media--residential img {
transform: scale(1.16) translateX(-22.6%);
}
}
/* ------------------------------------------------------------------
* THE PHOTOGRAPH PAGES ARE THE OPPOSITE CASE and are fixed on the
* `object-position` axis alone, with no transform: their sources are much
* TALLER-ratio than the band, so `cover` is height-bound, there is a great
* deal of vertical slack, and the only question is which horizontal slice of
* the picture the band shows. Measured before this round:
*
* page source of the source visible at 360 at 1280
* about 2160 x 2160 44.4% of the height 26.0%
* iaq 3630 x 2160 74.6% 43.7%
*
* For `object-position: center Y`, the visible source band is
* [Y*(1-v), Y*(1-v)+v] where v is that visible fraction -- which is how the
* windows below were chosen rather than nudged.
* ------------------------------------------------------------------ */
.hero__media.hero__media--about img {
/* THE STANDING TECHNICIAN WAS DECAPITATED AT DESKTOP. His head occupies
source y 29-41%; the centred 26% window at 1280 was y[37.0, 63.0], so
only his chin and below survived. 38% moves the window to y[28.1, 54.1]
-- his head is whole, and the kneeling technician's head (y 49-62%) keeps
its top half. Both heads together span 33% of the frame and the desktop
window is 26% tall, so they CANNOT both fit and this is a choice, not a
tuning: the standing technician has his hands on the gas-valve wiring and
is the subject of the alt text. At 360 the window is 44.4% tall and lands
at y[21.1, 65.5], which holds both heads in full. */
object-position: center 38%;
}
.hero__media.hero__media--iaq img {
/* THE SUNSET WAS THE POINT AND IT WAS SITTING ON THE BOTTOM EDGE. The
mountain ridge runs across source y 66-71% and the glow above it y
58-69%; the centred 43.7% window at 1280 was y[28.2, 71.9], so the ridge
landed hard against the bottom of the band and the whole foreground was
gone. 60% moves the window to y[33.8, 77.5]: the glow and the ridge sit
inside it with a strip of grassland under them. At 360 the window is
74.6% tall and barely moves (y[12.7, 87.3] to y[15.2, 89.8]), which is
correct -- there was nothing wrong with the mobile crop. */
object-position: center 60%;
}
/* /commercial-hvac-arvada AND /duct-cleaning-arvada ARE DELIBERATELY ABSENT,
* and their absence is a measured decision rather than an omission.
*
* COMMERCIAL asked to "fill the space" (spec sec. 1.1) and already does:
* commercial-hero.png is 3150x779, a 4.04:1 scene with ink edge to edge and
* no empty margin at all, and under the shared box `cover` shows 55.6%w/100%h
* at 360 and 95.1%w/100%h at 1280 -- the band is full on both axes at both
* widths. The request was raised against the pre-2026-09-06 layout, where
* that page's band rendered 88.9px at 360; the shared height already answered
* it (+80%, recorded in the rationale block above). Every fit available here
* would make it worse: sec. 1.1 works out that `contain` renders this art
* ~89px tall inside the 160px mobile band, "the exact opposite of fill the
* space". So the correct change is none.
*
* DUCT-CLEANING has no hero image at all. It is BLOCKED on a photograph the
* User is supplying (spec sec. 0.2 item 3, sec. 4.1) and must not be given a
* placeholder or another page's art. Its bare `call hero()` passes no
* `framing`, so nothing here selects it and its empty `.hero__media` renders
* exactly as before -- which is the point: the band is emitted on that page
* too, and it is what proves "the same size everywhere".
* ================================================================ */
/* ==================================================================
* 2026-09-10 -- THE HOMEPAGE HERO ART, PUT WHERE THE USER ASKED FOR IT
*
* This supersedes the 2026-09-09 `--home` framing above. That pass moved the
* art but did not land it: the User reported three defects against the live
* render, and they are one defect wearing three hats.
*
* 1. On a phone the art sat behind the PARAGRAPHS. Measured at 360: the
* band ran 354.1-514.1 while the headline ran 79.4-184.3 and the lead
* started at 202.5, so the artwork was 170px BELOW the last line it was
* supposed to be behind. Cause: `.hero__media` is `inset: 0 0 0 0` with
* a definite height and `margin-block: auto`, which CENTRES the band in
* a `.hero` whose height comes from the copy. The homepage's mobile copy
* is 745px tall, so a 160px band centres at mid-paragraph.
* 2. The ink was horizontally CENTRED -- measured centre x = 49.9% at all
* four widths -- because `translateX(-24.2%)` above exists precisely to
* drag it there. The User wants the source's own composition back: empty
* space on the LEFT, figures on the RIGHT of the headline.
* 3. On a real desktop window the hats and feet were cut off. Measured at
* 1920: ink 449.0px tall in a 332.8px band, clipped 60.9px at the top
* and 55.3px at the bottom. NOT visible at 1280 (ink 299.3px, fits),
* which is why the 2026-09-09 pass missed it -- 1280 was the widest
* viewport anyone had measured. Cause: the band is wider-ratio than the
* art at every desktop width, so `object-fit: cover` is WIDTH-bound and
* the rendered ink height is 0.2016 x viewport width, while the band's
* height is fixed in rem. The two cross at ~1651px and everything above
* that clips. A scale tuned at one width cannot fix a defect whose size
* is a function of width.
*
* THE MECHANISM: SIZE THE FRAME, DON'T ZOOM IT. `object-fit: cover` draws the
* whole source and crops NOTHING when the box it fills has the source's own
* aspect ratio. hero-banner.png is 10000x4500 = exactly 20:9, so an ![]()
box
* of `h` by `h * 20 / 9` renders the complete frame at a size we chose. `h` is
* in rem, so the rendered ink is the same number of pixels at 360 and at 4000
* and symptom 3 cannot come back at ANY width -- it is not tuned out, it is
* designed out. `object-fit` stays `cover` and `object-position` stays
* `50% 50%` (both inert at this ratio: zero slack on either axis), so the
* shared rules and their guard test are untouched, and spec sec. 0.8's
* finding that an `object-fit` FORK is inert still holds -- this is not one.
*
* INK GEOMETRY, measured with PIL against the committed source (bbox of every
* pixel that differs from the rgb(30,58,95) margin, which is byte-identical to
* `--navy`):
*
* bbox (4928, 1229) - (9905, 3245) of 10000 x 4500 = 4977 x 2016
* x 49.28% .. 99.05% y 27.3111% .. 72.1111%
*
* so for a frame of height A and width W = A * 20/9:
*
* ink height = 0.448 * A ink width = 0.4977 * W = 1.106 * A
* ink top = 0.273111 * A below the frame's top
* ink right = 0.0095 * W = 0.0211111 * A left of the frame's right edge
*
* The 0.0095 term is why `right` below subtracts it: we are positioning the
* INK's right edge, not the file's, and the file carries a right margin.
*
* A IS CHOSEN SO THE INK IS AS TALL AS THE HEADLINE, which is what "aligned
* with the headline" means in pixels. Measured heights of the h1's own text
* rects: 106.9px at 360, 182.6px at 768 and above (the `clamp()` caps at
* 3.25rem, so 768, 1280 and 1920 all render the same type).
*
* A = 15rem -> ink 265.4 x 107.5 (mobile; headline 106.9)
* A = 25.5rem -> ink 451.3 x 182.8 (>=48rem; headline 182.6)
*
* THE BAND IS TOP-PINNED ON THIS PAGE, AND ONLY ON THIS PAGE. The art cannot
* reach the headline from a centred band -- at 360 the band's top is 290px
* below the headline's, and `overflow: hidden` stops the ![]()
escaping it.
* So `.hero__media--home` re-pins the band to the hero's top, which puts the
* headline inside it at every width, and the ![]()
is then placed within the
* band. The 2026-09-06 "center-justified instead of top" decision still
* governs the other five pages;
* `test_hero_banner_band_is_vertically_centred_in_the_hero` now asserts
* centring on those five and top-pinning here, so neither can drift.
* The band's HEIGHT and the art's 0.2 OPACITY are untouched -- the shared box
* is not forked, only the band's offset inside its own hero.
*
* 0.875rem = 14px is measured, not assumed: `.hero__inner` has 1rem of top
* padding and the h1's first line rect starts 2px above its border box (half
* leading), so the headline's first glyph row is 14px below the hero's top on
* every width. Putting the ink's top there aligns art and type by their tops.
*
* HORIZONTALLY THE INK'S RIGHT EDGE MEETS THE CONTENT COLUMN'S RIGHT EDGE,
* derived from `--wrap` and `--gutter` rather than re-typed, so it tracks the
* headline if either token moves. Everything to the ink's left is empty --
* 74.6px at 360, 712.8px at 1280, 1032.8px at 1920 -- which is the voidspace
* the User asked for, and the figures read as standing to the right of the
* headline. There is no `translateX` any more; the source's own composition
* is the point, and dragging it to centre was the bug.
* ================================================================== */
.hero__media.hero__media--home {
/* `bottom: auto` is the whole change: it un-over-constrains the box, so the
auto block margins that centred it resolve to zero and `top: 0` wins.
Left, right and height are exactly as the shared rule set them. */
inset: 0 0 auto 0;
margin-block: 0;
}
.hero__media.hero__media--home img {
--home-art-h: 15rem;
--home-art-w: calc(var(--home-art-h) * 20 / 9);
position: absolute;
width: var(--home-art-w);
height: var(--home-art-h);
/* MEASURED, NOT DEFENSIVE. The base `img { max-width: 100% }` at :115 is
narrower than the frame below 48rem (533.3px of frame in a 360px band)
and silently clamped it to the band's width, which un-does the 20:9 ratio
the whole approach rests on -- `cover` then crops after all. It does not
bind at 1280, so this reproduced ONLY at mobile widths. */
max-width: none;
/* ink top -> 14px below the hero's top, i.e. the headline's first line. */
top: calc(0.875rem - var(--home-art-h) * 0.273111);
/* ink right -> the content column's right edge. `100%` is the band, which
is the viewport; the max() is `.wrap`'s auto margin, and it collapses to
0 below --wrap exactly as `margin: 0 auto` does. */
right: calc(
max(0px, (100% - var(--wrap)) / 2) + var(--gutter)
- var(--home-art-w) * 0.0095
);
/* Replaces `scale(1.81) translateX(-24.2%)` and its 48rem sibling above.
The frame is sized and placed outright now, so there is nothing to zoom
and nothing to pan. */
transform: none;
}
@media (min-width: 48rem) {
/* Same breakpoint as `--hero-banner-h`, for the same reason it was forked
there: the headline's type stops growing at 3.25rem here, so the ink
height that matches it changes exactly once. Only the one variable moves;
every offset above is written in terms of it. */
.hero__media.hero__media--home img {
--home-art-h: 25.5rem;
}
}
/* ==================================================================
* 2026-09-10 (SECOND PASS) -- THE DESKTOP ART, GROWN TO ITS CEILING
*
* A USER DECISION ON A TRADEOFF THE FIRST PASS DOCUMENTED. That pass tied
* `--home-art-h` to the headline's measured type height, so the ink was
* exactly as tall as the words (182.6px of type, 182.8px of ink at >=48rem).
* Review observed that this left the navy band two thirds empty -- 182.8px of
* ink in a 332.8px band -- and that because the no-clip mechanism is the
* source's own 20:9 ratio in rem, it is clip-proof at ANY size, so a bigger
* desktop figure was available for the asking. The User asked. This is that.
*
* WHAT ACTUALLY LIMITS THE SIZE, MEASURED IN CHROMIUM RATHER THAN REASONED:
* it is NOT the band. The ink's top is pinned to the headline's first line of
* type (that is symptom 1 and it does not move), so every rem of extra height
* is spent downwards, and the first thing below the headline is the lead
* paragraph. The band has 136px of slack under the ink; the lead has 29.8px.
*
* at >=48rem, page pixels, homepage:
* ink top 95.6 (= hero top + 14px, fixed, independent of A)
* headline type 95.6 - 278.2
* lead top 308.1
* band 81.6 - 414.4
*
* ink height = 0.448 * A, so clearance(A) = 308.1 - 95.6 - 0.448 * A
*
* A = 25.5rem (408px) ink 182.8 clearance 29.8 <- first pass
* A = 28rem (448px) ink 200.7 clearance 11.9 <- HERE
* A = 28.54rem(456.6px) ink 204.5 clearance 8.0 <- the test's floor
* A = 29.66rem(474.5px) ink 212.5 clearance 0.0 <- ink TOUCHES the lead
* A = 44.5rem (712px) ink 318.8 clearance -106 <- where the BAND
* would have bound
*
* So the honest ceiling is 29.66rem, not "the band is 332.8 tall so make the
* art 332.8". Between 29.66rem and 44.5rem the art is inside the band and on
* top of the body copy, which is the defect the User reported first
* ("it should overlap the HEADLINE only"). Measured at 32rem: the ink ends
* 16.8px BELOW the lead's first line.
*
* 28rem IS CHOSEN WITH THAT MARGIN STATED: 1.66rem (26.5px of frame, 11.9px
* of ink) below the touch point, and 0.54rem below the 8px floor
* `HOME_INK_LEAD_CLEARANCE_PX` asserts. 28.5rem measures 8.3px of clearance --
* inside the floor by 0.3px -- which is a hair-trigger, not a margin, so the
* last half-rem is deliberately left on the table.
*
* WHAT IT BUYS: ink 451.2 x 182.8 -> 495.5 x 200.7, +9.8% on each axis and
* +20.6% of area. Modest, because the vertical budget was only ever the
* headline-to-lead gutter. Reported as such rather than dressed up.
*
* THE OTHER FIVE CONSTRAINTS ARE MEASURED, NOT ASSUMED, at 360/768/1280/1920/
* 2560 (`test_home_hero_art_is_whole_and_sits_right_of_the_headline`):
*
* - CLIPPING stays zero at every width. It is structural, not tuned: only
* `--home-art-h` moves and it stays in rem, so the ink is the same 200.7px
* at 1280, 1920 and 2560 and the test's spread assertion still states it.
* Nothing viewport-relative enters the chain -- that would kill
* width-independence, which is the whole fix.
* - THE BAND still contains it with 118.1px to spare at >=48rem.
* - VOIDSPACE ON THE LEFT survives: a taller frame is a wider frame and it
* grows leftwards from a pinned right edge, so this had to be checked.
* Ink centre 65.1% / 71.6% / 64.4% / 60.8% at 768 / 1280 / 1920 / 2560
* (was 68.0 / 73.3 / 65.5 / 61.7; floor 55%), void to its left 32.9% /
* 52.2% / 51.5% / 51.1% (was 38.6 / 55.7 / 53.8 / 52.8; floor 15%). The
* narrowest desktop width, 768, is the worst case and clears by 17.9pts.
* - THE INK'S TOP is untouched: `top` is written as
* `0.875rem - A * 0.273111`, which cancels A out of the ink's top edge
* exactly, so the alignment holds at any A. Measured gap to the
* headline's first line: under 0.01px at every width.
* - MOBILE DOES NOT MOVE. This override is inside the same 48rem query as
* the value it replaces; the 15rem below it is untouched, and the shrink
* there is forced (at 360 the headline ends 184.3px in and the lead starts
* 202.5px in -- 18.2px of slack, and the ink already uses all but 17.6 of
* it). Measured identical to 4 decimal places at 360 across every
* candidate from 25.5rem to 32rem.
*
* APPEND-ONLY, so the 25.5rem figures in the block above are left standing as
* the record of the first pass; this block supersedes them. `--hero-banner-h`,
* `HERO_BAND_H`, the 0.2 opacity, the 20:9 mechanism, every offset `calc()`
* and all five other pages are untouched -- one variable moves.
* ================================================================== */
@media (min-width: 48rem) {
.hero__media.hero__media--home img {
--home-art-h: 28rem;
}
}
/* ================================================================
* HOMEPAGE SECTIONS PASS -- User mobile review 2026-09-10.
* Two rules, both new, both added for markup that moved on index.html.j2.
*
* COMPOUND / DESCENDANT SELECTORS ON PURPOSE. A BEM `--modifier` is ONE class
* and ties with its base rule, winning only on source order (spec sec. 0.4),
* and this stylesheet is append-only with other branches landing at its end.
* Neither rule below may depend on where it sits in the file:
* `.card .offer-badge` is (0,2,0) against `.offer-badge`'s (0,1,0), so it
* wins on specificity, not order.
* `.card__offer-line` is a brand-new class with no competing rule at all.
* ================================================================ */
.card .offer-badge {
/* The badge moved INSIDE the commercial card (item 3). `.offer-badge` sets
`margin: 0`, which was right when it was the only child of its own
`section--offer`; in a card it now has a Learn More button under it and
needs flow spacing. Scoped to `.card` so commercial-hvac-arvada.html.j2's
copy of the badge -- which is NOT in a card and shares every
`.offer-badge*` rule with this one -- is untouched.
Contrast is unchanged by the move: the badge paints its own `--pale`
background, so its text measures the same here as it does anywhere,
whatever sits behind it. Since the sec.7 pass (2026-09-11) that text is
`--navy` on `--pale` = 9.48:1; it was `--orange-dark` at 3.51:1. */
margin: 0 0 1.25rem;
}
.card__offer-line {
/* The residential card's dated furnace-replacement line (item 4).
SIZE WAS A CONTRAST DECISION, NOT A TASTE ONE. `--orange-dark` measured
4.26:1 on the card's white background -- under WCAG AA's 4.5:1 for body
text, over the 3:1 that applies to large text -- so 1.2rem (19.2px) at
weight 700 was required to clear WCAG's 18.66px bold bound, which 1.15rem
(18.4px) would NOT have.
The sec.7 palette pass (2026-09-11) moved this to `--orange-cta`
(4.85:1 on this card's white background), so the colour now passes AA
at ANY size and
the size is no longer load-bearing for contrast. It is kept at 1.2rem/700
as a typographic choice, and a test asserts both. */
color: var(--orange-cta);
font-family: var(--font-head);
font-weight: 700;
font-size: 1.2rem;
}
/* ================================================================
* Footer badges 2x2 + Contact Us removal (User mobile review 2026-09-10).
*
* Appended overrides rather than in-place edits, per this file's
* append-only convention. Uses the `.site-footer__badges--grid` modifier
* CLASS added in `_footer.html.j2`, compounded with the base class, so the
* override wins on genuine specificity -- NOT on source order. (An earlier
* commit on this branch mis-justified a bare-selector repeat as following
* "the same pattern as the Phase 1b banner above" -- that citation was
* wrong: the Phase 1b block is a comment divider, not a rule, and no such
* precedent exists in this file. Retracted; see spec §0.4, which documents
* this exact same-specificity/source-order trap for BEM modifiers and is
* the actual authority here.)
*
* WHY: the User asked for all four credential badges (three existing +
* the BBB mark, moved up out of the legal strip) in one 2x2 block, and
* for the footer's "Contact Us" heading/phone/email to go, since they
* duplicate the pinned mobile call bar and the desktop header phone CTA.
*
* SUPERSESSION: `.site-footer__badges`'s base-rule comment above
* ("Kept to one row... item 1.11") describes a flex `nowrap` fix for
* THREE badges wrapping 2+1 at 360px. That concern cannot recur here --
* a CSS grid with a fixed 2-column track lays out 2x2 unconditionally,
* it does not wrap at all. This is a deliberate new instruction from the
* same User, not a regression of the 2026-09-07 fix.
*
* COHERENT SET, BBB EXCEPTED (User decision 2026-09-10, review round 2):
* the three credential badges are 120x120 and keep the square
* `aspect-ratio: 1/1` + `object-fit: contain` treatment below. The BBB
* mark's source raster is measured at 3840x2160 (16:9) -- the markup's
* OLD `140x60` attributes (neither the real ratio nor the real pixel
* count) were only ever a pre-load size hint; `_footer.html.j2` now
* carries `width="160" height="90"`, a 16:9 pair matching the measured
* raster, so the pre-CSS reserved box already has the right shape.
* Forcing 16:9 art into a 1:1 box left it letterboxed to the vertical
* middle third of its white card, reading as a smaller, lighter
* afterthought next to the three edge-to-edge circular badges. The BBB
* cell now gets its own `aspect-ratio: 16/9` (see the `img.bbb-badge`
* rule below) so the mark fills its card the way the other three fill
* theirs, while `.bbb-badge`'s white-card background/border/padding
* (site.css:1128-1138) is untouched -- the mark must stay legible on navy
* regardless of shape.
*
* DESKTOP: measured at 1280px, the footer `.wrap` caps at 68rem (1088px)
* minus gutters, so a `2fr 1fr` grid gives the badges column roughly
* 320-340px -- enough for a comfortable 2x2 block (2 x 120px badges +
* gap), but a single row of 4 badges (~530px incl. gaps) would not fit
* without either shrinking the badges below their mobile size or taking
* width from the service-area column. 2x2 at every width was chosen so
* the badge footprint never changes, and to avoid recreating the exact
* class of uneven-wrap bug item 1.11 was fixed for, now with a fourth
* badge in the mix. The grid's 2 equal-`fr` columns are computed from the
* container, not from item content, so letting the BBB cell's own image
* grow wider than 120px (below) cannot itself widen its track or knock
* the 2x2 crooked -- it just fills more of the track it already has.
* ================================================================ */
.site-footer__badges.site-footer__badges--grid {
display: grid;
grid-template-columns: repeat(2, 1fr);
gap: 1rem;
align-items: center;
}
.site-footer__badges.site-footer__badges--grid img {
/* `width: 100%; max-width: 120px` -- NOT `width: auto`. Measured: with
`auto`, Chromium collapses the box to 0x0 at 360px before the image
finishes loading, because there is no other definite size for
`aspect-ratio` to resolve against pre-load. `100%` gives every badge a
definite size from its grid track immediately, then `max-width` clamps
it. Also measured: `justify-items: center` has no visible effect once
width is a percentage (Chromium places the clamped box at the track's
start edge, not centered) -- removed rather than left in as a comment
that doesn't match what renders. The result is still a clean, evenly
offset 2x2 (both columns' badges share one left edge; verified at
360px and 1280px), just not centered within each cell. */
width: 100%;
max-width: 120px;
aspect-ratio: 1 / 1;
object-fit: contain;
}
.site-footer__badges.site-footer__badges--grid img.bbb-badge {
/* Higher specificity (0,3,1) than the generic img rule above (0,2,1),
so this wins unconditionally, not on source order. No `max-width`: the
grid track (fixed by the 2-column layout, independent of content) is
already the card's outer bound, so the image fills exactly to the
track's edge at every width instead of stopping at an arbitrary
square-badge number that has nothing to do with its own ratio. The
16/9 figure is the raster's measured intrinsic ratio (3840x2160), not
the markup's now-corrected `160x90` size hint -- see the block
comment above. */
aspect-ratio: 16 / 9;
max-width: none;
}
@media (min-width: 48rem) {
/* Contact Us column removed from the footer grid (User mobile review
2026-09-10) -- was `2fr 1fr 1fr` (area / contact / badges). Two
columns remain; badges keep roughly their prior share of the row.
Review round 3, Fix A: `.site-footer__grid` alone is (0,1,0), the exact
same specificity as the base override at line ~1206 (also (0,1,0), also
inside this same media query) -- they tie and this one only won because
it sits later in the file, which is the trap this file's own review
process exists to catch. `.site-footer__grid` only ever appears as the
`