8000 csswg-drafts/css-scroll-snap-1/Proposal.src.html at 909a92d3ebe85ecd5a0cee174534f4f808017471 · w3c/csswg-drafts · GitHub
Skip to content

Proposal.src.html

Latest commit

 

History

History
1176 lines (994 loc) · 45.6 KB

Proposal.src.html

File metadata and controls

1176 lines (994 loc) · 45.6 KB
If the <a>snap area</a> is larger than the <a>snapport</a> in a particular axis,
and there are no other <a>snap areas</a> within the <a>snapport</a>
that would provide a <a>snap position</a> aligning the overflowing <a>snap area</a> within the <a>snapport</a>,
then any scroll position in which the <a>snap area</a> covers the <a>snapport</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, 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 <a>snap area</a> is larger than the <a>snapport</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 resists outward scrolling
until you fling out or pull it sufficiently to trigger snapping to a different <a>snap position</a>.
</div>
<h4 id="unreachable">
Unreachable Snap Areas</h4>
If a <a>snap position</a> is unreachable as specified,
such that aligning to it would require scrolling the <a>scroll container</a>’s viewport
past the edge of its <a>scrollable area</a>,
the <em>used</em> <a>snap position</a> for this <a>snap area</a>
is the position resulting from scrolling <em>as much as possible</em> in each relevant axis
toward the desired <a>snap position</a>.
<!--
██████ ████████ ███████ ████████
██ ██ ██ ██ ██ ██ ██
██ ██ ██ ██ ██ ██
██████ ██ ██ ██ ████████
██ ██ ██ ██ ██
██ ██ ██ ██ ██ ██
██████ ██ ███████ ██
-->
Scroll Snap Limits: the 'scroll-snap-stop' property {#scroll-snap-stop}
--------------------------
<pre class="propdef">
Name: scroll-snap-stop
Value: normal | always
Initial: normal
Applies to: all elements
Inherited: no
Percentages: n/a
Computed value: as specified
Animatable: no
Media: interactive
</pre>
This property specifies whether the <a>snap position</a>
absorbs all remaining inertia during an <a>inertial scroll</a>,
or allows the <a>inertial scroll</a> to pass multiple <a>snap positions</a> before coming to rest.
Values are defined as follows:
<dl dfn-type=value dfn-for=scroll-snap-stop>
<dt><dfn>normal</dfn>
<dd>
A <a>snap position</a> defined by this element
does not interfere with the inertia
of an <a>inertial scroll</a> that is passing across it,
unless it is the landing <a>snap position</a>.
<dt><dfn>always</dfn>
<dd>
A <a>snap position</a> defined by this element,
when encountered by an <a>inertial scroll</a>,
absorbs all remaining inertia from an <a>inertial scroll</a>,
forcing a stop at this <a>snap position</a>,
exactly as if the scroll had enough inertia to reach the <a>snap position</a>,
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 <a>snap position</a>
per inertial scroll action.
</dl>
Snapping Mechanics {#snap-concepts}
===================================
The precise model algorithm to select a <a>snap position</a> 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.
<!--
████████ ██ ██ ████████ ████████ ██████
██ ██ ██ ██ ██ ██ ██ ██
██ ████ ██ ██ ██ ██
██ ██ ████████ ██████ ██████
██ ██ ██ ██ ██
██ ██ ██ ██ ██ ██
██ ██ ██ ████████ ██████
-->
Types of Scrolling Methods {#scroll-types}
------------------------------------------
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:
: <dfn export local-lt="explicit" lt="explicit scroll">explicit scrolling</dfn>
:: A scroll is <a>explicit</a> 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 {{Window/scrollTo()}}
* tabbing through the document's focusable elements
* navigating to an anchor within the page
: <dfn export local-lt="inertial" lt="inertial scroll">inertial scrolling</dfn>
:: A scroll is <a>inertial</a> 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 {{Window/scrollBy()}}
The scroll position that an <a>inertial</a> scroll would naturally land on
without further intervention is the <dfn noexport>natural end-point</dfn>.
: <dfn export local-lt="directional" lt="directional scroll">directional scrolling</dfn>
:: A scroll is <a>directional</a> 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 <dfn export>axis-lock</dfn> a scroll when its direction
is sufficiently vertical or horizontal.
An <a>axis-locked</a> scroll is bound to only scroll along that axis.
This prevents,
for example,
a <em>nearly</em> horizontal fling gesture from gradually drifting up or down as well,
because it is very difficult to fling in a precisely horizontal line.
<!--
██ ████████ ███████ ████████
████ ██ ██ ██ ██ ██ ██
██ ██ ██ ██ ██ ██
██ ██ ██ ███████ ██ ██
██ ██ ██ ██ ██ ██
██ ██ ██ ██ ██ ██
██████ ████████ █████████ ████████
-->
Axis vs Point-Snapping {#snap-dimensions}
-----------------------------------------
Issue: 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 <dfn lt="snap behavior|snapping behavior">snapping behaviors</dfn> that a <a>scroll container</a> might engage in:
: <dfn export local-lt="axis" lt="axis-snapping|axis-snap">axis-snapping</dfn>
:: If a <a>scroll container</a> is <a>axis-snapping</a>,
its descendants indicate a desired scroll position
in each axis of the <a>scroll container</a> independently,
with no dependent preference for what the other axis's scroll position should be.
Note: This is the “default” type of <a>snap behavior</a>
that most <a>scroll containers</a> will want to use,
and so the ''scroll-snap-type'' property intentionally defaults to it.
Note: An element in an <a>axis-snapping</a> <a>scroll container</a>
can declare two <a>snap positions</a>,
one in each axis.
If one of the element's <a>snap positions</a> is chosen in one axis,
this has no bearing on the other dimension's <a>snap position</a>--
it might be chosen,
or a different element's <a>snap position</a> might be chosen for that axis,
or that axis might not snap at all.
: <dfn export local-lt="point" lt="point-snapping|point-snap">point-snapping</dfn>
:: If a <a>scroll container</a> is <a>point-snapping</a>,
its descendants indicate a desired scroll position
in both axises of the <a>scroll container</a> simultaneously--
in other words,
some point in the descendant must be aligned to a corresponding point in the <a>scroll container</a>.
This type of <a>snapping behavior</a> 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 <a>scroll container</a> was <a>axis-snapping</a>).
<!--
██████ ██ ██ ███████ ███████ ██████ ████ ██ ██ ██████
██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ███ ██ ██ ██
██ ██ ██ ██ ██ ██ ██ ██ ██ ████ ██ ██
██ █████████ ██ ██ ██ ██ ██████ ██ ██ ██ ██ ██ ████
██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ████ ██ ██
██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ███ ██ ██
██████ ██ ██ ███████ ███████ ██████ ████ ██ ██ ██████
-->
Choosing Snap Positions {#choosing}
-----------------------------------
A <a>scroll container</a> can have many <a>snap areas</a>
scattered throughout its <a>scrollable area</a>.
A naive algorithm for selecting a <a>snap position</a>
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:
* <a>Snap positions</a> should be chosen to minimize the distance between the end-point
(or the <a>natural end-point</a>)
and the final snapped scroll position,
subject to the additional constraints listed in this section.
* <a>Point-snapping</a> is all-or-nothing;
if the <a>snap position</a> of an element is chosen to align to,
the <a>scroll container</a> must set its scroll position
according to the element's <a>snap positions</a> in <em>both</em> axises;
the <a>scroll container</a> <em>must not</em> “partially align” to the element
by taking its <a>snap position</a> in one axis
and aligning the other axis according to something else.
* If a scroll is <a>axis-locked</a> and the <a>scroll container</a> is <a>axis-snapping</a>,
any <a>snap positions</a> in the other axis should be ignored
during the scroll.
(However, <a>snap positions</a> in the other axis can still effect the final scroll position.)
If a scroll is <a>axis-locked</a> and the <a>scroll container</a> is <a>point-snapping</a>,
<a>snap positions</a> should be penalized in the selection process
according to the amount of other-axis scrolling they would cause.
* <a>Snap positions</a> should be ignored if their elements are far outside of the “corridor”
that the <a>snapport</a> defines as it moves through the <a>scrollable area</a>
during an <a>inertial scroll</a>,
or a hypothetical “corridor” in the direction of a <a>directional scroll</a>,
or the <a>snapport</a> after an <a>explicit scroll</a>.
(This is to prevent a far-offscreen element
from having difficult-to-understand effects
on the scroll position.)
* User agents <em>must</em> ensure that a user can “escape” a <a>snap position</a>,
regardless of the scroll method.
For example, if the snap type is ''mandatory''
and the next <a>snap position</a> 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 <a>snap position</a>
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 <a>directional scroll</a> must always ignore the starting <a>snap positions</a>.)
* 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 <a>snap positions</a>,
the user agent should <a>snap</a> to one of that element's <a>snap positions</a>.
The user agent may do this even when the <a>scroll container</a> has ''scroll-snap-type: none''.
<!--
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}
-------------------------
View remainder of file in raw view