CSS Scroll Snap Points 1 Module Level 1

Change Proposal Diff,

This version:
https://drafts.csswg.org/css-snappoints/ https://drafts.csswg.org/css-scroll-snap/ 1
Latest version:
http://www.w3.org/TR/css-snappoints-1/
Previous Versions:
http://www.w3.org/TR/2015/WD-css-snappoints-1-20150326/
Feedback:
www-style@w3.org with subject line “ [css-snappoints] [css-scroll-snap] 1 … message topic … ” ( archives)
Issue Tracking:
In Disposition of Comments (see also previous Disposition of Comments)
Editors:
Matt Rakow (Microsoft)
Tab Atkins-Bittner (Google)
Jacob Rossi (Microsoft)
Elika J. Etemad / fantasai (Invited Expert)

Abstract

This module contains features to control panning and scrolling behavior with "snap positions". CSS is a language for describing the rendering of structured documents (such as HTML and XML) on screen, on paper, in speech, etc.

Status of this document

This is a diff as of 23 April 2016.

1. Introduction

[No proposed changes.]

2. Motivating Examples

[ This collection of examples needs updating to better showcase how scroll snap now works, such as in cases where sizes of the content and/or viewport are variable. ]

3. Overview

This module introduces control over scroll snap positions, which are scroll positions that produce particular alignments of content within a scrollable viewport. Using the scroll-snap-type property n the relevant scroll container, the author can request a particular bias for the viewport to land on a valid V snap position after scrolling operations.

Snap positions can be specified as a particular alignment (scroll-snap-align) of an element’s scroll snap margin scroll snap area 2 (scroll-snap-margin, defaulting to its margin box its border bounding box, as modified by scroll-snap-margin 3) within the scroll container’s snapport (the rectangle obtained by reducing its visual viewport its visual viewport, as reduced by its scroll-snap-padding R). This is conceptually equivalent to specifying the alignment of an alignment subject within an alignment container. A scroll position that satisfies the specified alignment is a valid V snap position.

The act of adjusting the scroll offset of a scroll container’s visual viewport such that it is aligned to a snap position is called snapping, and a scroll container is said to be snapped to a snap position if its visual viewport’s scroll offset is that snap position and there is no active scrolling operation. D The CSS Scroll Snap Module intentionally does not specify nor mandate any precise animations or physics used to enforce snap positions; this is left up to the user agent. 4

Snap positions must only affect the nearest ancestor (on the element’scontaining block chain) scroll container on the element’scontaining block chain. R

4. Definitions D

scroll container
An element which provides a scrolling user interface as described in [CSS21], particularly in the section on overflow.
snap alignment container
A scroll container’s snap alignment container is the rectangle obtained by reducing its visual viewport by its scroll-snap-padding.

Better name for this concept?

snap margin
An element’s snap margin is the rectangle obtained by expanding its border box by its scroll-snap-margin.
snap position
For a scroll container, a particular value for its scroll offset is a snap position if when scrolled to that offset the visual viewport of the scroll container would align with a descendent element in the manner specified by the scroll snap properties.
snapped
A scroll container is said to be snapped to a snap position if its visual viewport’s scroll offset is that snap position and there is no active scrolling operation.
snap
The act of adjusting the scroll offset of a scroll container’s visual viewport such that it is snapped to a snap position is called snapping.

5 Capturing Scroll Snap Areas: S Properties on the scroll container

5.1. Scroll Snapping Rules Types: S the scroll-snap-type property

Name: scroll-snap-type
Value: none | [ proximity | mandatory ] || [ x | y | block | inline | both | point ] 5
Initial: none
Applies to: all elements
Inherited: no
Percentages: n/a
Computed value: as specified
Animatable: no

The scroll-snap-type property defines specifies whether a scroll container is a scroll snap container, 6 how strictly a scroll container it should snaps, and which axes are considered 5. It intentionally does not specify nor mandate any precise animations or physics used in snapping; this is left up to the user agent 4

We’re considering splitting this into subproperties. Current proposed names are scroll-snap for the current grammar, scroll-snap-affinity for the proximity/mandatory distinction, and scroll-snap-axis for the x/y/etc distinction.

The strictness values (none, proximity, mandatory) specify how strictly snap positions are enforced on the scroll container (by forcing an adjustment to the scroll offset). 5 Values are defined as follows:

none

If specified on a scroll container, 6 the scroll container must not snap: all scroll positions are equally valid. C

If specified on a non-scroll container, this value has no effect. 6

proximity

If specified on a scroll container, 6 the scroll container may snap to a valid snap positionC at the termination of a scroll, at the discretion of the UA given the parameters of the scroll.

If the content changes such that the scroll container would no longer be snapped (e.g. content is added, moved, deleted, resized) to the same snap position it was snapped to before the content change and that same snap position still exists (e.g. its associated element was not deleted) and is reachable, the scroll container must be re-snapped to that same snap position after the content change. 9

If specified on a non-scroll container, this value “traps” descendant boxes’ snap positions, preventing them from affecting any ancestor scroll containers. 6

mandatory
If specified on a scroll container, 6 the scroll container is guaranteed required 8 to be snapped to a valid snap position C when there are no active scrolling operations. If a reachable snap position exists, then the scroll container must snap at the termination of a scroll. That is, it must snap to a valid snap position at the termination of a scroll, if any exist. (If no reachable snap position none exists, then no snapping occurs.) R If the content changes such that the scroll container would no longer be snapped (e.g. content is added, moved, deleted, resized) to the same snap position it was snapped to before the content change, the scroll container must be re-snapped. If the same snap position it was snapped to before the content change still exists (e.g. its associated element was not deleted) and is reachable, the scroll container must be re-snapped to that same snap position after the content change. 9

If specified on a non-scroll container, this value “traps” descendant boxes’ snap positions, preventing them from affecting any ancestor scroll containers. 6

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

For example, if an author wishes to force snapping to the top of each section heading, s/he could accomplish this in two ways: snapping the headings
h1, h2, h3, h4, h5, h6 { scroll-snap-align: start; } /* snap headings - but not section content */

or snapping the section elements.

section { scroll-snap-align: start; }                /* snap entire section - including content */

If the author chooses mandatory snapping of the headings, and one section is longer than the viewport, then the reader will have difficulty accessing the content that overflows the screen, because mandatory snapping does not allow the scroll position to rest on the content between the snapped headings.

However, if the author chooses mandatory snapping of the section element (which contains all the content of the section) then the UA can allow the reader to scroll freely through the entire section in the cases where the content is longer than the screen.

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:

5

9

If the content or layout of the scroll container changes e.g. content is added, moved, deleted, resized), the UA must re-evaluate, and potentially re-snap if necessary, the resulting scroll offset once the positions of the content have restabilized. This can result in no snapping, (e.g. if there are no nearby snap positions for a proximity-snapping scroll container). However, if there was a previously-snapped snap position (associated with the same element) that still exists after such changes, the UA must remain snapped to iteven if the changes would have placed a different snap position closer to the current scroll offset C. Otherwise, the scroll container must be re-snapped as if the user had scrolled to its current scroll offset (as an explicit scroll, if no other scroll operation is active).

changes such that the scroll container would no longer be snapped (e.g. content is added, moved, deleted, resized) to the same snap position it was snapped to before the content change and that same snap position still exists (e.g. its associated element was not deleted) and is reachable, the scroll container must be re-snapped to that same snap position after the content change.

changes such that the scroll container would no longer be snapped (e.g. content is added, moved, deleted, resized) to the same snap position it was snapped to before the content change, the scroll container must be re-snapped. If the same snap position it was snapped to before the content change still exists (e.g. its associated element was not deleted) and is reachable, the scroll container must be re-snapped to that same snap position after the content change.

5.2. Scroll Snap Padding Snapping Window S: he scroll-snap-padding property

Name: scroll-snap-padding
Value: [ <length> | <percentage> ]{1,4}
Initial: 0
Applies to: scroll containers
Inherited: no
Percentages: relative to the corresponding dimension of 8 the scroll container’s visual viewport
Computed value: as specified, with lengths made absolute
Animatable: yes as length, percentage, or calc 9

The scroll-snap-padding property defines the scroll snapporta region inset from the visual viewport of a scroll container used in calculating its snap positions. The snapport is used as the alignment container when calculating snap positions. the area of the scrollport that is used as the alignment container of the scroll snap areas when calculating their snap positions. R

[ <length> | <percentage> ]{1,4}
Specifies the region inset from the visual viewport. R Values are interpreted as for padding, and specify inward offsets from each edge of the visual viewport.

This property is a shorthand property that sets all of the scroll-snap-padding-* longhands in one declaration.

6. Aligning Scroll Snap Areas: Properties on the elements scrolling content

6.1. Scroll Snap Margin Snapping Area S: the scroll-snap-margin property

Name: scroll-snap-margin
Value: <length>{1,4}
Initial: 0
Applies to: all elements
Inherited: no
Percentages: n/a
Computed value: as specified, with lengths made absolute
Animatable: yes as length

The scroll-snap-margin property defines the scroll snap margin area 2 on elements within a scroll container, used in calculating snap positions for that scroll container that is used for snapping this box to the snapport. R The <length> values give outsets (interpreted as for margin or border-image-outset). The scroll snap area is the rectangular bounding box of the transformed border box, plus the specified outsets, axis-aligned in the scroll container’s coordinate space. 12

<length>{1,4}
Specifies the outset of the element’s snap margin from the axis-aligned bounding box of the transformed border box, in the scroll container’s coordinate space. Outsets are applied to this bounding box, not the border box.

Note: This ensures that the scroll snap margin area 2 is always rectangular and axis-aligned to the scroll container’s coordinate space.

This property is a shorthand property that sets all of the scroll-snap-margin-* longhands in one declaration.

6.2. Scroll Snap Snapping Alignment S: the scroll-snap-align property

Name: scroll-snap-align
Value: [ none | start | end | center ]{1,2}
Initial: none
Applies to: all elements
Inherited: no
Percentages: n/a
Computed value: two keywords
Animatable: no

The scroll-snap-align property specifies how an element’s scroll snap margin should align with its ancestor scroll container’s snapport the box’s snap position as an alignment of its snap area (as the alignment subject) within its snap container’s snapport as the alignment container). 13 The two values specify the snapping behavior in the x block and y inline axes, respectively. If only one value is specified, the second value defaults to the same value.

Values are defined as follows: R

none
This box does not define a snap position in the specified axis.
start
The scroll offset which aligns the start edge of this box’s scroll snap margin with the start edge of its ancestor scroll container’s region defined by scroll-snap-padding in the specified axis is a snap position in that axis.
Start alignment of this box’s scroll snap area within the scroll container’s snapport is a valid snap position in the specified axis. R
end
The scroll offset which aligns the end edge of this box’s scroll snap margin with the end edge of its ancestor scroll container’s region defined by scroll-snap-padding in the specified axis is a snap position in that axis.
End alignment of this box’s scroll snap area within the scroll container’s snapport is a valid snap position in the specified axis. R
center
The scroll offset which aligns the center of this box’s scroll snap margin with the center of its ancestor scroll container’s region defined by scroll-snap-padding in the specified axis is a snap position in that axis.
Center alignment of this box’s scroll snap area within the scroll container’s snapport is a valid snap position in the specified axis. R

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.

15

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?

Why no <length> or <position> values?

The values here represent alignments (in the sense of align-self and justify-self), so are consistent with that syntax. We chose to use this simpler syntax without lengths or percentages because the scroll-snap-margin concept already provides length offsets—but does so in a smarter way, that degrades better on small screens (see above) because it provides more information (a box, rather than a point) to the UA. We could have also added lengths here, but it would provide multiple ways to do the same thing, which is additional overhead for implementation, testing, and (most importantly) author learning. It also introduces more room for cascading errors, and guides authors in the wrong direction—away from scroll-snap-margin.

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.

Why limit snapping to only when the element is visible? As the WebKit implementers point out, extending a snap edge infinitely across the canvas only allows for snapping gridded layouts, and produces odd behavior for the user when off-screen elements do not align with on-screen elements. (If this requirement is onerous for implementers however, we can default to a gridded behavior and introduce a switch to get smarter behavior.)

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).

For example, take the third code fragment in the previous example, which had a photo as the area. The author wants mandatory snapping from item to item, but if the item happens to be larger than your viewport, you want to be able to scroll around the whole thing once you’re over it.

Since the snap area is larger than the snapport, while the area fully fills the viewport, the container can be scrolled arbitrarily and will not try to snap back to its aligned position. However, if the container is scrolled such that the area no longer fully fills the viewport in an axis, the area resists outward scrolling until you fling out or pull it sufficiently to trigger snapping to a different snap position.

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

Name: scroll-snap-stop
Value: normal | always
Initial: normal
Applies to: all elements
Inherited: no
Percentages: n/a
Computed value: as specified
Animatable: no

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 positionit 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:

Appendix A: Longhands

Physical Longhands for scroll-snap-padding

Name: scroll-snap-padding-top, scroll-snap-padding-right, scroll-snap-padding-bottom, scroll-snap-padding-left
Value: <length> | <percentage>
Initial: 0
Applies to: scroll containers
Inherited: no
Percentages: relative to the corresponding dimension of the scroll container’s visual viewport
Computed value: as specified, with lengths made absolute
Animatable: yes as length, percentage, or calc

These longhands of scroll-snap-padding specify the top, right, bottom, and left edges of the snapport, respectively.

Flow-relative Longhands for scroll-snap-padding

Name: scroll-snap-padding-inline-start, scroll-snap-padding-block-start, scroll-snap-padding-inline-end, scroll-padding-block-end
Value: <length> | <percentage>
Initial: 0
Applies to: scroll containers
Inherited: no
Percentages: relative to the corresponding dimension of the scroll container’s visual viewport
Computed value: as specified, with lengths made absolute
Animatable: yes as length, percentage, or calc

These longhands of scroll-snap-padding specify the block-start, inline-start, block-end, and inline-end edges of the snapport, respectively.

Name: scroll-snap-padding-block, scroll-snap-padding-inline
Value: [ <length> | <percentage> ]{1,2}
Initial: 0
Applies to: all elements
Inherited: no
Percentages: n/a
Computed value: as specified, with lengths made absolute
Animatable: yes as length, percentage, or calc

These shorthands of scroll-snap-margin-block-start + scroll-snap-margin-block-end and scroll-snap-margin-inline-start + scroll-snap-margin-inline-end are longhands of scroll-snap-padding, and specify the block-axis and inline-axis edges of the snapport, respectively. If two values are specified, the first gives the start value and the second gives the end value.

Physical Longhands for scroll-snap-margin

Name: scroll-snap-margin-top, scroll-snap-margin-right, scroll-snap-margin-bottom, scroll-snap-margin-left
Value: <length>
Initial: 0
Applies to: all elements
Inherited: no
Percentages: n/a
Computed value: as specified, with lengths made absolute
Animatable: yes as length

These longhands of scroll-snap-margin specify the top, right, bottom, and left edges of the scroll snap area, respectively.

Flow-relative Longhands for scroll-snap-margin

Name: scroll-snap-margin-block-start
Value: <length>
Initial: 0
Applies to: all elements
Inherited: no
Percentages: n/a
Computed value: as specified, with lengths made absolute
Animatable: yes as length

These longhands of scroll-snap-margin specify the block-start, inline-start, block-end, and inline-end edges of the scroll snap area, respectively.

Name: scroll-snap-margin-block, scroll-snap-margin-inline
Value: <length>{1,2}
Initial: 0
Applies to: all elements
Inherited: no
Percentages: n/a
Computed value: as specified, with lengths made absolute
Animatable: yes as length

These shorthands of scroll-snap-margin-block-start/scroll-snap-margin-block-end and scroll-snap-margin-inline-start/scroll-snap-margin-inline-end are longhands of scroll-snap-margin, and specify the block-axis and inline-axis edges of the scroll snap area, respectively. If two values are specified, the first gives the start value and the second gives the end value.

8. Privacy and Security Considerations

This specification does not expose any information whatsoever that is not already exposed to the DOM directly; it just makes scrolling slightly more functional. There are no new privacy or security considerations.

Acknowledgements

Many thanks to lots of people for their proposals and recommendations, some of which are incorporated into this document. David Baron, Simon Fraser, Håkon Wium Lie, Theresa O'Connor, François Remy, Majid Valpour, potentially some anonymous Microsoft engineers (?), and most especially to Robert O'Callahan for their proposals and recommendations, which have been incorporated into this document. A