This section is not normative.
Popular UX paradigms for scrollable content frequently employ paging through content, or sectioning into logical divisions. This is especially true for touch interactions where it is quicker and easier for users to quickly pan through a flatly-arranged breadth of content rather than delving into a hierarchical structure through tap navigation. For example, it is easier for a user to view many photos in a photo album by panning through a photo slideshow view rather than tapping on individual photos in an album.
However, given the imprecise nature of scrolling inputs like touch panning and mousewheel scrolling, it is difficult for web developers to guarantee a well-controlled scrolling experience, in particular creating the effect of paging through content. For instance, it is easy for a user to land at an awkward scroll position which leaves an item partially on-screen when panning.
To this end, this module introduces scroll snap positions which enforce the scroll positions that a scroll container’s scrollport may end at after a scrolling operation has completed.
Also, to offer better control over paging and scroll positioning even when snapping is off, this module defines the scroll-padding property for use on all scroll containers, to adjust the scroll container’s optimal viewing region for the purpose of paging and scroll-into-view operations. Similarly the scroll-margin property can be used on any box to adjust its visual area for the purpose of scroll-into-view operations.
1.1. Module interactionsThis module extends the scrolling user interface features defined in [CSS2] section 11.1.
None of the properties in this module apply to the ::first-line and ::first-letter pseudo-elements.
1.2. Value DefinitionsThis specification follows the CSS property definition conventions from [CSS2] using the value definition syntax from [CSS-VALUES-3]. Value types not defined in this specification are defined in CSS Values & Units [CSS-VALUES-3]. Combination with other CSS modules may expand the definitions of these value types.
In addition to the property-specific values listed in their definitions, all properties defined in this specification also accept the CSS-wide keywords as their property value. For readability they have not been repeated explicitly.
2. Motivating ExamplesIn this example, a series of images arranged in a
scroll containerare used to build a photo gallery. In this example the
scroll containeris larger than the photos contained within (such that multiple images may be seen simultaneously), and the image sizes vary. Using mandatory element-based snap positions, scrolling will always complete with an image centered in the
scroll container’sscrollport.
img {
/* Specifies that the center of each photo
should align with the center of the scroll
container in the X axis when snapping */
scroll-snap-align: none center;
}
.photoGallery {
width: 500px;
overflow-x: auto;
overflow-y: hidden;
white-space: nowrap;
/* Requires that the scroll position always be
at a snap position when the scrolling
operation completes. */
scroll-snap-type: x mandatory;
}
<div class="photoGallery">
<img src="img1.jpg">
<img src="img2.jpg">
<img src="img3.jpg">
<img src="img4.jpg">
<img src="img5.jpg">
</div>
The layout of the scroll container’s contents in the example. The snapport is represented by the red rectangle, and the snap area is represented by the yellow rectangle. Since the scroll-snap-align is “center” in the inline (horizontal) axis, a snap position is established at each scroll position which aligns the X-center of the snapport (represented by a red dotted line) with the X-center of a snap area (represented by a yellow dotted line).
This example builds a paginated document that aligns each page near to (but not exactly on) the edge of the
scroll container. This allows the previous page to “peek” in from above in order to make the user aware that they are not yet at the top of the document. Using proximity snap positions instead of mandatory snap positions allows the user to stop halfway through a page (rather than forcing them to snap one page at a time). However, if a scrolling operation would finish near a snap position, then the scroll will be adjusted to align the page as specified.
.page {
/* Defines the top of each page as the
edge that should be used for snapping */
scroll-snap-align: start none;
}
.docScroller {
width: 500px;
overflow-x: hidden;
overflow-y: auto;
/* Specifies that each element’s snap area should
align with a 100px offset from the top edge. */
scroll-padding: 100px 0 0;
/* Encourages scrolling to end at a snap position when the
operation completes, if it is near a snap position */
scroll-snap-type: y proximity;
}
<div class="docScroller">
<div class="page">Page 1</div>
<div class="page">Page 2</div>
<div class="page">Page 3</div>
<div class="page">Page 4</div>
</div>
The layout of the scroll container’s contents in the example. The snapport is represented by the red rectangle (inset from the top by 100px due to the scroll-padding), and the snap area is represented by the yellow rectangle. Since the scroll-snap-align is “start” in the Y axis, a snap position is established at each scroll position which aligns the Y-start of the snapport (represented by a red dotted line) with the Y-start of a snap area (represented by a yellow dotted line). 3. Scroll Snap Model
This module defines controls for scroll snap positions, which are scroll positions that produce particular alignments of content within a scroll container. Using the scroll-snap-type property on the relevant scroll container, the author can request a particular bias for the scrollport to land on a snap position after scrolling operations (including programmatic scrolls such as the scrollTo() method).
Snap positions are specified as a particular alignment (scroll-snap-align) of an element’s scroll snap area (its border bounding box, as modified by scroll-margin) within the scroll container’s snapport (its scrollport, as reduced by scroll-padding). 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 snap position.
The act of adjusting the scroll position of a scroll container’s scrollport such that it is aligned to a snap area is called snapping, and a scroll container may be snapped to a snap area in each axis if its scrollport is aligned with that snap area in that axis and there is no active scrolling operation. When there are multiple valid snap areas, a single one is chosen for each axis when snapping according to the algorithm for selecting between multiple aligned snap areas. 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.
Snap positions only affect the nearest ancestor scroll container on the element’s containing block chain.
4.1. Scroll Snapping Rules: the scroll-snap-type propertyThe scroll-snap-type property specifies whether a scroll container is a scroll snap container, how strictly it snaps, and which axes are considered. If no strictness value is specified, proximity is assumed.
In this example, snapping to headings is enabled in the
block axis(the y axis for horizontal writing, x axis for vertical writing):
html {
scroll-snap-type: block; /* applied to main document scroller */
}
h1, h2, h3, h4, h5, h6 {
scroll-snap-align: start; /* snap to the start (top) of the viewport */
}
UAs must apply the scroll-snap-type value set on the root element to the document viewport. Note that, unlike overflow, scroll-snap-type values are not propagated from HTML body.
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:
The strictness values (none, proximity, mandatory) specify how strictly snap positions are enforced on the scroll container (by forcing an adjustment to the scroll position). Values are defined as follows:
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 scrollport 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.
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.
4.1.3. Re-snapping After Layout ChangesIf the content or layout of the document changes (e.g. content is added, moved, deleted, resized) such that the content of a snapport changes, the UA must re-evaluate the resulting scroll position, and re-snap if required. If the scroll container was snapped before the content change and those same snap areas still exist (e.g. their associated elements were not deleted), the scroll container must be re-snapped to those same snap areas after the content change. A snap area can be snapped in each axis, following the algorithm for selecting between multiple aligned snap areas. If it is not possible to snap to both (e.g. if snapping to one resulted in the other being offscreen), it must prefer the focused box, followed by the targeted box, followed by the block axis if neither box is focused or targeted.
Scrolling required by a re-snap operation to a new or different box must behave and animate the same way as any other scroll-into-view operation, including honoring controls such as scroll-behavior. Scrolling behavior for re-snapping to the same box as before however, is UA-defined. The UA may, for example, when snapped to the start of a section, choose not to animate the scroll to the section’s new position as content is dynamically added earlier in the document in order to create the illusion of not scrolling.
In the following example, the log console, when initially loaded and as each message is added to the bottom, remains snapped to the bottom of the content unless the user has scrolled away from that edge:
.log {
scroll-snap-type: y proximity;
align-content: end;
}
.log::after {
display: block;
content: "";
scroll-snap-align: end;
}
The rules create a single scroll snap area represented by the ::after pseudo-element, positioned at the very bottom of a scroll snap container. If the user scrolls “near” the bottom, the container will snap to it. If more content is dynamically added to the container, it’ll remain snapped to it (because scroll containers are required to re-snap to the same scroll snap area if it still exists after any changes). However, if the user has scrolled to somewhere else in the logs, it won’t do anything at all.
4.2. Scroll Snapport: the scroll-padding propertyThis property specifies (for all scroll containers, not just scroll snap containers) offsets that define the optimal viewing region of a scrollport: the region used as the target region for placing things in view of the user. This allows the author to exclude regions of the scrollport that are obscured by other content (such as fixed-positioned toolbars or sidebars) or simply to put more breathing room between a targeted element and the edges of the scrollport.
The scroll-padding property is a shorthand property that sets all of the scroll-padding-* longhands in one declaration, assigning values to the longhands representing each side exactly as the padding property does for its longhands. Values have the following meanings:
Defines an inward offset from the corresponding edge of the scrollport. When applied to the root viewport, the offset is calculated and applied relative to the layout viewport (rather than the visual viewport) the same way as the corresponding inset properties on fixed-positioned boxes; the optimal viewing region is the remaining area that intersects with the visual viewport.
Indicates that the offset for the corresponding edge of the scrollport is UA-determined. This should generally default to a used length of 0px, but UAs may use heuristics to detect when a non-zero value is more appropriate.
For example, a UA could detect when a
position:fixedelement is being used as an opaque unscrollable “header” that obscures the content below it, and resolve the top offset to the height of that element so that a “page down” operation (such as pressing
PgDn) automatically scrolls by one “visible page” of content.
These offsets reduce the region of the scrollport that is considered “viewable” for scrolling operations: they have no effect on layout, on the scroll origin or initial position, or on whether or not an element is considered actually visible, but should affect whether an element or the caret is considered scrolled into view (e.g. for targeting or focusing operations), and reduce the amount of scrolling for paging operations (such as using the PgUp and PgDn keys or triggering equivalent operations from the scrollbar) so that within the optimal viewing region of the scrollport the user sees a continuous stream of content.
For a scroll snap container this region also defines the scroll snapport—the area of the scrollport that is used as the alignment container for the scroll snap areas when calculating snap positions.
In this example,
scroll-paddingis used to center slideshow images within the portion of the scrollport that is not obscured by a fixed-position toolbar.
html {
overflow-x: auto;
overflow-y: hidden;
scroll-snap-type: x mandatory;
scroll-padding: 0 500px 0 0;
}
.toolbar {
position: fixed;
height: 100%;
width: 500px;
right: 0;
}
img {
scroll-snap-align: none center;
}
UAs must apply the scroll-padding values set on the root element to the document viewport. (Note that, unlike overflow, scroll-padding values are not propagated from HTML body.)
This property is a shorthand property that sets all of the scroll-margin-* longhands in one declaration, assigning values to the longhands representing each side exactly as the margin property does for its longhands.
Values represent outsets defining the scroll snap area that is used for snapping this box to the snapport. The scroll snap area is determined by taking the transformed border box, finding its rectangular bounding box (axis-aligned in the scroll container’s coordinate space), then adding the specified outsets.
Note: This ensures that the scroll snap area is always rectangular and axis-aligned to the scroll container’s coordinate space.
If a page is navigated to a fragment that defines a target element (one that would be matched by :target, or the target of scrollIntoView()), the UA should use the element’s scroll snap area, rather than just its border box, to determine which area of the scrollable overflow area to bring into view, even when snapping is off or not applied on this element.
The scroll-snap-align property specifies 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). The two values specify the snapping alignment in the block axis and inline axis, respectively, as determined by the snap container’s writing mode. If only one value is specified, the second value defaults to the same value.
Values are defined as follows:
Start and end alignments are resolved with respect to the writing mode of the snap container unless the scroll snap area is larger than the snapport, in which case they are resolved with respect to the writing mode of the box itself. (This allows items in a container to have consistent snap alignment in general, while ensuring that start always aligns the item to allow reading its contents from the beginning.)
5.2.1. Scoping Valid Snap Positions to Visible BoxesSince the purpose of scroll snapping is to align content within the scrollport for optimal viewing, a scroll position cannot be considered a valid snap position if snapping to it would leave the contributing snap area entirely outside the snapport, even if it otherwise satisfies the required alignment of the snap area.
For example, a
snap areais top-aligned to the
snapportif its top edge is coincident with the
snapport’s top edge; and this would be considered a valid
snap positionfor block-axis start-aligned snapping of that
snap area if at least part of the snap area is on-screen. If the entire
snap areais outside the
snapport, however, then the
scroll containercannot be considered to be
snappedbecause the required alignment, though satisfied, would not be relevant to the viewer.
╔════viewport════╗┈┈┈┈┈┈┈┈┌──────────────┐
║ ┌─────┐ ┌──┐ ║ │ top-snapping │
║ ├──┐ │ └──┘ ║ │ element │
║ └──┴──┘ ║ │ │
╚════════════════╝ │ │
└──────────────┘
Alignment of an off-screen element is not considered snapping. 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 later.)
Note: Although scroll-snap-type: both evaluates snap positions independently in each axis, choosing of a snap position in one axis can be influenced by snap positions in the other axis. For example, snapping in one axis may push off-screen the snap area that the other axis would otherwise align to, making its snap position invalid and therefore unchooseable.
5.2.2. Snapping Boxes that Overflow the ScrollportIf the snap area is larger than the snapport in a particular axis, then any scroll position in which
the distance between the geometrically previous and subsequent otherwise-valid snap positions in that axis is larger than size of the snapport in that axis,
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. explicit paging).
For example, take the first example in
§ 2 Motivating Examples, 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 it is scrolled sufficiently to trigger snapping to a different snap position.
For another example, mandatory top-snapping on nested
section
elements can produce large snapping areas (from large top-level sections) potentially filled with smaller snapping areas (from the subsections). When the subsections are small enough, they snap normally; when they’re longer, the viewer can scroll arbitrarily within them, or within a large segment of the top-level section that has no subsections to snap to.
┌─ top-level section ─┐ ━┓ ┳ 1 (scroll position = 0) │ │ 1┃ ┃ │ │ ┃ ┃ │ │ ━┩ ┃ │ │ ┆ ╿ │ │ ┆ │ │ │ ┆ │ │┌─── sub-section ───┐│ ╯ ━┓ ┿ 2 │└───────────────────┘│ 2┃ │ │┌─── sub-section ───┐│ ━┓ ┃ ┿ 3 ││ ││ 3┃ ━┛ │ │└───────────────────┘│ ┃ │ │┌─── sub-section ───┐│ ━┛ ━┓ ┿ 4 │└───────────────────┘│ 4┃ │ │┌─── sub-section ───┐│ ━┓ ┃ ╈ 5 ││ ││ 5┃ ━┛ ┃ ││ ││ ┃ ┃ ││ ││ ━┩ ┃ ││ ││ ┆ ┃ ││ ││ ┆ ╹ ││ ││ ┆ │└───────────────────┘│ ┆ └─────────────────────┘ ╯In the figure above, the five numbered viewports represent the five snap positions associated with the top-level section and its four subsections. Because the first and last snap positions are part of ranges taller than the viewport, the viewer is allowed to scroll freely between the top and bottom of each range.
Any position in that range is a valid snap position, which can be snapped to when it is the nearest position; however, if the element is targetted directly (such as by a fragment ID or a scrolling API), the UA will land on the bolded position, which corresponds to the ideal requested alignment of the element’s snap area within the snapport.
Note: If the author had instead set mandatory snap positions on the headings of each section (rather than the sections themselves), the contents of the first and fifth sections would be partially inaccessible to the user, as the heading snap area does not extend to cover the whole section. This is why it’s a bad idea to use mandatory snap positions on elements that might be widely spaced apart.
5.2.3. Unreachable Snap PositionsIf 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 overflow 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.
5.3. Scroll Snap Limits: the scroll-snap-stop propertyWhen performing a relative scroll, the scroll container can “pass over” several possible snap positions (that would be valid to snap to, if the scrolling operation used the same direction but a lesser distance) before reaching the natural endpoint of the scroll operation and selecting its final scroll position. The scroll-snap-stop property allows such a possible snap position to “trap” the scrolling operation, forcing the scroll container to stop before the scrolling operation would naturally end.
Values are defined as follows:
This property has no effect on non-relative scrolling operations, as they do not conceptually “pass over” any snap positions.
6. Snapping MechanicsThe 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.
6.1. Types of Scrolling MethodsThere are many ways to cause a page to scroll, and they differ in their intent, which affects how scroll snapping and other features should respond to them. The types of scrolling intents are:
An absolute scroll is a scrolling operation that is not intended to have any relation with the previous scroll position. Whether the new position is before or after the previous scroll position is not relevant to the operation; the scroll container just "goes straight there".
Common examples of
absolute scrollsinclude:
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
homing operations such as the Home/End keys
Note: Scroll snapping responds to an absolute scroll by finding the nearest valid snap position, regardless of direction.
A relative scroll is a scrolling operation that does have a meaningful relation with the previous scroll position; that is, the fact that the new scroll position is before or after the old scroll position is an important quality of the scroll.
Relative scrolls might or might not have an intended end position, but they always have an intended direction.
Common examples of
relative scrollswith both an intended direction and end position include:
a “fling” gesture, interpreted with momentum
programmatically scrolling via APIs such as scrollBy()
paging operations such as the PgUp/PgDn keys (or equivalent operations on the scrollbar)
Common examples of relative scrolls with only an intended direction include:
pressing an arrow key on the keyboard
pressing an arrow button on the scrollbar
a swiping gesture interpreted as a fixed (rather than inertial) scroll
The intended end point of the scroll prior to intervention from features such as snap points is its natural end-point.
Note: Scroll snapping responds to a relative scroll by finding the nearest valid snap position in the intended direction (if possible), so a snapped element can’t get "trapped" when the snap positions are far apart.
A stationary scroll is a scrolling operation that isn’t "intending" to move the scroller at all; instead, it’s attempting to keep something stationary (usually, an element you’re focusing on).
Common examples of
stationary scrollsinclude:
scroll anchoring with overflow-anchor, when off-screen content changes size and would move the current anchor
scroll snapping (especially mandatory) when another element changes size and causes the scroller to no longer be at a valid snap point
Note: Scroll snapping responds to a stationary scroll by finding the nearest valid snap position, similar to an absolute scroll.
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 less-precise input mechanisms from drifting in the non-primary axis.
Note: This specification only applies to scrolling methods supported by the user agent; it does not require the user agent to support any particular input or scrolling method.
6.2. Choosing Snap PositionsA scroll container can have many snap areas scattered throughout its scrollable overflow area. A naïve 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.
If a scroll is axis-locked, 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.)
In order to prevent a far-offscreen element from having difficult-to-understand effects on the scroll position, snap positions should be ignored if their elements are far outside of the “corridor” that the snapport defines as it moves through the scrollable overflow area, or a hypothetical “corridor” in the direction of a relative scroll, or the snapport after an absolute scroll.
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 might “trap” the user if their end position was only one screen-width away. 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 relative scroll without an intended end position must always ignore the starting snap positions.)
If a page is navigated to a fragment that defines a target element (e.g. one that would be matched by :target, or the target of scrollIntoView()), and that element defines some snap positions, the user agent must snap to one of that element’s snap positions if its nearest scroll container is a scroll snap container. The user agent may also do this even when the scroll container has scroll-snap-type: none.
If a scroll by page operation (e.g. Page down / Page up) is being performed, eligible snap positions that require scrolling less than or equal to the size of the optimal viewing region of the scroll container should be selected before any farther away, ignoring the starting snap positions so that progress is still made in the intended direction.
When snapping to a scroll position that is aligned with multiple scroll snap areas, the following algorithm procedure is used to determined which box is snapped on the block and inline axes for a particular scroll container:
Let scroll position be the scroll position of the scroll container
Let inline be the set of boxes whose scroll snap areas are aligned at this scroll position in the inline axis.
Let block be the set of boxes whose scroll snap areas are aligned at this scroll position in the block axis.
For each list of block and inline:
If list contains the focused box, remove all other boxes from list.
If list contains the targeted box, remove all other boxes from list.
For each box in list:
Remove any box from list which is an ancestor of box.
If inline and block are overlapping sets:
Replace inline with the intersection of inline and block.
Replace block with the intersection of inline and block.
Select the first element in tree order from inline as the snapped inline axis box.
Select the first element in tree order from block as the snapped block axis box.
The physical and logical longhands (and their shorthands) interact as defined in [CSS-LOGICAL-1].
Physical Longhands for scroll-paddingThese longhands of scroll-padding specify the top, right, bottom, and left edges of the snapport, respectively. Negative values are invalid.
Flow-relative Longhands for scroll-paddingThese longhands of scroll-padding specify the block-start, inline-start, block-end, and inline-end edges of the snapport, respectively. Negative values are invalid.
These shorthands of scroll-padding-block-start + scroll-padding-block-end and scroll-padding-inline-start + scroll-padding-inline-end are longhands of scroll-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.
If only one value is specified, the second value defaults to the same value.
Physical Longhands for scroll-marginThese longhands of scroll-margin specify the top, right, bottom, and left edges of the scroll snap area, respectively.
Flow-relative Longhands for scroll-marginThese longhands of scroll-margin specify the block-start, inline-start, block-end, and inline-end edges of the scroll snap area, respectively.
These shorthands of scroll-margin-block-start + scroll-margin-block-end and scroll-margin-inline-start + scroll-margin-inline-end are longhands of scroll-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.
If only one value is specified, the second value defaults to the same value.
7. Privacy and Security ConsiderationsThis 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.
8. AcknowledgementsMany thanks to David Baron, Simon Fraser, Håkon Wium Lie, Theresa O’Connor, François Remy, Majid Valpour, and most especially Robert O’Callahan for their proposals and recommendations, which have been incorporated into this document.
9. Changes 9.1. Changes Since 19 March 2019 CRChanges since the 19 March 2019 Candidate Recommendation include:
If the scroll container was snapped before the content change and that same snap position still exists (e.g. its associated element was not deleted), the scroll container must be re-snapped to that same snap position after the content change. If multiple boxes were snapped before and their snap positions no longer coincide, then if one of them is focused or targeted, the scroll container must re-snap to that one and otherwise which one to re-snap to is UA-defined. (The UA may, for example, track which element is snapped as layout shifts align and de-align the snap positions of other elements.)
Scrolling required by a re-snap operation to a new or different box must behave and animate the same way as any other scroll-into-view operation, including honoring controls such as scroll-behavior. Scrolling behavior for re-snapping to the same box as before however, is UA-defined. The UA may, for example, when snapped to the start of a section, choose not to animation the scroll to the section’s new position as content is dynamically added earlier in the document in order to create the illusion of not scrolling.
UAs must apply the scroll-snap-type value set on the root element to the document viewport. Note that, unlike overflow, scroll-snap-type values are not propagated from HTML
body.
UAs must apply the scroll-padding values set on the root element to the document viewport. (Note that, unlike overflow, scroll-padding values are not propagated from HTML
body.)
Defines an inward offset from the corresponding edge of the scrollport. When applied to the root viewport, the offset is calculated and applied relative to the layout viewport (rather than the visual viewport) the same way as the corresponding inset properties on fixed-positioned boxes; the optimal viewing region is the remaining area that intersects with the visual viewport.
A Disposition of Comments is available.
9.2. Changes Since 31 January 2019 CRChanges since the 31 January 2019 Candidate Recommendation include:
Also, to offer better control over paging and scroll positioning even when snapping is off, this module defines the scroll-padding property for use on all scroll containers, to adjust the scroll container’s optimal viewing region for the purpose of paging and scroll-into-view operations; similarly the scroll-margin property can be used on any box to adjust its visual area for the purpose of scroll-into-view operations.
This property specifies (for all scroll containers, not just scroll snap containers) offsets that define the optimal viewing region of a scrollport…
If a page is navigated to a fragment that defines a target element (one that would be matched by :target, or the target of
scrollIntoView()), the UA should use the element’s scroll snap area, rather than just its border box, to determine which area of the scrollable overflow area to bring into view , even when snapping is off or not applied on this element .
Changes since the 14 August 2018 Candidate Recommendation include:
A Disposition of Comments is available.
9.4. Changes Since 14 December 2017 CRChanges since the 14 December 2017 Candidate Recommendation include:
scrollTo() are also subject to snapping. (Issue 2593)
Using the scroll-snap-type property on the relevant scroll container, the author can request a particular bias for the scrollport to land on a snap position after scrolling operations (including programmatic scrolls such as the scrollTo() method) .
A Disposition of Comments is available.
9.5. Changes Since 24 August 2017 CRChanges since the 24 August 2017 Candidate Recommendation include:
scrollIntoView()/etc should take scroll-margin into account, regardless of whether snapping is turned on or not. (Issue 1
If a page is navigated to a fragment that defines a target element (one that would be matched by :target, or the target of
scrollIntoView()), the UA should use the element’s scroll snap area, rather than just its border box, to determine which area of the scrollable overflow area to bring into view.
scrollIntoView()/etc must (rather than should) use snap positions if snapping is turned on. (Issue 1
If a page is navigated to a fragment that defines a target element (one that would be matched by :target, or the target of
scrollIntoView()), and that element defines some snap positions, the user agent should mustsnap to one of that element’s snap positions if its nearest scroll container is a scroll snap container . The user agent may also do this even when the scroll container has scroll-snap-type: none.
A Disposition of Comments is available.
9.6. Changes Since 20 October 2016 CRChanges since the 20 October 2016 Candidate Recommendation include:
Values must be non-negative and are interpreted as for padding …
Although scroll-snap-type: both evaluates snap positions independently in each axis, choosing of a snap position in one axis may be influenced by snap positions in the other axis. For example, snapping in one axis may push off-screen the snap area that the other axis would otherwise align to, making its snap position invalid and therefore unchooseable.
This specification only applies to scrolling methods supported by the user agent; it does not require the user agent to support any particular input or scrolling method.
A Disposition of Comments is available.
Conformance requirements are expressed with a combination of descriptive assertions and RFC 2119 terminology. The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in the normative parts of this document are to be interpreted as described in RFC 2119. However, for readability, these words do not appear in all uppercase letters in this specification.
All of the text of this specification is normative except sections explicitly marked as non-normative, examples, and notes. [RFC2119]
Examples in this specification are introduced with the words “for example” or are set apart from the normative text with class="example", like this:
Informative notes begin with the word “Note” and are set apart from the normative text with class="note", like this:
Note, this is an informative note.
Advisements are normative sections styled to evoke special attention and are set apart from other normative text with <strong class="advisement">, like this: UAs MUST provide an accessible alternative.
A style sheet is conformant to this specification if all of its statements that use syntax defined in this module are valid according to the generic CSS grammar and the individual grammars of each feature defined in this module.
A renderer is conformant to this specification if, in addition to interpreting the style sheet as defined by the appropriate specifications, it supports all the features defined by this specification by parsing them correctly and rendering the document accordingly. However, the inability of a UA to correctly render a document due to limitations of the device does not make the UA non-conformant. (For example, a UA is not required to render color on a monochrome monitor.)
An authoring tool is conformant to this specification if it writes style sheets that are syntactically correct according to the generic CSS grammar and the individual grammars of each feature in this module, and meet all other conformance requirements of style sheets as described in this module.
So that authors can exploit the forward-compatible parsing rules to assign fallback values, CSS renderers must treat as invalid (and ignore as appropriate) any at-rules, properties, property values, keywords, and other syntactic constructs for which they have no usable level of support. In particular, user agents must not selectively ignore unsupported component values and honor supported values in a single multi-value property declaration: if any value is considered invalid (as unsupported values must be), CSS requires that the entire declaration be ignored.
Once a specification reaches the Candidate Recommendation stage, non-experimental implementations are possible, and implementors should release an unprefixed implementation of any CR-level feature they can demonstrate to be correctly implemented according to spec.
To establish and maintain the interoperability of CSS across implementations, the CSS Working Group requests that non-experimental CSS renderers submit an implementation report (and, if necessary, the testcases used for that implementation report) to the W3C before releasing an unprefixed implementation of any CSS features. Testcases submitted to W3C are subject to review and correction by the CSS Working Group.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4