Scroll Snap Generator

Features

• Four axes: horizontal, vertical, both, and the block axis
• Three alignments: start, centre, end
• ⚠️ The `proximity` versus `mandatory` difference is spelled out, including what `mandatory` does to long content
• ⚠️ States that both properties are needed: `scroll-snap-type` on the container, `scroll-snap-align` on the items, and half of it raises no error
• The live preview can be dragged directly
• A vertical container gets a height automatically (without one it cannot scroll)
• Copies the container and item blocks separately, ready to rename

How to use

1. Pick the axis and the alignment
2. Drag the block below to see it snap
3. Copy the code and apply the two blocks to your own structure

FAQ

Why does scroll-snap-type do nothing?

Most likely the other half is missing. Scroll snapping needs the container and the items together: `scroll-snap-type` on the scrolling container and `scroll-snap-align` on each item that should snap. With only the container half, scrolling works perfectly — it is simply ordinary scrolling. That is what makes it hard to trace: no error, both properties correctly written in isolation, and the symptom is that nothing happens. The other common cause is that the container has nothing to scroll — the content is shorter than the container, or the container has no size — in which case there is nothing to snap.

Should I use mandatory or proximity?

Default to `proximity`. `mandatory` promises “it always stops on a snap point”, which sounds better, but when the content is longer than the container the browser forces a snap back — so scrolling into the middle and letting go bounces you out, and the middle content is unreachable. Nothing on screen tells the user there is more. Keyboard users also jump item by item. `mandatory` is safe and better only when every screenful is exactly one snap item — the classic carousel where each card fills the view.

Why does vertical snapping need an explicit height?

Because a block with no height constraint will not scroll — its height is set by its content, so it always equals the content height and there is no overflow to scroll. Horizontal is the same in principle (with no width it keeps growing rightwards). So vertical snapping nearly always needs a `height` (or `max-height`), and that is why it is easier to get wrong than horizontal: a horizontal scroll container is naturally width-constrained by normal document flow, a vertical one is not.

Does scroll snapping affect keyboard users and screen readers?

It does, and `mandatory` more so. When a keyboard user presses `PageDown` or an arrow key, forced snapping makes them skip past snap point after snap point, unable to read the content in between. Screen readers read content in DOM order and are unaffected by snapping (which is visual), but a mismatch between the visual and spoken order is confusing in itself. The spec offers `scroll-snap-stop: always` (every snap point must be stopped at) as a partial remedy, but the sounder approach for long content is `proximity`. CSS cannot make that judgement for you.

Should a carousel use scroll snapping or JavaScript?

Prefer scroll snapping. It gives you several things JavaScript versions often get wrong, for free: native momentum on trackpads and touch screens, arrow-key scrolling, a scrollbar, and “the back button returns to the previous scroll position”. And with no script, it cannot fail because a script failed to load. JavaScript is worth adding only for something extra: autoplay, infinite looping, syncing an indicator dot to the current page, or acting when a snap finishes. Even then, start from scroll snapping and read its state from script rather than reimplementing scrolling.