12 CSS Full Page Sections

Three declarations carry the whole pattern. The scroll container gets scroll-snap-type: y mandatory, each panel gets scroll-snap-align: start, and each panel is min-height: 100dvh so it fills the viewport. That is the entire mechanism — no library, no JavaScript, no scroll hijacking. The detail that trips people up is which element is the scroll container. If the page itself scrolls, put the snap properties on html; if a wrapper scrolls, that wrapper needs overflow-y: auto and a bounded height, or it never becomes a container at all and the snap properties do nothing. Every demo here uses an inner scroller with overflow-y: auto; height: 100dvh, which is also what makes them work inside an embedded preview. Use min-height rather than height on panels so content taller than the viewport can still grow instead of being clipped.

Because 100vh on iOS means the viewport with the address bar hidden, not the viewport you are actually looking at. On load the bar is visible, so a 100vh panel is taller than the visible area and its bottom is cut off; as you scroll the bar collapses, the viewport grows, and everything jumps. The fix is 100dvh — the dynamic viewport height, which tracks the visible area as browser chrome appears and disappears. There are three related units worth knowing: svh is the smallest viewport (chrome visible), lvh is the largest (chrome hidden), and dvh moves between them. For snapping panels dvh is almost always what you want, since the panel should match whatever the user can see right now. A common belt-and-braces pattern is min-height: 100vh; min-height: 100dvh; so older browsers get the legacy value and modern ones override it.

Add scroll-snap-stop: always to each panel. By default a fast flick or a hard trackpad swipe can carry the scroll past several snap points before it settles, so a user aiming for section two lands on section four and misses your content entirely. scroll-snap-stop: always forces the scroll to come to rest on every snap point it passes, one panel per gesture, which is what people expect from a full-page scroller. It goes on the children, not the container — putting it on the scroller does nothing. Support is good across evergreen browsers and it degrades harmlessly: where it is unsupported you simply get the default skipping behaviour, so no fallback is needed. Use it deliberately, though. On a long list it makes scrolling feel laborious, since the user must gesture once per item. It suits a handful of full-page panels, not a fifty-item feed.

mandatory always snaps to the nearest point, so the scroll can never rest between panels. proximity only snaps when the scroll ends near a point, leaving the user free to stop anywhere. For a clean full-page scroller mandatory is the right default: it is the whole reason the layout feels deliberate. There are two cases where it actively hurts. First, when a panel is taller than the viewport — mandatory snapping can fight the user trying to read the overflow, and in the worst case makes content unreachable. Second, sticky stacking effects, where mandatory snapping competes with the pinning and produces a visible stutter. Both demos here that use sticky stacking or prioritise keyboard access deliberately use proximity. The rule of thumb: if every panel fits the viewport exactly, use mandatory; if any panel might overflow, use proximity and let the user drive.

It can be, but it is one of the easier patterns to get wrong. The main hazard is keyboard users: if focus moves to an element inside a panel while mandatory snapping is active, the browser can fight the focus scroll and effectively trap someone mid-panel. Keep every panel a real section with its own heading and make sure Tab order follows visual order, so keyboard navigation moves through panels naturally. Arrow keys, Page Up and Page Down should all work — they do by default on a native scroll container, and they break the moment you hijack scrolling with JavaScript, which is a good reason not to. The second requirement is motion. Snapping plus scroll-behavior: smooth is exactly the sort of movement that triggers vestibular symptoms, so both should be switched off entirely inside @media (prefers-reduced-motion: reduce). Every demo here does that, and the result is an ordinary scrolling page rather than a degraded one.

fullpage.js predates native scroll snapping and solved the problem with JavaScript, listening for wheel and touch events and animating the scroll position itself. That works, but it hijacks scrolling: momentum feels wrong, keyboard and screen-reader behaviour has to be re-implemented, and you carry roughly 20KB before writing any of your own code. Native scroll-snap-type does the same job in three declarations with no script, and because the browser is still doing the scrolling, momentum, keyboard keys, find-in-page and accessibility all keep working for free. What you give up is the programmatic API — there is no moveTo(3) method, no per-section callbacks, no built-in continuous-loop mode. If you need to drive the scroller from application code, one line of element.scrollIntoView() covers most of it. For the common marketing or portfolio case, the native approach is smaller, faster and more robust.

Almost always one of four things. First, the snap container is not actually a scroll container — scroll-snap-type only takes effect on an element that scrolls, which means it needs overflow: auto or scroll plus a constrained height. A div that grows with its content never scrolls and never snaps. Second, the alignment is on the wrong element: scroll-snap-align belongs on the children, not the container. Third, the children are not direct children — snap alignment only applies to the container's own children, so an extra wrapper in between silently breaks it. Fourth, an ancestor has overflow: hidden, which can make the intended container inert. One more that catches people out: if you set snapping on html but a wrapper element is actually doing the scrolling, the properties apply to something that never moves. Check in DevTools which element has a scrollbar before debugging anything else.

The CSS ports unchanged — every .fps-NN selector and custom property is framework-agnostic, and 10 of the 12 designs need no JavaScript at all. The natural component boundary is a Scroller wrapper that owns overflow-y, height and scroll-snap-type, plus a Panel child that owns min-height: 100dvh and scroll-snap-align. Consumers then compose panels freely without touching the mechanism. Watch one framework-specific trap: in single-page apps a route change often needs the scroller reset to the top, and because the scroll container is your wrapper rather than the window, window.scrollTo(0, 0) does nothing — you need a ref to the scroller element. For Tailwind the properties map directly to snap-y, snap-mandatory, snap-start and h-dvh, all first-class utilities, so this pattern is one of the cleanest to express in utility classes.