22 CSS Headers

The classic pattern uses window.addEventListener('scroll', …) in JavaScript to toggle a class on the header when scroll position passes a threshold. That approach still works but costs INP (Interaction to Next Paint) on Core Web Vitals — every scroll event runs the handler on the main thread, which lags on mid-tier mobile. The 2026 pattern uses position: sticky plus a scroll-linked CSS animation defined with @keyframes and animation-timeline: scroll(root) that interpolates background opacity and backdrop-filter from 0 → 1 as the page scrolls past the first 80px. Zero JavaScript, zero scroll listeners, zero CWV impact. Baseline in Chromium 115+ / Safari 18+ / Firefox 130+. Demo 12 is the reference implementation with an @supports (animation-timeline: scroll()) gate and a solid-always fallback for older browsers. Most tutorials still teach the JavaScript pattern because they predate the spec — a real gap developers land on this collection to fill.

The visible layer is pure CSS — the trigger is a search pill in the middle of the header showing 'Search…' and a ⌘K badge, styled as a real search affordance rather than a decoration. Clicking or focusing the pill opens a modal command palette overlay implemented as a native <dialog> element opened via <details> disclosure. The overlay uses backdrop-filter: blur() on the scrim, animates in with a scale-and-fade, and closes when the backdrop is clicked or Escape is pressed (both handled natively by <dialog>). The keyboard shortcut is the only JavaScript — under 15 lines of document.addEventListener('keydown', ...) that checks for event.key === 'k' && (event.metaKey || event.ctrlKey) and calls dialog.showModal(). event.preventDefault() on the match to stop the browser's default 'find in page' shortcut. Linear, Vercel, Raycast, GitHub, Notion, and Cursor all ship this pattern; demo 01 is the copy-paste version. Accessibility: <dialog> handles focus trap and focus return natively when opened with showModal().

Position sticky has three failure modes tutorials rarely mention. First, an ancestor with overflow: hidden (or any overflow value other than visible) creates a scroll container that becomes the sticky's containing block — the header sticks to the ancestor's edge, not the viewport, which usually reads as 'sticky just isn't working'. Fix by moving the sticky element out of the overflow-clipped ancestor, or by promoting the ancestor to overflow: clip where possible (clip creates a paint boundary without a scroll container). Second, the sticky element and its siblings must live in the same containing block — a header inside a wrapper that has contain: layout or transform will detach from the page scroll and stick to its wrapper. Third, position: fixed is NOT a substitute — fixed removes the header from document flow, causing layout-shift (CLS) on load and breaking scroll-timeline animations that depend on the header being part of the flow. Every demo in this collection uses position: sticky; top: 0 for that reason. If sticky misbehaves, run document.querySelectorAll('*').forEach(el => { const cs = getComputedStyle(el); if (cs.overflow !== 'visible' && cs.overflow !== '') console.log(el, cs.overflow); }) in devtools to find the offending ancestor.

Most 'CSS mega menu' tutorials use :hover alone, which fails for keyboard and touch users. The correct pattern uses :focus-within on the parent <li>: the menu panel opens when ANY descendant element receives focus, so tabbing into the trigger button opens the panel and tabbing through the items keeps it open until focus leaves. Pair with :hover on the same parent for pointer users. Every trigger is a real <button> (not a <div> or <a href='#'>) with aria-haspopup='menu' and aria-expanded reflecting state. The panel wrapper is role='menu' and each item is role='menuitem' — screen readers announce 'menu, 4 items' when the panel opens. Use transition-behavior: allow-discrete (Baseline 2024) so visibility transitions cleanly instead of the panel remaining hit-testable while invisible. Demo 13 is the CSS Grid mega menu reference, demo 21 is the 3-level nested dropdown, demo 10 is the notification-bell + user-menu combined pattern — all keyboard-navigable without JavaScript. This matters on real e-commerce and docs sites where 30-40% of navigation traffic comes from keyboard-heavy workflows (autocomplete, screen reader, mouse-lost, external keyboards).

The pattern is a visually-hidden <input type='checkbox'> plus a <label> styled as the sun/moon toggle, plus :has(:checked) on the header root that rewrites CSS custom properties. Every colour reads from the properties, so one :checked flips the whole palette. Zero JavaScript. The subtle bug every implementation hits: on a visitor whose OS preference matches your default (light-OS visitor on a light-default site), the toggle appears to do nothing on the first click because both the OS-driven rule (.hd-NN:not([data-theme='dark']):not(:has(:checked)) inside @media (prefers-color-scheme: light)) and the :has(:checked) rule land on the same light values. Only the second click flips anything. Fix by adding a nested flip-back rule inside the @media (prefers-color-scheme: light) block: .hd-NN:has(:checked){ …dark-base values… } that restores the opposite base when the checkbox is checked on a light-OS visitor. Restore EVERY custom property from the dark base, not just --bg. Demos 08, 10, and 11 ship this pattern verbatim — the nested-media flip-back rule is the single most-missed accessibility fix in dark-mode toggles across the ecosystem.

Six requirements from AA that every header in this collection meets. First, SC 2.4.1 (Bypass Blocks) — a visually-hidden skip-to-content link at the top of every header that becomes visible on :focus-visible. Second, SC 2.4.13 (Focus Appearance, added in WCAG 2.2) — every focus indicator is at least 2 CSS pixels thick and reaches 3:1 contrast against adjacent colours. Dark-mode headers use a distinct --focus-ring token calibrated for the dark surface (bright cyan tends to work — oklch(83% 0.13 200)), not the primary accent. Third, SC 2.5.8 (Target Size Minimum, WCAG 2.2) — every icon-only button hits at least 24×24 CSS pixels; interactive controls in dense headers hit 44×44 (Level AAA). Fourth, SC 4.1.2 (Name, Role, Value) — every <nav> carries aria-label naming its role (Main, Breadcrumb, Utility, Footer), every icon-only button carries aria-label, every dropdown trigger carries aria-haspopup='menu' and aria-expanded. Fifth, SC 1.4.11 (Non-text Contrast) — 3:1 for the borders around search pills, badges, and any UI component that carries meaning. Sixth, SC 2.4.7 (Focus Visible) — never outline: none without an equivalent replacement (a box-shadow ring or outline that meets 2.4.13). Compliance matters especially for HIPAA, education, government, and enterprise SaaS traffic — those verticals audit their vendors on accessibility before purchase.

Nine adjacent collections on codefronts cover different scopes. css-navbars (8 demos) ships bare navigation bars — logo + links only. css-header-designs (this collection, 22 demos) ships full-page-header compositions — logo + primary nav + utility cluster + search + CTA + theme all together as one region. css-sticky-navigation (25 demos) owns the pure-CSS position: sticky mechanism — every demo here uses position: sticky because a header requires it, but the design lane is composition, not sticky behavior. css-responsive-navbar (20 demos) owns breakpoint-collapse patterns. css-hamburger-menus (28 demos) owns the hamburger widget itself. css-mobile-navigation (16 demos) owns mobile-first patterns (bottom tab, drawer, radial). css-mega-menus (6 demos) owns standalone mega panels. css-sidebar-navigation (10 demos) owns vertical navigation. css-glassmorphic-navbars (11) and css-liquid-glass-navbars (24) own glass NAVBARS specifically. Every demo in this collection is the composed header region — the topmost site strip where a real product ships its logo, nav, search, cart, workspace switcher, and utility icons together. If you need a bare navbar, use css-navbars; if you need the full header, this collection is the one.

Every demo is framework-agnostic vanilla HTML + CSS + optional under-15-line JS, scoped under a unique .hd-NN root that drops into any framework without leaking. Tailwind v3 users translate the CSS to @apply inside @layer components; Tailwind v4 uses the CSS-first config so --font-display, --surface, --ink tokens can be declared in @theme and consumed by both the utility variants and the demo's own rules. React and Next.js apps wrap the demo as a <Header /> component; the theme-toggle demos work with any theme-provider that writes data-theme on document.documentElement (the demo CSS reads the attribute regardless of who sets it). Vue 3 users bind :data-theme="theme" on the layout root and useDark() from VueUse writes it. Svelte does it with bind:data-theme. Astro islands (client:visible) work with the pure-CSS demos as-is; hydrate a small island around demo 01 for the ⌘K keyboard listener. SolidJS, Qwik, and Angular signals all map to the same [data-theme] attribute pattern. The scroll-timeline demos (01, 05, 06, 08, 12, 22) use animation-timeline: scroll(root) which needs no framework code at all — the animation lives entirely in CSS and works identically across every stack.