CSS Scroll Snap Points 1 Module Level 1

A box captures snap positions if it is a scroll container or has a value other than none for scroll-snap-type. If a box’s nearest snap-position capturing ancestor on its containing block chain is a scroll container with a non-none value for scroll-snap-type, that is the box’s scroll snap container. Otherwise, the box has no scroll snap container, and its snap positions do not trigger snapping. 6

Authors should use mandatory snap positions with consideration of varyingly-sized screens and (if applicable) varying-sized content. In particular, although access to snapped elements larger than the viewport is handled by the UA, if authors assign mandatory snapping to non-adjacent siblings, content in between can become inaccessible in cases where it is longer than the screen. 7

The axis values specify what axis(es) are affected by snap positions, and whether snap positions are evaluated independently per axis, or together as a 2D point. Values are defined as follows:

x

The scroll container axis-snaps to snap positions in its horizontal axis only.

y

The scroll container axis-snaps to snap positions in its vertical axis only.

block

The scroll container axis-snaps to snap positions in its block axis only.

inline

The scroll container axis-snaps to snap positions in its inline axis only.

both

The scroll container axis-snaps to snap positions in both of its axises independently (potentially snapping to different elements in each axis).

point

The scroll container point-snaps to snap positions in both axises simultaneously, treating each element’s snap position as a single 2D position (rather than potentially snapping to different elements in each axis).

If no axis value is specified, then the axis is automatically computed:

• If the scroll container is only scrollable in one axis (only one axis has its overflow set to auto or scroll) it axis-snaps in the scrollable axis only.

• Otherwise, it axis-snaps in its block axis only.

5

If the element’s scroll container is point-snapping, and this property does not specify a valid snap position in both axises (that is, it contains none), the element does not contribute any snap positions at all.

For all of these values, the block or inline axis is relative to the element’s parent’s writing mode. 14

Is this the correct writing mode to compute against? Or should it be the scroll container’s writing mode?

6.2.1. Scoping Valid Snap Positions to Visible Boxes I-62

Since the purpose of scroll snapping is to align content within the viewport for optimal viewing: in all cases, the specified alignment creates a valid snap position only if at least part of the snap area is within the snapport. For example, a snap area is top-aligned to the snapport if its top edge is coincident with the snapport’s top edge; however, this alignment is nonetheless not a valid snap position if the entire snap area is outside the snapport.

6.2.2. Snapping Boxes that Overflow the Scrollport I-3

If the snap area is larger than the snapport in a particular axis, and there are no other snap areas within the snapport that would provide a >snap position aligning the overflowing snap area within the snapport, then any scroll position in which the snap area covers the snapport is a valid snap position in that axis. The UA may use the specified alignment as a more precise target for certain scroll operations (e.g. inertial scrolling or explicit paging).

6.2.3. Unreachable Snap Areas I-70

If a snap position is unreachable as specified, such that aligning to it would require scrolling the scroll container’s viewport past the edge of its scrollable area, the used snap position for this snap area is the position resulting from scrolling as much as possible in each relevant axis toward the desired snap position.

6.3. Scroll Snap Limits: the scroll-snap-stop property I-64

This property specifies whether the snap position absorbs all remaining inertia during an inertial scroll, or allows the inertial scroll to pass multiple snap positions before coming to rest. Values are defined as follows:

normal

A snap position defined by this element does not interfere with the inertia of an inertial scroll that is passing across it, unless it is the landing snap position.

always

A snap position defined by this element, when encountered by an inertial scroll, absorbs all remaining inertia from an inertial scroll, forcing a stop at this snap position, exactly as if the scroll had enough inertia to reach the snap position, but not enough to escape it.

Note: This means that if all snap positions in a scroller have scroll-snap-stop: always, an inertial scroll can only move one snap position per inertial scroll action.

7. Snapping Mechanics I-68

The precise model algorithm to select a snap position to snap to is intentionally left mostly undefined, so that user agents can take into account sophisticated models of user intention and interaction and adjust how they respond over time, to best serve the user.

This section defines some useful concepts to aid in discussing scroll-snapping mechanics, and provides some guidelines for what an effective scroll-snapping strategy might look like. User agents are encouraged to adapt this guidance and apply their own best judgement when defining their own snapping behavior. It also provides a small number of behavior requirements, to ensure a minimum reasonable behavior that authors can depend on when designing their interfaces with scroll-snapping in mind.

7.1. Types of Scrolling Methods

When a page is scrolled, the action is performed with an intended end position and/or an intended direction. Each combination of these two things defines a distinct category of scrolling, which can be treated slightly differently:

explicit scrolling

A scroll is explicit if it has an intended end position, but no intended direction.

This includes methods such as:

• a panning gesture, released without momentum

• manipulating the scrollbar "thumb" explicitly

• programmatically scrolling via APIs such as scrollTo()

• tabbing through the document’s focusable elements

• navigating to an anchor within the page

inertial scrolling

A scroll is inertial if it has both an intended end position and an intended direction.

This includes methods such as:

• a "fling" gesture, released with momentum (the "intended" end position might be implicitly determined by the UA’s scrolling physics, but the strength of the user’s fling still expresses a weak intention about where the scroll should end up)

• a mousewheel scroll

• programmatically scrolling via APIs such as scrollBy()

The scroll position that an inertial scroll would naturally land on without further intervention is the natural end-point.

directional scrolling

A scroll is directional if it has an intended direction, but no intended end point.

This includes methods such as:

• pressing an arrow key on the keyboard

Additionally, because page layouts usually align things vertically and/or horizontally, UAs sometimes axis-lock a scroll when its direction is sufficiently vertical or horizontal. An axis-locked scroll is bound to only scroll along that axis. This prevents, for example, a nearly horizontal fling gesture from gradually drifting up or down as well, because it is very difficult to fling in a precisely horizontal line.

7.2. Axis vs Point-Snapping I-67

This feature is planned to be removed in the next publication in order to reduce the feature-set of Level 1. It is included here for future reference in defining Level 2.

There are two distinct snapping behaviors that a scroll container might engage in:

axis-snapping

If a scroll container is axis-snapping, its descendants indicate a desired scroll position in each axis of the scroll container independently, with no dependent preference for what the other axis’s scroll position should be.

Note: This is the “default” type of snap behavior that most scroll containers will want to use, and so the scroll-snap-type property intentionally defaults to it.

Note: An element in an axis-snapping scroll container can declare two snap positions, one in each axis. If one of the element’s snap positions is chosen in one axis, this has no bearing on the other dimension’s snap position—it might be chosen, or a different element’s snap position might be chosen for that axis, or that axis might not snap at all.

point-snapping

If a scroll container is point-snapping, its descendants indicate a desired scroll position in both axises of the scroll container simultaneously—in other words, some point in the descendant must be aligned to a corresponding point in the scroll container.

This type of snapping behavior is intended for "two-dimensional" panning-type layouts, such as cities on a map (using proximity 2D snap positions to snap a city to the center of the display when it gets close), or a tiled image gallery (using mandatory 2D snap positions to force each image to be centered on the screen). In both of these cases, it would look weird if the horizontal scrolling was aligned to one element while the vertical was aligned to a different element (which is the behavior you’d get if the scroll container was axis-snapping).

7.3. Choosing Snap Positions I-68

A scroll container can have many snap areas scattered throughout its scrollable area. A naive algorithm for selecting a snap position can produce behavior that is unintuitive for users, so care is required when designing a selection algorithm. Here are a few pointers that can aid in the selection process:

• Snap positions should be chosen to minimize the distance between the end-point (or the natural end-point) and the final snapped scroll position, subject to the additional constraints listed in this section.

• Point-snapping is all-or-nothing; if the snap position of an element is chosen to align to, the scroll container must set its scroll position according to the element’s snap positions in both axises; the scroll container must not “partially align” to the element by taking its snap position in one axis and aligning the other axis according to something else.

• If a scroll is axis-locked and the scroll container is axis-snapping, any snap positions in the other axis should be ignored during the scroll. (However, snap positions in the other axis can still effect the final scroll position.)

  If a scroll is axis-locked and the scroll container is point-snapping, snap positions should be penalized in the selection process according to the amount of other-axis scrolling they would cause.

• Snap positions should be ignored if their elements are far outside of the “corridor” that the snapport defines as it moves through the scrollable area during an inertial scroll, or a hypothetical “corridor” in the direction of a directional scroll, or the snapport after an explicit scroll. (This is to prevent a far-offscreen element from having difficult-to-understand effects on the scroll position.)

• User agents must ensure that a user can “escape” a snap position, regardless of the scroll method. For example, if the snap type is mandatory and the next snap position is more than two screen-widths away, a naïve “always snap to nearest” selection algorithm would “trap” the user if they were panning with a touch gesture; a sufficiently large distance would even trap fling scrolling! Instead, a smarter algorithm that only returned to the starting snap position if the end-point was a fairly small distance from it, and otherwise ignored the starting snap position, would give better behavior.

  (This implies that a directional scroll must always ignore the starting snap positions.)

• If a page is navigated to a fragment that defines a target element (one that would be matched by :target), and that element defines some snap positions, the user agent should snap to one of that element’s snap positions. The user agent may do this even when the scroll container has scroll-snap-type: none.