CSS Scroll Snap and Scroll Behavior

Intermediate

Scroll Snap lets CSS define preferred snap positions for scrolling, while scroll-behavior controls how certain programmatic or non-user scrolling operations are performed. The two features change scrolling behavior, not the underlying rules that create a scroll container.

This lesson is the primary Foxipa owner for CSS scroll snapping and declarative scrolling behavior: snapports, snap areas, snap positions, scroll-snap-type, scroll-snap-align, scroll-snap-stop, scroll-padding, scroll-margin, snapping selection and settling, and scroll-behavior.

The central model

A scroll container provides a scrolling coordinate space. Scroll Snap adds preferred destinations within that space. The browser still has to perform scrolling; snapping influences the final position when snapping is active.

?

Snap positions are preferences, not extra layout boxes

A snap position is a position to which a scroll container can be snapped. The snap position is derived from a snap area and the scrollport/snapport geometry; it is not a new box inserted into layout.

?

The scrollport and the snapport

The scrollport is the visible scrolling area. Scroll padding can effectively expand the region used to determine snap positions, creating a snapport that is inset from the scrollport edges.

?

scroll-snap-type: axis and strictness

The first part of scroll-snap-type selects the snapping axis: x, y, block, inline, or both. Its strictness selects whether the container must snap when relevant scrolling settles or may snap when appropriate.

.scroller{height:9rem;overflow:auto;scroll-snap-type:y mandatory;scroll-timeline-name:--page;border:1px solid}.item{height:8rem;scroll-snap-align:start;border-bottom:1px solid;display:grid;place-items:center;animation:fade linear ?;animation-timeline:--page}@keyframes fade{from{opacity:.4}to{opacity:1}}

Choosing an axis without duplicating writing-mode rules

Physical x/y axes are explicit. Block and inline axes connect snapping to the element’s writing mode. Writing Modes remains the owner of what block and inline mean.

?

scroll-snap-align: where an element wants to land

scroll-snap-align specifies the preferred alignment of a snap area in the snapport. The values start, end, and center describe alignment along each axis; two-value syntax can specify block and inline alignments separately.

?

Snap areas and transformed geometry

A snap area is associated with an element’s border box and its scroll-margin. Transforms remain a separate geometry system; do not use Scroll Snap as the owner of transformed layout geometry.

?

scroll-margin versus scroll-padding

Use scroll-padding on the scroll container when the snapport needs an inset. Use scroll-margin on the snap target when that target needs an outset. They solve different sides of the geometry relationship.

?

scroll-snap-stop

scroll-snap-stop controls whether a snap area is allowed to be skipped during a scrolling operation. Normal behavior permits skipping when the scrolling operation would otherwise pass over multiple snap areas; always requests that the snap area not be skipped.

?

Snapping selection and settling

The browser considers reachable snap positions and the intended scrolling operation before settling. The exact final choice can depend on the scrolling method, direction, velocity, current position, and available snap positions; authors should not assume a universal “nearest card” algorithm.

?

Nested scroll containers

Nested scrolling creates more than one scroll container, and each container has its own scrollport and possible snapping model. Keep the ownership local: configure the intended scroll container and its snap areas instead of treating the entire document as one snapping surface.

?

When snapping is not the right tool

Scroll Snap is useful when scrolling has meaningful discrete destinations: carousels, paged panels, or structured reading positions. It should not be used merely to hide overflow or to force a layout into fixed pages.

?

scroll-behavior is a different control

CSS Overflow defines scroll-behavior as auto or smooth for scroll containers. It affects scrolling caused by navigation, scrolling APIs, or non-user scroll snapping operations. User-driven scrolling is not controlled by this property, and user agents may ignore it.

?

scroll-behavior does not mean “smooth everything”

The property is not a universal scroll-speed switch. Its defined effect is limited to particular scrolling operations, and its timing function and duration are user-agent defined. Authors should therefore avoid promising an exact duration.

?

Root scrolling and the body boundary

When scroll-behavior is specified on the root element, it applies to the viewport. The specification notes that the body element’s scroll-behavior is not propagated to the viewport, so do not treat body as a portable alias for the root.

?

scroll-margin and anchor navigation

Scroll margins can also provide space when an element is brought into view by scrolling operations. This makes them useful for targets that would otherwise end up underneath persistent UI; the actual scrolling API remains Web Platform material.

?

Scroll padding and fixed interfaces

If a scroll container has a persistent interface that visually occupies space near an edge, scroll-padding can express an inset for scrolling and snapping calculations. It is a CSS positioning aid for scrolling, not a replacement for layout or accessibility semantics.

.scroller{height:11rem;overflow:auto;scroll-snap-type:y mandatory;?-block-start:2.5rem;border:1px solid}.bar{position:sticky;top:0;height:2rem;background:Canvas;z-index:1}.items section{height:9rem;scroll-snap-align:start;border-bottom:1px solid;display:grid;place-items:center}

Scroll Snap and Scroll-driven Animations

A scroll container can both snap and expose scroll progress to a scroll-driven animation. These are different mechanisms: snapping chooses settling positions, while a scroll timeline maps scroll offset to animation progress.

?

Scroll Snap is not CSS animation

A snap operation may involve motion while the browser settles scrolling, but that does not make it a CSS animation or a transition. CSS Animations and Transitions retain their own timing models and lifecycle rules.

?

Imperative scrolling remains outside this CSS owner

CSSOM View defines APIs such as scrollTo(), scrollBy(), and scrollIntoView(). This lesson may show them as integration boundaries, but their API contracts and JavaScript behavior belong to the Web Platform curriculum rather than this CSS lesson.

?

Snap-stop is not a velocity control

scroll-snap-stop does not specify a speed, duration, or easing curve. It changes whether a snap area may be skipped. Do not use it as a substitute for scroll-behavior or animation timing.

?

Mandatory is not “one scroll equals one item”

Mandatory snapping requires settling on a valid snap position when snapping applies, but it does not establish a generic one-item-per-input contract. The available snap positions and scrolling operation still matter.

?

Two-dimensional snapping

With both axes active, a scroll container can have snap positions in two dimensions. The snap areas and their alignments can therefore constrain both block/inline or x/y movement.

?

Logical versus physical snap alignment

scroll-snap-align can be expressed using start, end, and center without hard-coding a physical side. The interpretation of logical axes follows the relevant writing-mode context.

?

Interaction with overflow

Overflow remains the prerequisite owner for determining whether content produces scrollable overflow and whether an element is a scroll container. Scroll Snap does not create overflow just because snap properties are present.

?

Debugging: first find the scroll container

When snapping appears broken, first identify which element actually scrolls. Then inspect its overflow, axis, snap type, snap padding, and the snap areas’ alignments and margins. A snap declaration on a non-scrolling ancestor may simply not affect the scrolling element you are observing.

?

Debugging: inspect geometry

If the correct scroll container is snapping but the landing position looks wrong, inspect scroll-padding and scroll-margin before changing layout rules. These properties intentionally change the geometry used for scroll positioning.

?

Debugging: distinguish smoothness from snapping

A scroll that moves smoothly is not necessarily snapping, and a snapping operation does not require scroll-behavior: smooth. Test the final settled position separately from how the movement looks.

?

Reduced motion is a preference boundary

Reduced-motion semantics belong to the Media Features / User Preferences / Color Adjustment owner. This lesson can demonstrate an adaptation, but it should not redefine the meaning of prefers-reduced-motion or make a blanket accessibility rule beyond the relevant specifications.

?

Developing Scroll Snap Level 2

Scroll Snap Level 2 is a First Public Working Draft. It extends the Level 1 model with developing additions including an initial scroll target property and snap-related events. These features should be taught as work in progress, not as stable fundamentals.

?

Do not turn Level 2 into a second scrolling curriculum

Level 2 also describes snap-related events and pseudo-class ideas. Because that surface is still developing, Foxipa records it as a boundary rather than building a separate event lesson here. Future Web Platform event/API curriculum can own script-facing details if and when appropriate.

?

Scroll Snap and carousel semantics

A snapping carousel still needs appropriate HTML structure, focus behavior, controls, and accessible names. Scroll Snap changes scrolling behavior; it does not supply interaction semantics or keyboard controls.

?

A compact decision tree

Ask four questions: does an element actually scroll; should it have intentional landing positions; does the target need an inset/outset; and is the concern motion style rather than landing position? These questions usually lead to Overflow, Scroll Snap, scroll-padding/margin, or scroll-behavior respectively.

.rail{display:flex;gap:1rem;overflow-x:auto;scroll-snap-type:x mandatory;scroll-padding-inline:1rem;width:20rem;border:1px solid;padding:1rem;scroll-behavior:smooth}.rail article{flex:0 0 15rem;height:7rem;scroll-snap-align:start;?:normal;scroll-margin-inline:.5rem;border:1px solid;display:grid;place-items:center}

Ownership boundaries at a glance

Overflow owns the existence and geometry of scrolling. Scroll Snap owns snap destinations and snapping behavior. Overflow also owns scroll-behavior as a CSS property. Scroll-driven Animations maps scrolling progress to animation progress. Animations owns keyframes and ordinary animation controls. CSSOM View owns imperative scrolling APIs.

Practice: build a predictable snap rail

?

Final mental model

Think of Scroll Snap as a constraint on where scrolling settles, not as a layout system, animation engine, or input handler. Think of scroll-behavior as a request about the motion of certain non-user scrolling operations. Keep those models separate and the feature becomes predictable.

?

What this lesson deliberately does not teach

This owner does not re-teach overflow clipping, scroll-container creation, writing-mode semantics, keyframe authoring, easing functions, transform geometry, user-preference semantics, or JavaScript scrolling API contracts. Those concepts remain in their existing owners.

?