22 Tailwind CSS Headers

Two demos cover this. The sticky base is one utility — sticky top-0 z-50 on the header, which keeps it in normal flow until it reaches the top of the viewport, then pins it with no scroll listener and no fixed positioning that needs a spacer element. The shrinking header (demo 22) goes further with a scroll-driven animation: an @keyframes that interpolates the header height from 5rem to 3.5rem, driven by animation-timeline: scroll() so the browser ties progress to scroll position on the compositor thread instead of a JS handler. The scroll-driven sticky header (demo 12) uses the same timeline to fade a background and blur in once you leave the top. The most common trap is forgetting z-50: the header stays sticky but a later section with its own stacking context slides over it. Give the header a z-index above every page section.

Demo 15 does it with the checkbox hack. A visually hidden <input type="checkbox"> sits before the overlay, and the hamburger is a <label> whose for points at that checkbox, so tapping the label toggles :checked. The overlay is a following sibling styled with peer-checked: variants — hidden and opacity-0 at rest, full-screen and visible when checked. Because it is a real form control, Space and Enter toggle it and it is reachable by Tab out of the box. The accessibility gap to close yourself: the label needs an aria-label such as "Open menu", and ideally the state should surface as aria-expanded, which pure CSS cannot update — if that matters, add a few lines of script. There is also no focus management, so when the overlay closes focus stays where it was; on a large menu that is worth a small script to return focus to the trigger.

This is the number-one bug with the transparent-over-hero pattern in demo 8. The header floats with no background, so the link colour is fixed at author time — usually white — but a hero image is not uniformly dark. Over a bright sky or a pale product shot the white nav simply disappears. The demo leans on two fixes. Add a subtle top-down scrim behind the header, a bg-gradient-to-b from-black/40 to-transparent layer, so text always has something dark under it regardless of the photo. And keep the logo and links at a weight that survives a busy background. Do not rely on mix-blend-mode alone — it inverts unpredictably over mid-tones. If your hero can be any image a CMS supplies, the scrim is not optional. Test the focus ring too: a white focus-visible outline vanishes over light areas exactly like the text does, so give it a contrasting colour.

Demo 14 is built for exactly this, and for the bug it usually hides. The naive approach — justify-between on a flex row of three items — only centres the middle group when the logo and the button happen to be the same width. The moment they differ, the centre drifts off. The fix is a three-column layout where the outer two columns are equal and flexible: give the logo wrapper and the actions wrapper flex-1, put justify-start on the first and justify-end on the last, and let the nav sit in the middle at its natural width. The two flex-1 columns now absorb all leftover space symmetrically, so the nav is truly centred on the bar rather than on the remaining gap. On narrow widths you collapse the centre nav and fold to a two-item row. Avoid absolute-position centring for the nav — it overlaps the logo once the viewport shrinks.

Demos 13 and 21 open their panels on hover and on focus-within, and that pairing is the whole accessibility story. Hover alone strands keyboard and touch users: the panel opens under the pointer but never for Tab. Adding :focus-within — in Tailwind, focus-within:opacity-100 focus-within:visible on the menu wrapper — means the panel also opens the instant focus lands on the trigger or any link inside it, so a keyboard user tabs straight through. Keep the trigger a real <button> or link so it is focusable at all. The multi-level demo (21) nests the same rule at each depth, flying each submenu out beside its parent. A subtle bug: a hover-intent delay set with transition-delay on the opening direction can swallow focus opening — apply the delay only to closing. On touch, hover-open causes a double-tap, so if that audience matters, gate the panel behind an explicit click toggle instead.

Demo 16 is a full glass header — backdrop-blur-xl backdrop-saturate-180 over a drifting gradient. If your blur does nothing, the usual cause is an opaque background: backdrop-filter blurs whatever sits behind the element, so the element's own background must be semi-transparent. A solid bg-white paints over everything the blur would reveal — use bg-white/70 or a low-alpha tint so content behind the header shows through and blurs. The second cause is that nothing is actually passing under the header: the effect only appears when the header is sticky or fixed and content scrolls beneath it. Support is broad, but older Firefox gated it behind a flag, so ship a readable bg-white/80 fallback that looks fine with no blur at all. Heavy blur over large areas is also GPU-expensive; keep the blurred surface to the header strip rather than the whole page.

Demo 17 collapses a promo bar to nothing with no script and deliberately without display:none. The trick is a grid-rows transition: the bar's wrapper is grid with grid-rows-[1fr] when open and grid-rows-[0fr] when dismissed, while the inner content carries overflow-hidden min-h-0. Animating that fraction unit smoothly collapses the height to zero — something display:none can never do because it is not an interpolatable value, it just snaps. State is held by the checkbox hack: a hidden checkbox and a close <label>, wired with peer-checked:grid-rows-[0fr]. The real catch is persistence — pure CSS forgets the dismissal on reload, so the bar reappears every visit. If it must stay closed, record the choice in localStorage with a little script. Give the close control an aria-label too; an icon-only <label> announces nothing to a screen reader otherwise.

Several of these patterns are wrong for some sites. A sticky or shrinking header (demos 12 and 22) eats vertical space on short viewports — a phone in landscape can lose a quarter of its screen to a pinned bar, so consider hiding on scroll-down and revealing on scroll-up rather than always pinning. The transparent-over-hero header (8) only works when there is a hero to sit over; on an interior page with a white top it becomes invisible, so it must switch to a solid scrolled state. The reading-progress bar (6) belongs on long articles, not on a dashboard or checkout where there is no linear progress to report — there it is just noise. The full-screen overlay (15) is heavy for a three-link marketing site, where a plain dropdown feels calmer. And animation-timeline: scroll() is unsupported in older browsers, so any scroll-driven effect must degrade to a plain static header — never to a broken one.