diff --git a/src/styles/global.css b/src/styles/global.css
index 4e67e4a..21845d2 100644
--- a/src/styles/global.css
+++ b/src/styles/global.css
@@ -107,14 +107,18 @@
 }
 
 * { box-sizing: border-box; }
-html { -webkit-text-size-adjust: 100%; scroll-padding-top: 76px; /* sticky header + anchor jumps */ }
-/* Chrome re-scrolls the focused editable into view on EVERY keystroke and
-   honours scroll-padding-top while doing it. Inputs inside the sticky header
-   live above that 76px line by definition, so each typed character triggered
-   a corrective scroll-to-top. Negative scroll-margin cancels the padding for
-   exactly these fields (root cause, not a workaround — the padding exists for
-   in-content anchors, never for header chrome). */
-.nav-search input, .search-pop input { scroll-margin-top: -76px; }
+html { -webkit-text-size-adjust: 100%; }
+/* Anchor jumps (TOC, skip link) must land below the 76px sticky header. That
+   offset used to be a global `html { scroll-padding-top: 76px }` — but Chrome
+   re-scrolls the focused editable into view on EVERY keystroke and honours
+   scroll-padding-top while doing it (crbug.com/41492445: the reveal also
+   ignores the editable's own scroll-margin, so a negative scroll-margin on
+   the header inputs could not cancel it). The header search fields sit above
+   the 76px line by definition and, being sticky, can never be scrolled below
+   it — so each typed character walked the page toward 0. Scoping the offset
+   to the in-content anchor targets fixes typing and keeps every jump
+   (TOC headings, skip link → #main) landing below the header. */
+main, main [id] { scroll-margin-top: 76px; }
 /* Guard, not a solution (DESIGN.md): every wide element is contained at its own
    level (tables scroll in their box, long words wrap); clip only catches
    regressions so one offender can never remove the page gutters. `clip`, unlike