[CSSWG][css-scroll-snap] Updated CR of CSS Scroll Snapping Level 1

# fantasai (8 months ago)

The CSS WG has published an updated Candidate Recommendation of the CSS Scroll Snapping Module Level 1:

 https://www.w3.org/TR/css-scroll-snap-1/

This module contains features to control panning and scrolling behavior with “snap positions”.

This update renames the 'scroll-snap-margin' property to 'scroll-margin' and applies it also to the target element of scrolling operations such as scrollIntoView(), focus(), and navigating to #fragment.

Note that 'scroll-padding' is already applied generally: www.w3.org/TR/css-scroll-snap-1/#scroll-padding

A related concern was brought up that some DOM APIs define scrolling to an element in a way that conflicts with scroll-snapping; such APIs should allow for an element's snap position, if defined, to dictate the position of an element to the viewport if no explicit argument is given to the contrary.

Significant changes are listed at:

www.w3.org/TR/2017/CR-css-scroll-snap-1-20171214/#changes

Disposition of comments:

drafts.csswg.org/css-scroll-snap-1/issues-cr-2016-08

Please review the draft, and send any comments to this mailing list,

<www-style at w3.org>, prefixed with [css-scroll-snap] (as I did on this

message) or (preferably) file them in the GitHub repository at w3c/csswg-drafts/issues

For the CSS WG, ~fantasai

Contact us to advertise here
# Anne van Kesteren (7 months ago)

On Mon, Dec 25, 2017 at 11:54 AM, fantasai

<fantasai.lists at inkedblade.net> wrote:

A related concern was brought up that some DOM APIs define scrolling to an element in a way that conflicts with scroll-snapping; such APIs should allow for an element's snap position, if defined, to dictate the position of an element to the viewport if no explicit argument is given to the contrary.

The way I would expect this to work is that if CSS "owns" scrolling (which I think it ought to), it defines an operation that performs scrolling taking into account various parameters. Those DOM APIs then call into that operation. Then if you define new properties that affect scrolling, you only need to adjust the scrolling algorithm and the various APIs will not require any changes as they all share the same underlying primitive. I'd recommend figuring out that primitive and clearly documenting it (parts of it are already in CSSOM View if I remember correctly).

# fantasai (5 hours ago)

On 12/25/2017 02:54 AM, fantasai wrote:

The CSS WG has published an updated Candidate Recommendation of the CSS Scroll Snapping Module Level 1:

 https://www.w3.org/TR/css-scroll-snap-1/

This module contains features to control panning and scrolling behavior with “snap positions”.

This update renames the 'scroll-snap-margin' property to 'scroll-margin' and applies it also to the target element of scrolling operations such as scrollIntoView(), focus(), and navigating to #fragment.

Note that 'scroll-padding' is already applied generally: www.w3.org/TR/css-scroll-snap-1/#scroll-padding

A related concern was brought up that some DOM APIs define scrolling to an element in a way that conflicts with scroll-snapping; such APIs should allow for an element's snap position, if defined, to dictate the position of an element to the viewport if no explicit argument is given to the contrary.

Significant changes are listed at:

www.w3.org/TR/2017/CR-css-scroll-snap-1-20171214/#changes

Sorry, that URL should be

www.w3.org/TR/2018/CR-css-scroll-snap-1-20180814/#changes

~fantasai

Want more features?

Request early access to our private beta of readable email premium.