/* tc-site-chrome.css — browser chrome the old theme styled and Bricks does not. WHY THIS EXISTS The fearless-aiims theme narrows the scrollbar site-wide (source/tailwind/tailwind.css, the "Modern scrollbar" block just under the `body` rule). Bricks has no control for this, and no Bricks global class can express `*` or `::-webkit-scrollbar`, so it was never ported. WHY IT IS A PARITY BUG AND NOT COSMETICS The scrollbar width is subtracted from the layout viewport but NOT from `vw` units. Production's scrollbar is 10px; a stock one is 15px. That 5px changes: - every `clamp(..., vw, ...)` heading, because the clamp reads `vw` (unaffected) while the text wraps inside the layout viewport (5px narrower) — measured 62.0767px vs production's 62.8877px on the referral hero h1 at a 1490 viewport; - `.container` width — 1475 vs production's 1480, which cascades into every column width on every page; - the hero's `w-screen` / `lg:w-[50vw]` bleed column, which is sized in `vw` and offset by a fixed -20px, so a wider scrollbar pushes it into horizontal overflow. Verified July 30 2026: production reports innerWidth 1490 / clientWidth 1480 at desktop and 390 / 380 at mobile — a 10px scrollbar at both. Ported verbatim from the theme; the colour literals become --tc-* tokens. `--tc-primary` is #0457A5, the theme's `rgb(var(--brand-primary))`. */ /* ══ HERO TOP OFFSET ════════════════════════════════════════════════════════ The header is `position: fixed`, so the first section on every page has to reserve its height. Production measures the header in JS and sets the hero container's margin-top from it, so the offset tracks the logo's `vw` clamp continuously: 88.00 @1490, 126.24 @1200, 124.60 @1000, 123.60 @800, 127.60 @400. Ours was two constants — 88px, and 128px below xl — living in the Customizer's Additional CSS (Appearance -> Customise -> Additional CSS, printed inline as #wp-custom-css): body:not(.home) main#brx-content > section.brxe-section:first-of-type { padding-top: 88px } plus a 128px variant of the same rule inside @media(max-width:1279px) That is the right SHAPE — one rule, every page, no per-element duplication — so it is kept and only the value is replaced. tc-header-offset.js publishes the measured height as `--tc-header-h`; 88px is the desktop fallback for a no-JS load. The leading `html` is deliberate: #wp-custom-css is printed inline in the head and would otherwise win on source order at equal specificity. This makes it (0,4,4) against their (0,4,3), so it wins wherever it sits. NOTE the 18 hero sections also carry an element-level `padding-top: var(--tc-header-h, 88px)`. They agree with this rule and act as a fallback if the global one is ever edited away; they do not fight it. */ html body:not(.home) main#brx-content > section.brxe-section:first-of-type { padding-top: var(--tc-header-h, 88px); } /* ══ PORTABILITY: the last hard-coded twoconnect.test asset URL ══════════════ Every background image in the Bricks data is now stored ROOT-RELATIVE, because Bricks emits `_background.image.url` VERBATIM into the page's inline CSS — it does not re-resolve it from the attachment id (proved by setting one to `/wp-content/...` and watching the emitted rule change to match). So an absolute `https://twoconnect.test/...` there would survive a domain change and 404 on the new host. ONE rule was not in the Bricks data at all: Appearance -> Customise -> Additional CSS carries a page-scoped override for the advantages component on Premium Talent (page 390), with an absolute URL: body.page-id-390 .brxe-82cadc{background-image:url(https://twoconnect.test/wp-content/uploads/2026/05/bg-img-006.png)} The Customizer is not on disk, so it is overridden here instead of edited — same trick as the `#wp-custom-css` note above: (0,2,2) with the `html` prefix beats their (0,2,1) regardless of source order. TODO (one-line manual cleanup): delete that single line from Additional CSS. Until then this rule wins and the site is portable either way. */ html body.page-id-390 .brxe-82cadc { background-image: url('/wp-content/uploads/2026/05/bg-img-006.png?lm=6A79C5EA'); } /* ══ BugHerd #24 — the stat strip is GREY on Culture only ════════════════════ Production's Culture page gives the stat strip `#E9ECEF` (rgb(233,236,239)) — the same grey as the "Remote Collaboration" section directly above it, which is exactly what the ticket asks for ("background should be the grey colour above"). Ours rendered transparent. It has to be PAGE-SCOPED. `40b4e8` is the shared TC Stat Strip component and it is transparent everywhere else (the homepage included), so putting the colour on the component would wrongly grey it site-wide. Component instances also drop instance-level settings, so a per-instance background is not an option — same constraint that forced the page-scoped rule for `82cadc` on Premium Talent. `html` prefix for the same reason as the rules above: it has to outrank the inline `#wp-custom-css` block at equal specificity. */ html body.page-id-1237 .brxe-40b4e8 { background-color: #e9ecef; } /* ══ CLS: --tc-header-h NEEDS A RESPONSIVE CSS DEFAULT ══════════════════════ tc-header-offset.js runs in the , so at that point
has not been parsed yet and there is nothing to measure — the first successful measurement lands after the document parses. Until then every consumer of the variable falls back to the literal in the `var()`, which was the DESKTOP value (88px). On mobile the real header is 128px, so the hero painted 40px too high and then dropped when the script published the true value. Measured in a real 482px window: CLS 0.0553, of which 0.0465 was one shift at 3.29s with `#brxe-hhctr0` moving y 88 -> 128 and the hero photo strip following it down. Fixing it in JS is not possible — anything that has to read the DOM is already too late. So the variable gets a CSS default per breakpoint that ALREADY equals the height the header will measure, and the script then only refines it by a pixel or two (no visible shift). Values are the measured header heights recorded in tc-header-offset.js: 88.00 @1490, 126.24 @1200, 124.60 @1000, 123.60 @800, 127.60 @400. Bricks' desktop breakpoint is 1279 and the <=1279 header carries the extra full-width CTA row, which is what makes it tall — hence the step at 1280. */ :root { --tc-header-h: 128px; } @media (min-width: 768px) { :root { --tc-header-h: 124px; } } @media (min-width: 1024px) { :root { --tc-header-h: 126px; } } @media (min-width: 1280px) { :root { --tc-header-h: 88px; } } /* ══ BUTTON DEFAULTS ════════════════════════════════════════════════════════ Bricks ships `.bricks-button { letter-spacing: .5px; gap: 10px }` in frontend-layer.min.css. Production's `.btn` (theme tailwind.css ~line 271) is `gap-3` with letter-spacing left at `normal`. Measured July 30 2026 on /thank-you/ at a 1490 viewport: production's "CLICK HERE TO GO BACK TO THE HOME PAGE" button is 426.50px, ours was 445.50px — 19px wider, which is exactly 38 characters x 0.5px. The same 0.5px was on EVERY Bricks button on the site, including the header and footer CTAs, so this is fixed once here rather than per element. Bricks' rule lives in a cascade layer, so unlayered CSS beats it outright; the single class is enough and no !important is needed. */ .bricks-button { letter-spacing: normal; gap: 12px; } /* ══ FOOTER NAV — the 1px placeholder that cost a line ══════════════════════ Bricks' nav-menu ships `:where(.brxe-nav-menu) .bricks-nav-menu > li { margin-left: 30px }`. All four footer menus reset it correctly on their own element (`#brxe-8niqd6|kwy1r0|0sdi1p|1u5887 .bricks-nav-menu>li{margin:0}`), but the footer SECTION also carried a stale retry block: #brxe-78zydz .bricks-nav-menu li:not(#tcnull) { margin-left:1px; margin-right:1px } At (2,2,1) that beat all four, and those two placeholder pixels were real: they took the industries column's li from 205px to 203px, and "Construction & Engineering" measures 203.77px at 16px Manrope. It wrapped to a second line — 24px taller than production, on every page. The same 1px also made the copyright menu 254px against production's 249px. Measured July 31 2026 at a 1900 viewport: production li 205 / height 24, ours 203 / height 48. The section block is now deleted (template 3557). This rule is what replaces it. It has to live here because Bricks' normalizer DROPS a rule whose only declaration is a zero — an appended `#brxe-f0wpxk .bricks-nav-menu>li{margin:0}` was silently discarded on save, which is how the 1px placeholders got written in the first place. The copyright menu carries no global class, so this is scoped to the footer element rather than to `.tc-footer-nav`. (0,3,3) clears Bricks' (0,1,1). */ html footer .brxe-nav-menu ul.bricks-nav-menu > li { margin-left: 0; margin-right: 0; } /* ══ FORM CONTROL TEXT ALIGNMENT ════════════════════════════════════════════ Bricks ships `button, input, optgroup, select, textarea { text-align: inherit }` in frontend-layer.min.css. Production has no such rule, so its form controls keep the UA default — `start` for text fields, `center` for buttons — regardless of the container. That matters because both sidebar form cards are `text-center` (`.sidebar-case-study-form` and `.sidebar-form-cta` are `p-3 py-[60px] text-center`), so every placeholder inherited `center`: "First name*", "Email*" and friends sat in the middle of their pills where production has them hard left. Measured July 31 2026 on petcover — production `text-align: start`, ours `center`, everything else about the field identical (padding-left 16px, font-size 16px, height 48px). A previous pass hit the same inheritance on the error text and fixed it in place (`.hbspt-form .hs-error-msgs { text-align: left }`), which is why the validation message was left-aligned under a centred placeholder — the tell in the screenshot. Restoring the per-type defaults rather than blanket-resetting: a submit input is centred by the UA and must stay that way. Bricks' rule is in a cascade layer, so unlayered CSS beats it without specificity tricks, and at (0,0,1) this loses to every deliberate alignment already in tc-forms.css. */ input, select, textarea { text-align: start; } input[type="submit"], input[type="button"], input[type="reset"] { text-align: center; } /* ══ SCROLLBAR ══════════════════════════════════════════════════════════════ */ /* Firefox + modern Chromium */ * { scrollbar-width: thin; scrollbar-color: color-mix(in srgb, var(--tc-primary, #0457A5) 40%, transparent) transparent; } /* Safari + older Chromium */ ::-webkit-scrollbar { width: 8px; height: 8px; } ::-webkit-scrollbar-track { background: transparent; } ::-webkit-scrollbar-thumb { background: color-mix(in srgb, var(--tc-primary, #0457A5) 40%, transparent); border-radius: 9999px; } ::-webkit-scrollbar-thumb:hover { background: var(--tc-primary, #0457A5); }