12 Tailwind CSS Full Page Sections

The whole pattern is four utilities on two elements, shown in demos 01 and 02. The scroll container gets h-dvh overflow-y-auto snap-y snap-mandatory — it owns the scrolling, is exactly one viewport tall, and declares a mandatory vertical snap axis. Each direct child panel then gets h-dvh snap-start so its top edge is the snap position. That is it; there is no scroll listener, no IntersectionObserver, no library. The browser's native scroll-snap engine does the paging. One thing people miss: the snap container must be the element that actually scrolls, not the <body>, or the snap-* utilities apply to a box that never overflows and nothing snaps. If you want the page itself to snap instead of an inner container, move h-dvh snap-y snap-mandatory onto the <html> element and let the body panels be the snap children.

By default snap is forgiving: a fast flick carries momentum through several snap points and only settles on whichever one it lands near, so a quick swipe on mobile can jump from panel one to panel three. Demo 03 puts two identical scrollers side by side to show the fix. The left one uses plain snap-start and flies past panels; the right one adds snap-always to each panel, which maps to scroll-snap-stop: always. That tells the engine it must stop at every snap point before the next one, converting the flick into a one-panel-at-a-time pager. Use it when each section is a discrete unit a reader should not miss — onboarding steps, a pitch deck, portfolio projects. Skip it on long editorial content, because forcing a stop at every panel makes a reader who just wants to scroll feel like the page is fighting them. It is a per-child utility, so you can apply it selectively.

Use dvh. The collection is built on h-dvh throughout for one reason: on mobile, 100vh resolves to the largest viewport, the height with the browser toolbar retracted. When the address bar is showing — which is most of the time on first load — a 100vh panel is taller than the visible area, so its bottom edge and your snap point sit under the toolbar and the next panel peeks in at the bottom. dvh (dynamic viewport height) tracks the viewport as the toolbar shows and hides, so h-dvh is always exactly the space you can see. Pair it with min-h-dvh rather than a fixed h-dvh on any panel whose content can grow past one screen, otherwise that content is clipped. The trade-off is that the panel height animating as the toolbar slides can cause a small reflow; it is almost always less jarring than the toolbar-sized gap vh leaves behind.

Demos 05 and 06 do it with CSS scroll-driven animations instead of a scroll listener. Each full-viewport section carries an animation-timeline: view() animation, so its progress through the viewport is the animation timeline — no scroll event, no IntersectionObserver. The matching dot or nav link runs a keyframe that flips its active styling (background, scale, the frosted fill on the dot rail) exactly while its section fills the screen. Demo 05's rail is built from real anchor links — each dot is an <a> pointing at its section id, sized to a 44px hit target so it is tappable and focusable, not a decorative div. The usual bug is forgetting scroll-behavior: smooth on the snap container, so clicking a dot teleports instead of gliding. Browsers without scroll-driven-animation support simply show the default (inactive) dot styling, which is a clean fallback rather than a broken rail.

Demo 07 layers three scroll-driven animations on one panel: the photograph, a colour wash and the headline each run their own keyframe tied to animation-timeline: view(), but with different translate distances, so they travel at different rates as the panel crosses the viewport — that rate difference is the parallax. Demo 08 uses the same timeline to animate a sheet from scale(0.92) and 30% opacity up to full size and full opacity, timed with animation-range so it lands exactly as the panel snaps home and then holds. Because it is a real CSS animation driven by scroll position rather than time, it reverses perfectly when you scroll back up. Wrap every one of these in motion-reduce:animation-none (or a prefers-reduced-motion block): vestibular users get the layout with no travel, and browsers that do not support scroll timelines render the final resting state, so nothing is stuck mid-reveal.

They can be hostile if you use the naive setup, which is exactly what demo 12 addresses. snap-mandatory plus scroll-snap-stop: always can trap a keyboard user: pressing Tab moves focus to a control inside the next panel, the browser scroll-snaps toward it, and mandatory snapping yanks it back, so focus and viewport fight. The shippable panel switches to snap-proximity, which snaps when you are close but never overrides an intentional focus jump, and adds arrow-key handlers plus visible focus rings. Other rules the collection follows: every nav dot is a focusable <a> with a 44px target and an aria-label; decorative parallax images are marked aria-hidden; and all motion is gated behind prefers-reduced-motion. Also give each panel a heading and a landmark so a screen-reader user can navigate by structure instead of being forced through twelve full screens linearly.

Demo 11 swaps the axis. The container becomes a horizontal flex row with flex overflow-x-auto snap-x snap-mandatory, and each chapter is w-screen shrink-0 snap-start — shrink-0 is the load-bearing utility, because without it flex squeezes every panel into the visible width and there is nothing to scroll sideways through. The container still needs a defined height (h-dvh) since the children are full-screen. Two things to plan for: trackpad and wheel users scroll vertically by habit, so a sideways-only region can feel stuck — the demo flips to a vertical stack at narrow breakpoints rather than forcing horizontal on a phone. And horizontal snap containers are a known focus-order trap, so keep DOM order equal to visual order and make sure Tab moves left-to-right through the panels the same way the eye does.

Reach for it when each screen is a self-contained unit — a product tour, a portfolio where one project deserves one screen (demo 10), a SaaS feature walkthrough (demo 09). Avoid it for content-dense or long-form pages. If a section holds more than one viewport of text, snap-mandatory forces a snap point in the middle of the reading, so the user cannot rest the paragraph they are reading at a comfortable position — the page keeps tugging to the panel edge. It also hijacks the scroll rhythm users expect from a normal document, which is fine for a deliberate presentation and frustrating for reference material. Three practical escape hatches: use snap-proximity instead of snap-mandatory so snapping is a hint not a rule; use min-h-dvh so a tall panel can grow past one screen; and never hide real content behind the effect, since a panel the user has to fight to scroll into is a panel they will not read.