[css-scroll-snap] Consider more specific guidance for scroll-into-view

[fantasai]

From a discussion about scrollOptions in whatwg/html#2787 (comment) ...

As for the preferred position of the focused element, the CSS Scroll Snap module already defines various parameters for the preferred scroll positions for viewing an element, and imho it is better to re-use these rather than establish a contradictory and less powerful set of arguments in the .focus() API. The scroll-padding property already specifies that it applies, and probably scroll-snap-margin should as well. The spec currently avoids specifying that focusing operations inherently trigger snapping to the element’s snap position, but it does specify that (even when snapping is off), a #fragmentID-targetted element should snap into position... so if this is desired behavior we can look into defining that behavior as well. In any case, it doesn't seem like this belongs specifically in the JS API, unless for some reason the behavior of an API call needs to differ from that of a user-triggered event.

Possible guidance to consider:

• Suggesting that scroll-into-view operations consider scroll-snap-margin in addition to scroll-padding
• Recommending that UAs use the element's snap position if it has one and snapping is on.
• Allowing UAs to use the suggested snap position, if the element has defined one, even if snapping is off.

[css-meeting-bot]

The Working Group just discussed Interaction of scroll-snap and JS scrolling APIs, and agreed to the following resolutions:

• RESOLVED: When using SIV you should take scroll snap margin into account
• RESOLVED: SIV must use the element position if it has one and snapping is on
• RESOLVED: Implementation may use the snap position if snapping is off

The full IRC log of that discussion

<gregwhitworth> Topic: Interaction of scroll-snap and JS scrolling APIs
<astearns> github: https://github.com//issues/1707
<leaverou> TabAtkins: A bit late but bullet is not clipped in Chrome in your example, it just inserts a line, see here: http://dabblet.com/gist/07b894c9f6c1bbc3237c422172d0e5b9
<gregwhitworth> TabAtkins: the scroll snap spec defines that if you do a fragment nav and it defines margin or something, you should pay attention to those
<gregwhitworth> TabAtkins: it doesn't have any guidance on similar scrollIntoView APIs rather than just target scrolling
<gregwhitworth> TabAtkins: we have the API opt into that
<gregwhitworth> TabAtkins: the API has other properties of its own
<Rossen> leaverou, add the <ul>
<gregwhitworth> florian: when you say some properties what are those
<gregwhitworth> fantasai: the things we were consider the scroll snap margin that's the indication that there should be additional space
<leaverou> Rossen: oops, added. Same result.
<gregwhitworth> fantasai: if it has a snap position that's an indication that you should snap that position
<Rossen> leaverou, there is a bullet, right?
<leaverou> Rossen: yes. Tab said there wouldn't be.
<gregwhitworth> fantasai: the third thing, the UA could opt into using the snap position even if snapping is not turned on because the UA is trying to determine this and they may utilize this info from the author for the best end user behavior
<Rossen> leaverou: good, we have interop then :)
<gregwhitworth> astearns: it's a bit vague, but you're going for a must to consider the padding and positioning
<gregwhitworth> smfr: if it an element is in scrolled to it but look at it's container's scroll margin?
<gregwhitworth> fantasai: usually you're looking at the border box for SIV and it will then take scroll margin into account
<gregwhitworth> florian: the other aspect about snap position, if snapping is not turned on but it has position you may use that to position
<gregwhitworth> smfr: would you only look at the targeted item or the ancestor chain?
<gregwhitworth> fantasai: just the one that's being targeted
<gregwhitworth> smfr: it seems weird that your taking a property that's meant solely for scroll snapping and you're adding it to the SIV
<gregwhitworth> fantasai: this is adding author intent to the SIV
<gregwhitworth> smfr: you could add props to SIV
<gregwhitworth> fantasai: this makes it so that you don't have to track it all though
<astearns> q?
<gregwhitworth> smfr: is the UA allowed to override scroll snap margins?
<gregwhitworth> florian: is it implied that we should take scroll padding?
<gregwhitworth> fantasai: yes
<gregwhitworth> florian: I recall doing it in general, but wasn't aware we did it for this API
<gregwhitworth> fantasai: that was intentional, you shouldn't be able to get in a state in JS that you can't get to as a user
<gregwhitworth> astearns: the two of you smfr and Rossen showed some concern
<gregwhitworth> myles: we have to make sure that websites that turn off scroll snapping, with this change the margin will now have effect
<gregwhitworth> fantasai: usually this will get you a better experience
<gregwhitworth> myles: I'll be for implementing this and seeing if this has a web compat issue
<gregwhitworth> fantasai: I don't think we should have a web compat issue
<gregwhitworth> myles: I think we can resolve on this
<gregwhitworth> astearns: I'm hearing some movement to resolving
<gregwhitworth> astearns: anyone object?
<gregwhitworth> RESOLVED: When using SIV you should take scroll snap margin into account
<fantasai> scroll-into-view must use element's snap position if it has one and snapping is on
<gregwhitworth> RESOLVED: SIV must use the element position if it has one and snapping is on
<gregwhitworth> RESOLVED: Implementation may use the snap position if snapping is off
<gregwhitworth> florian: should this change intersection observer?
<gregwhitworth> TabAtkins: I don't think we should bring this in?

[syj10]

As described in https://drafts.csswg.org/cssom-view-1/#dom-element-scrollintoview,
users can specify the alignment of ScrollIntoView by ScrollIntoViewOptions or a boolean.
My questions is, if the javaScript calls element.scrollIntoView({block: "start", inline: "start"}), but the element itself defines its snap alignment as "center". Should the snap alignment override SIV alignment, or the SIV alignment override snap alignment?

More specifically, say scroller A contains scroller B contains target C, and C defines snap alignment as "center" on its snap container B. When we call C.scrollIntoView({block: "start", inline: "start}), should C be center-aligned to B or start-aligned to B? After C is scrolled visible in B, we would scroll A to make sure C is also visible in A. Should C be center-aligned to A, or start-aligned to A(as snap alignment only affect its nearest snap container)?

[fantasai]

What will happen right now is that scrollIntoView's options will “win”, but if the position they land on conflicts with the snapping requirements, then the snapping requirements will subsequently shift the scroll position. Basically it'll be as if the user scrolled to the position that scrollIntoView requested, and then let go of the scroller.

We should probably add a note to clarify this, both to css-scroll-snap and to cssom-view.

[syj10]

Thanks for the clarification!
Does this also apply to element.scrollTo(x, y) and element.scrollBy(dx, dy)?

Correct me if I'm wrong.

1. If it's a smooth-scroll, the scroller first animates to the input position, then animates to the snap position.
2. If it's an instant-scroll, the scroller directly goes to the snap position.
3. When we call scrollIntoView() without options, it would still use the default start-alignment[1]. And if it defines snap-alignment-end, it would land on the end-alignment after SIV.

[1] https://drafts.csswg.org/cssom-view-1/#enumdef-scrolllogicalposition