Overview.bs

<pre class='metadata'>
Title: CSS Scroll Snapping Change Proposal
Shortname: css-scroll-snap
Level: 1
Status: UD
Work Status: exploring
Group: CSSWG
ED: https://drafts.csswg.org/css-scroll-snap/
Editor: Tab Atkins-Bittner, Google, http://xanthir.com/contact/
Editor: Elika J. Etemad / fantasai, Invited Expert, http://fantasai.inkedblade.net/contact
Abstract: A brief description of an alternate model for scroll-snapping.
Ignored Terms: snap position, snap positions, inertial scroll, inertial scrolls, semantic scroll, semantic scrolls, scrollable area, scroll-group-align
</pre>

<pre class="link-defaults">
spec: css-shapes-1; type: value; for: <shape-box>
	text: border-box
	text: margin-box
spec: css-writing-modes-3; type: dfn
	text: start
	text: end
</pre>

Introduction {#intro}
=====================

We think scroll snapping is a great idea, and fully support exposing this functionality through CSS. However, a major weakness of the current spec is the way it conceives snapping on a coordinate model rather than a box model. This requires a lot of manual calculations in figuring out the correct coordinates from the box model; and also makes sensible scroll-snap settings dependent on the relative sizes of the viewport and the snappable contents, causing problems for users are unexpectedly large and/or small screens (a problem commonly ignored by many authors).

This proposal builds off of roc's model, using an area-snapping model to intelligently handle adaptation to multiple screen sizes. It also adds group alignment as a built-in concept, rather than requiring authors to build one in JavaScript.

Use Cases {#use-cases}
======================

<div class="example">
	Use Case 1: Snapping to the start or middle of each box
	e.g. address book (start) or photo album (middle)

	1. Snapping to 0.25rem above the top of each heading

		<pre class="lang-css">
		:root { scroll-snap-type: proximity; }
		h1, h2, h3, h4, h5, h6 {
			scroll-snap-align: start;
			scroll-snap-area: 0.25em;
		}
		</pre>

	2. Snapping to the center of each photo

		<pre class="lang-css">
		:root { scroll-snap-type: mandatory; }
		img { scroll-snap-align: center; }
		</pre>
</div>

<div class="example">
	Use Case 2: Snapping to the start or middle of a group of boxes,
	where the number of boxes depends on how many fit in the viewport
	e.g. scrolling image galleries

	1. Snapping to the top of each "page" of address book entries in a list of entries

		<pre class="lang-css">
		:root {
			scroll-snap-type: proximity;
			scroll-group-align: start;
		}
		article {
			scroll-snap-align: group;
		}
		</pre>
</div>

<div class="example">
	Use Case 3: Snapping to boxes (or points) in 2D
	e.g. on a map, where you want to snap points of interest to the
	center, or a flow-chart diagram, where you want to snap the edges
	of each box into the visible area. In both cases, you don't want
	objects wholly outside the visible area to influence snapping.

	1. Snapping each flow chart entry to within the viewport when it falls near the edge:

		<pre class="lang-css">
		:root {
			scroll-snap-type: proximity;
		}
		li {
			scroll-snap-align: edges;
		}
		</pre>

	2. Snapping each city on a map to the center of the viewport,
		but only once it gets near the center in both dimensions:

		<pre class="lang-css">
		:root {
			scroll-snap-type: proximity;
		}
		.city {
			scroll-snap-align: center;
		}
		</pre>
</div>

<div class="example">
	Use Case 4: Slideshow, where successive slides are arranged horizontally,
	and sometimes "detail" slides are placed below the "main" slide for that point.

	<pre class="lang-html">
		&lt;div class="slides">
			&lt;div class="slide">...&lt;/div>
			&lt;div class="slide">...&lt;/div>
			&lt;div class="slide details">
				&lt;div class="slide">...&lt;/div>
				&lt;div class="slide">...&lt;/div>
			&lt;/div>
			&lt;div class="slide">...&lt;/div>
		&lt;/div>
		&lt;style>
		.slides {
			display: flex;
			flex-flow: row;
			scroll-snap-type: mandatory;
			overflow-x: scroll;
			width: 100vw;
			height: 100vh;
		}
		.slide {
			scroll-snap-align: edges;
			width: 100vw;
			min-height: 100vh;
		}
		.slide.details {
			display: flex;
			flex-flow: column;
			scroll-snap-type: mandatory;
			overflow-y: scroll;
		}
		&lt;/style>
	</pre>
</div>

Overview of Change {#proposal}
==============================

On the scroll container:

<table class=data>
	<thead>
		<tr>
			<th>Spec
			<th>Proposal
			<th>Priority
	<tbody>
		<tr>
			<td>'scroll-snap-type'
			<td>'scroll-snap-type' (no change)
			<td>High priority
		<tr>
			<td>''scroll-snap-destination: <<position>>''
			<td>''scroll-snap-padding: [ <<length>> | <<percentage> ]{1,4}''
			<td>
		<tr>
			<td>'scroll-snap-points-x'
			<td>'scroll-snap-points-x'
			<td>
		<tr>
			<td>'scroll-snap-points-y'
			<td>'scroll-snap-points-y'
			<td>
		<tr>
			<td>n/a
			<td>''scroll-group-align: [ start | end | edges ]{1,2} | <<position>>#''
			<td>Low priority
</table>

On the children:

<table class=data>
	<thead>
		<tr>
			<th>Spec
			<th>Proposal
			<th>Priority
	<tbody>
		<tr>
			<td>''scroll-snap-coordinate: <<position>>#''
			<td>''scroll-snap-align: [ none | start | end | edges ]{1,2} | <<position>> | group''
			<td>High priority; simpler version adds a center keyword to the bracketed set instead of allowing the full <<position>># syntax inherited from 'scroll-snap-coordinate'.
				''group'' keyword is low-priority.
		<tr>
			<td>n/a
			<td>''scroll-snap-area: [ border-box | margin-box ] || <<length>>{1,4}''
			<td>High priority
		<!--
		<tr>
			<td>n/a
			<td>''scroll-snap-scope: infinite | finite''
			<td>Only ''finite'' is really necessary to handle all use cases, however UAs might want ''infinite'' as the initial value for performance reasons.
		-->
</table>

Scroll Snapping Model {#snap-model}
=====================

	This module introduces control over <dfn lt="scroll snap position" local-lt="snap position">scroll snap positions</dfn>,
	which are scroll positions that produce particular alignments
	of content within a scrollable viewport.
	Using the 'scroll-snap-type' propoperty on the relevant <a>scroll container</a>,
	the author can request a particular bias
	for the viewport to land on a valid <a>snap position</a>
	during scrolling operations.

	Valid <a>snap positions</a> can be specified
	as a particular alignment ('scroll-snap-align')
	of an element's <a>scroll snap area</a> ('scroll-snap-area', defaulting to its margin box)
	within the <a>scroll container</a>’s <a>snap target area</a>
	(its viewport, as reduced by 'scroll-snap-padding').
	This is conceptually equivalent to specifying the alignment of
	an <a>alignment subject</a> within an <a>alignment container</a>.
	The scroll position that satisfies the specified alignment
	is a valid <a>snap position</a>.

	Valid <a>snap positions</a> can also be specified explicitly
	as coordinates of the <a>scrollable area</a>
	with the 'scroll-snap-points-x' and 'scroll-snap-points-y' properties.

	Issue: Discuss <a>intertial</a> vs <a>semantic</a> scrolling concepts (or drop from spec)

	Issue: Discuss 1D vs 2D snapping behaviors... and scoping. (This is all related?)

Scroll Snapping Container {#snap-container}
=========================

Scroll Snapping Rules: the 'scroll-snap-type' property {#snap-type}
----------------------


	<pre class="propdef">
	Name: scroll-snap-type
	Value: none | [ proximity | mandatory ] && single?
	Initial: none
	Applies to: <a>scroll containers</a>
	Inherited: no
	Percentages: n/a
	Computed value: as specified
	Animatable: no
	Media: interactive
	</pre>

	The 'scroll-snap-type' property is used to define
	how strictly <a>snap positions</a> are enforced on the <a>scroll container</a>
	(by forcing an adjustment to the scroll offset).
	It intentionally does not specify nor mandate any precise animations or physics used to enforce those <a>snap positions</a>;
	this is left up to the user agent.

	Values are defined as follows:

	<dl dfn-type=value dfn-for=scroll-snap-type>
		<dt><dfn>none</dfn>
		<dd>
			The visual viewport of this <a>scroll container</a>
			must ignore <a>snap positions</a>, if any, when scrolled:
			all scroll positions are equally valid.

		<dt><dfn>proximity</dfn>
		<dd>
			The visual viewport of this <a>scroll container</a>
			may come to rest at a <a>snap position</a> 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 visual viewport
			would no longer rest at a <a>snap position</a>
			(e.g. content is added, moved, deleted, resized),
			the scroll offset may be modified to maintain this guarantee.

			* For <a>inertial scrolls</a>,
				if the inertia of the scroll would place the scrolling position near a <a>snap position</a>
				(where "near" is user-agent defined),
				the scroll's inertia must be adjusted to make the scrolling position exactly match the <a>snap position</a> instead.
			* For <a>semantic scrolls</a>, TBD.

		<dt><dfn>mandatory</dfn>
		<dd>
			The visual viewport of this <a>scroll container</a>
			is guaranteed to rest at a <a>snap position</a>
			when there are no active scrolling operations.
			That is, it must come to rest at a <a>snap position</a>
			at the termination of a scroll, if possible.
			If the content changes such that the visual viewport
			would no longer rest at a <a>snap position</a>
			(e.g. content is added, moved, deleted, resized),
			the scroll offset must be modified to maintain this guarantee.

			* For <a>inertial scrolls</a>,
				the scroll's landing position must be adjusted
				to make the scrolling position exactly match the nearest <a>snap position</a>
				that is in the direction of the inertia.

				(That is, if you scroll down with only a little inertia,
				it can't snap back up,
				even if the preceding snap point is closer than the next one.)
			* For <a>semantic scrolls</a>, TBD.

		<dt><dfn>single</dfn>
		<dd>
			This keyword indicates that for <a>inertial scrolls</a>,
			the next <a>snap position</a> in the direction of the inertia
			captures all remaining inertia.
	</dl>

	Issue: See <a href="https://lists.w3.org/Archives/Public/www-style/2015Jul/0452.html">discussion on snapping in response to layout changes</a>.

	Issue: It's not clear from discussions if <css>-ms-scroll-snap-type: mandatory</css> is ''mandatory'' or ''mandatory single''. Should clarify status of the various implementations.

Scroll Snapping Window: the 'scroll-snap-padding' property {#snap-padding}
-----------------------


	<pre class="propdef">
	Name: scroll-snap-padding
	Value: [ <<length>> | <<percentage>> ]{1,4}
	Initial: 0
	Applies to: <a>scroll containers</a>
	Inherited: no
	Percentages: n/a
	Computed value: as specified
	Animatable: no
	Media: interactive
	</pre>

	The 'scroll-snap-padding' property defines the <dfn local-lt="snap target area">scroll snap target area</dfn>--
	the area of the viewport that is used as the <a>alignment container</a>
	when aligning a <a>scroll snap area</a> to a <a>snap position</a>.
	Values are interpreted as for 'padding',
	and specify inward offsets from each side of the viewport.

	<div class="example">
		In this example, points of interest in a map are centered
		within the portion of the viewport that does not include the toolbar overlay.

		<pre>
			map {
			  overflow: scroll;
			  scroll-snap-type: proximity;
			  scroll-snap-padding: 3em 0 0 0;
			}
			toolbar {
				position: absolute;
				margin: 0.5em;
				top: 0; left: 0; right: 0;
				height: 2em;
			}
			city {
				scroll-snap-align: center;
			}
		</pre>
	</div>

	<div class="example">

Coordinate-based Snapping {#snap-points}
=========================

Scroll Snapping Coordinates: the 'scroll-snap-points-x' and 'scroll-snap-points-y' properties {#coordinates}
----------------------------


	<pre class="propdef">
	Name: scroll-snap-points-x, scroll-snap-points-y
	Value: none | repeat(<length>)
	Initial: start end
	Applies to: <a>scroll containers</a>
	Inherited: no
	Percentages: relative to the size of the <a>scrollable area</a> in the appropriate axis
	Computed value: as specified, with lengths made absolute and clamped (see below)
	Animatable: no
	Media: interactive
	</pre>

	The 'scroll-snap-points-x' and 'scroll-snap-points-y' properties
	are used to define the positioning of explicit <a>snap positions</a>
	as coordinates within the <a>scrollable area</a> of the <a>scroll container</a>.

	<dl dfn-type="value" dfn-for="snap-points-x, snap-points-y">
		<dt><dfn>none</dfn>
		<dd>
			No <a>snap positions</a> are defined by this <a>scroll container</a>.
			Contained elements may still define <a>snap positions</a> on this <a>scroll container's</a> behalf.

		<dt><dfn>repeat(<<length>>)</dfn>
		<dd>
			Defines <a>snap position</a> that span the <a>scrollable area</a> in the appropriate axis,
			starting from the <a>start</a> edge of the <a>scrollable area</a> and recurring every <<length>> distance throughout the <a>scrollable area</a>.

			Negative <<length>>s are invalid.
			User agents must define a UA-defined minimum <<length>> greater than 0
			(recommended ''1px''),
			and clamp the computed value to that minimum.
	</dl>

	Coordinates specified by 'scroll-snap-points-x' and 'scroll-snap-points-y'
	are not affected by 'scroll-snap-padding'/'scroll-snap-destination'.

	Issue: Should we add ''start-edge'' and ''end-edge'' keywords here, so that the start and end of the scrollable area can be defined as reachable?
	This would be good for e.g. maps. (See <a href="https://lists.w3.org/Archives/Public/www-style/2015Jul/0453.html">Matt Rakow's take</a> on not having ''start'' or ''end'' here.)

	Issue: It was <a href="https://lists.w3.org/Archives/Public/www-style/2015Jul/0453.html">suggested</a> that repeat() be mutually exclusive with element-based snap positions. Is there a better way to integrate this than having the initial value here be "elements"?

	Issue: This needs logical equivalents (-block/-inline instead of -x/-y).

Element-based Snapping {#element}
======================

Scroll Snapping Area: the 'scroll-snap-area' property {#the-scroll-snap-area}
---------------------

	<pre class="propdef">
	Name: scroll-snap-area
	Value: [ border-box | margin-box ] || <<length>>{1,4}
	Initial: border-box
	Applies to: all elements
	Inherited: no
	Computed value: as specified, with lengths made absolute
	Animatable: yes, if ''border-box''/''margin-box'' are constant
	Media: interactive
	</pre>

	Specifies the <dfn>scroll snap area</dfn> that is used for snapping this box to the viewport.
	<<length>> values give outsets (similar to 'margin' or 'border-image-outset').

Scroll Snapping Alignment: the 'scroll-snap-align' property {#scroll-snap-align}
--------------------------

	<pre class="propdef">
	Name: scroll-snap-align
	Value: [ none | start-edge | end-edge | edges ]{1,2} | <<position>>#
	Initial: none
	Applies to: all elements
	Inherited: no
	Computed value: as specified, with lengths made absolute
	Animatable: no
	Media: interactive
	</pre>

	Specifies the element's <a>snap position</a> as an alignment of
	its <a>snap area</a> (as the <a>alignment subject</a>)
	within the viewport's <a>snap target area</a> (as the <a>alignment container</a>).

	The first value specifies alignment in the inline axis;
	the second value specifies alignment in the block axis.
	If one value is specified, it is duplicated.

	If the <a>snap area</a> is larger than the <a>snap target area</a> in a particular axis,
	then any scroll position in which the <a>snap area</a> covers the <a>snap target area</a>
	is a valid <a>snap position</a> 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).

	<div class="example">
		For example, imagine a photo as the area, or a slide in a slideshow.
		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 <a>snap area</a> is larger than the <a>snap target area</a>,
		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 resisting outward scrolling
		until you fling out or pull it sufficiently to trigger snapping to a different <a>snap position</a>.
	</div>

<!--
### Combining 1D and 2D Snap Alignments ### {#combo-snapping}

	The following algorithm defines
	how to combine 1D (''edges'', ''start'', or ''end'')
	and 2D (''center'' or <<position>>)
	snap alignments
	in the same scroller:

	1. Find the closest block-axis snapping edge in the scroll direction.
	2. Find the closest inline-axis snapping edge in the scroll direction.
	3. Compute the "edge displacement" as the euclidean distance between the current scroll position
		and what the scroll position would be if the scroll container were snapped to the aforementioned two lines.
	4. Find the closest snap *point* in the scroll direction,
		measured by euclidean distance from the current scroll position.
		The difference is the "point displacement".
	5. If the edge displacement is smaller than the point displacement, snap to those edges.
		Otherwise, snap to the point.

	Issue: Think about how mandatory/finite would work when there's nothing within range to snap to.
-->


Scope of Snapping Influence {#scope}
===========================

	Issue: Current spec doesn't define how to select which snap-point to snap to.
	See <a href="https://lists.w3.org/Archives/Public/www-style/2015Jul/0325.html">https://lists.w3.org/Archives/Public/www-style/2015Jul/0325.html</a>
	for a proposal to ignore snap positions far outside the viewport.

	Issue: UAs should be encouraged to ignore snap positions that require scrolling in two dimensions
	when a one-dimensional scroll is triggered.

	Issue: Define that <a>snap position</a> selection is based on the final scroll position that the scroll physics would land the scroller in after a fling.

<!--
Scoping Snaplines to Visible Objects: the 'scroll-snap-scope' property {#scroll-snap-scope}
---------------------------

	<pre class="propdef">
	Name: scroll-snap-scope
	Value: infinite | finite
	Initial: infinite
	Applies to: all elements
	Inherited: no
	Computed value: as specified
	Animatable: no
	Media: interactive
	</pre>

	When ''finite'' snapping is enabled,
	the "gravitational field" of a snap alignment is two-dimensional:
	distance to the snap position is calculated for both dimensions at once.

	In other words, if the snapping radius of influence is <var>r</var>,
	in infinite snapping the box snaps along the y axis
	whenever it is within <var>r</var> of its snapped y position,
	regardless of its x position.
	But in finite snapping,
	the box snaps along the y axis
	whenever it is within <var>r</var> of its snapped position
	in both dimensions.

	<div class="example">
		For example, a small box is snapped to the center of the viewport.
		It only snaps whenever it is < <var>r</var> distance in any direction
		from its snap position in both dimensions.
		In other words, it snaps whenever sqrt(<var>d<sub>x</sub></var><sup>2</sup> + <var>d<sub>y</sub></var><sup>2</sup>) &le; <var>r</var>
		for <var>d<sub>x</sub></var>,<var>d<sub>y</sub></var> as distance to the snapped position in the x and y dimensions, respectively.
	</div>

	<div class="example">
		As another example, a small box is snapped to the edges of the viewport.
		It only snaps whenever matching edges are within <var>r</var> of the respective viewport edges,
		so e.g. whenever its top edge approaches the top of the viewport,
		or its left edge approaches the left of the viewport;
		but there is no snapping effect if those edges are > <var>r</var> outside the viewport.
	</div>

	Issue: This feature can be safely deferred to a future level, if necessary.
	Alternately it can be dropped and ''finite'' snapping can be the default.
	(We can't think of a use case for the infinite snapping model,
	except perhaps UA performance.)
-->

Group-based Snapping {#group}
========================

Issue: This section will likely be dropped.

Collects the <a>scroll snap areas</a> of all group-snapped boxes,
segments them into groups that will fit within the viewport,
then creates synthesized <a>scroll snap areas</a> to represent each group.
The <a>snap positions</a> introduced by these boxes
is then the 'scroll-group-align' alignment of each such group
within the viewport.
(Note that such areas may overlap,
if group-snapped boxes are arranged in an overlapping pattern.)

This is a simple form of "scrolling by pages".

<div class="example">
	Use Case 1: Snapping to the top of each "page" of address book entries in a list of entries.

	<pre class="lang-css">
	:root {
		scroll-snap-type: proximity;
		scroll-group-align: start;
	}
	article {
		scroll-snap-align: group;
	}
	</pre>
</div>

<div class="example">
	Use Case 2: Scrolling an article to the first paragraph that hasn't been completely read.

	<pre class="lang-css">
	article {
		scroll-snap-type: proximity;
		scroll-group-align: start;
	}
	article > * {
		scroll-snap-align: group;
	}
	</pre>
</div>

<div class="example">
	Use Case 3: Scrolling image gallery, a la Pinterest, where images are packed tightly on the page.

	<pre class="lang-css">
	.gallery {
		scroll-snap-type: proximity;
		scroll-group-align: center;
	}
	.gallery > img {
		scroll-snap-align: group;
	}
	</pre>
</div>

Turning On Group Snapping: the ''group'' value of 'scroll-snap-align' {#scroll-snap-align-group}
-------------------------

	<pre class="propdef partial">
	Name: scroll-snap-align
	New values: group
	</pre>

	The <dfn value for=scroll-snap-align>group</dfn> value
	specifies that this element's scroll snap area should be group-aligned to the viewport.

Aligning the Group: the 'scroll-snap-group' property {#scroll-snap-group}
-----------------

	<pre class="propdef">
	Name: scroll-snap-group
	Value: [ start-edge | end-edge | edges | center ]{1,2}
	Initial: start
	Applies to: all elements
	Inherited: no
	Computed value: as specified
	Animatable: no
	Media: interactive
	</pre>

	Specifies the alignment of a group-snapped group's area within the viewport.