The Bar That Was Always There

The new header did not add a stray element — it exposed one. A pseudo-element from an earlier round had been sitting at the top of every page, hidden by what was stacked above it.

On 2026-06-05, after a header rebuild on a client site — the welding and fabrication shop whose deploy firewall is the subject of the companion post — a thin unexplained bar appeared directly beneath the header on every inner page and nowhere on the home page. The natural reading was that the new header had shipped with an extra row. It had not. The bar was an unqualified body::before pseudo-element defined two rounds earlier, and the new header's own padding-top: 110px had moved it from invisible to obvious.

That is the transferable finding, and it is a diagnostic reflex rather than a CSS trick. When a change you believe is correct surfaces a new symptom, the first question is not what did I break — it is did my change create this element, or merely move an existing one into view. We call the four-step version A Correct Fix Can Expose an Unrelated Defect. The two cases lead to opposite repairs: one reverts, the other removes something that predates you.

Step 1 — Test whether the change created the element or moved it

An unqualified body::before paints as the first box at the top of the body. That single behaviour explains the symptom and the two months of silence before it.

On the home page the body carried no top padding, so the box sat at y=0, underneath the fixed bars that occupy the top of that layout: rendered on every page load, covered on every page load. On inner pages the rebuilt header applied padding-top: 110px to the body, pushing the box to y=110 — the header's bottom edge, exactly where a stray header row would sit.

The two pages differed by one property on one element, and that property belonged to the correct change. The header was not defective. The concealment was.

Why the previous round could not find it

The round before had gone looking for a stray header element and reported there was none. That report was accurate. Pseudo-elements do not appear in an element count: a DOM query returned zero header elements, and the pages carried a body class declaring no header. Both readings were true and both were useless, because — in the source record's words — there was no header object to find. The bar was a paint instruction, not a node.

The definition lived in the theme customizer's Additional CSS field, a 68,502-character blob read in full on 2026-06-05, not in the snippet manager where the round's other CSS sat. It had been written as a CSS-only utility row — a workaround for the deploy firewall in the companion post, which blocks HTML tag-start literals and made a markup-based row undeployable.

Step 2 — Verify against the parsed DOM, never a substring grep

The earlier round had also retired the old header elements by setting them to draft, and verified in a browser that zero such elements remained site-wide. A raw-HTML curl fetch, grepped for the same string, still matched.

Both results were correct. The surviving match lived inside a single page-cache used-CSS block — dead CSS that styles nothing, retained by the cache layer and rendered by nobody. A substring grep sees text; a parsed DOM sees the document the browser actually built. Trust the parsed DOM, not a substring grep, and when the two disagree, establish which artifact you are reading before acting on either.

That round also indicted itself, which is why the next one caught the bar: markup verification alone had missed a defect plainly visible on screen, so the next mandate required visually re-verifying every page type, logged out.

Step 3 — Check specificity before you write the override

The fix is one line — body::before { content: none !important; display: none !important } — and it is worth explaining why that line provably cannot lose rather than asserting that it works.

The original block, confirmed against the backup taken on 2026-06-05, contains zero !important declarations. In the cascade, an important declaration in an author stylesheet beats every non-important one regardless of source order or specificity. With nothing important to compete against, the override wins unconditionally — including here, where the snippet carrying the fix loads before the customizer CSS it overrides. Under normal cascade rules, loading first is losing. It does not matter.

content: none does the second half of the work: it suppresses the generated box entirely rather than restyling it, covering the base rule, a scrolled-state variant and two media-query variants in one declaration. Reading the source rule for !important first takes thirty seconds and converts "this override should work" into "this override cannot fail."

Removing the box also settled the layout without tuning. With the roughly 34-pixel element suppressed, every content wrapper measured on 2026-06-05 landed flush at top:110, the header's exact height. Zero values were adjusted; the orphan had been consuming the difference all along. When a removal makes existing numbers exact rather than requiring new ones, that is corroboration you removed the right thing.

Step 4 — Re-verify visually, per page type, logged out

Verification on 2026-06-05 ran logged out across six page types, with the computed ::before content read from each page rather than inferred from the stylesheet. All six returned none. Twelve screenshots were captured at two viewport widths.

Logged out matters because an administrator session loads toolbars and bypasses caching a visitor never touches. Per page type matters because the defect existed on one class of page, and a single check on the home page would have come back clean.

The causal chain, which is why these two posts belong together

An undocumented origin firewall blocked HTML tag-start literals, which made a markup-based utility row undeployable. A CSS-only row was written instead — correct at the time, and it worked. The firewall constraint later stopped mattering, but the hack outlived its reason, sitting invisible at y=0 behind the fixed bars. Two rounds later a correct header rebuild added body padding, the orphan moved 110 pixels down, and a constraint from an entirely different layer surfaced as a visual defect on every inner page.

Nobody made a mistake in the second round. The defect was a workaround nothing had revisited — and revisiting workarounds after the constraint that forced them has lifted is not a step most build processes contain.

The honest ending

The fix was live at origin the same day and confirmed there. Visitors did not see it for hours.

The CDN edge kept serving stale copies, because the purge token had lapsed and the dashboard that would reissue it sat under an account the operator could not reach. The stale copies expired on their own four-hour TTL, the correct page propagated, and it resolved the same day.

The lesson is not about tokens. "Fixed at origin" and "fixed for the visitor" are two claims requiring two verifications, and a credential you cannot reach is an outage you cannot shorten. Both source records carry status: draft.

What would prove this wrong

• An !important declaration anywhere in the original body::before block. The "cannot lose" argument rests on that count being zero.
• The bar reappearing on any page type with the override active. Then something else paints at y=110.
• Removing the fixed bars on the home page without a roughly 34-pixel box appearing at y=0. The concealment explanation predicts that box exists.
• Content wrappers needing offset tuning after the removal. Had the numbers needed adjusting, the 34-pixel match was coincidence.
• A parsed-DOM query returning a header element on an inner page. That overturns the account of why the prior round came back clean.

Before you assume you broke it

Before assuming your change introduced a defect, check whether it merely revealed one. CSS workarounds written against a constraint that no longer applies are not dormant — they are waiting for a padding value. If one of those is still sitting in a build you own, we will help date it before the next layout change finds it for you.