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-dark 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.
MEASURED, AND NOT RESOLVED HERE: --orange-dark (#D1520E) is 4.26:1 against
the white .section background, i.e. BELOW WCAG AA's 4.5:1 for normal-size
text. (--orange is worse at 3.08:1; --blue-mid is 5.99:1, which is why the
two "light blue" rules above cite their numbers.) This is a pre-existing
site-wide condition, not something introduced here: `.icon-list--accent-
orange li` already sets body copy in this token on the commercial page.
Recorded rather than silently re-coloured, because picking a darker orange
would fork the one accent orange this site has. */
.tag-list--accent-orange li {
color: var(--orange-dark);
}
/* 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-dark token as the rules
above, deliberately -- one accent orange sitewide. Same pre-existing
4.26:1-against-white contrast noted above; not re-measured or re-litigated
here. */
.text--accent-orange {
color: var(--orange-dark);
}
.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;
}
/* -------------------------------------------------------- trust strip -- */
/* The credential badges where a page repeats them mid-body. The footer keeps
its own copy; this one wraps rather than overflowing at 360px. */
.trust-strip {
display: flex;
flex-wrap: wrap;
align-items: center;
justify-content: center;
gap: 1rem;
margin: 1.5rem 0 0;
}
.trust-strip img {
image-rendering: pixelated;
}
/* --------------------------------------------- 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".
* ================================================================ */