[css-scroll-snap][cssom] Define interaction of ScrollIntoView options and scroll-snap

[fantasai]

Scroll Snap and CSSOM View currently conflict with each other: they both attempt to define the position of the element wrt the viewport when scrolled into view.

For sure, Scroll Snap should win when there's no arguments given to the API.

I also think that the positioning arguments should be dropped in favor of control with the scroll snap properties, unless there's a compelling reason why a JS API call needs a different value than is given declaratively in CSS. (Note, according to MDN, ScrollIntoViewOptions have only been implemented in Gecko.)

[css-meeting-bot]

The Working Group just discussed Scroll Into View options, and agreed to the following resolutions:

• RESOLVED: We will make the changes to specs as necessary to ack scroll snap when no arguments are provided to ScrollIntoView
• RESOLVED: To keep scrollIntoView() options as they are

The full IRC log of that discussion

<gregwhitworth> Topic: Scroll Into View options
<astearns> github: https://github.com//issues/1708
<gregwhitworth> fantasai: there are several different options that target an element, such as scroll into view
<gregwhitworth> fantasai: then there is the focus api
<gregwhitworth> fantasai: this takes a bunch of args for smooth scrolling or not, how that element should be aligned within the viewport
<gregwhitworth> fantasai: the default behavior you should be following the scroll snap if the scroll snap says something
<gregwhitworth> fantasai: the second question is, are those options even necessary if there are scroll snap options
<gregwhitworth> TabAtkins: we discussed this internally, there may be areas where you want to do one off alignment
<gregwhitworth> fantasai: do you have a usecase
<gregwhitworth> eae: one is up and down arrows, you may want to align to the top or the bottom
<gregwhitworth> iank_: if you have a news feed you may want to use one or the either based on direction
<gregwhitworth> dbaron: we had a discussion about these options a few weeks ago
<gregwhitworth> dbaron: in that discussion I pasted the link to our internal code and if we want use cases where we use it
<gregwhitworth> smfr: is scrollIntoView default the same as SIV false
<dbaron> The Gecko internal API is documented here: https://searchfox.org/mozilla-central/source/layout/base/nsIPresShell.h#669-763
<dbaron> er, better permalink: https://searchfox.org/mozilla-central/rev/7e090b227f7a0ec44d4ded604823d48823158c51/layout/base/nsIPresShell.h#669-763
<gregwhitworth> smfr: we may scroll it into the top or the bottom, just as long as it's in the view
<gregwhitworth> TabAtkins: this became a weird api for legacy issues
<gregwhitworth> eae: our default is either true or false based on distance
<gregwhitworth> florian: your usecase of the newsfeed I think we should solve that in CSS scroll snapping
<gregwhitworth> myles: but that criteria of direction could be a bunch of different criteria, I don't think we should do that
<gregwhitworth> dbaron: most of the complicated ones come from the a11y code
<gregwhitworth> iank_: it looks like scrollIntoView args might be different than scrollIntoView with bool
<dbaron> s/most/some/
<gregwhitworth> iank_: if it's bool we set the block to start
<gregwhitworth> TabAtkins: that isn't per spec
<gregwhitworth> iank_: ok
<gregwhitworth> eae: ours is completely broken
<gregwhitworth> TabAtkins: I may open an issue on this
<gregwhitworth> astearns: I'm hearing at least 4 threads of convo
<gregwhitworth> astearns: do we need to have any more discussion about scrolling the least amount?
<gregwhitworth> TabAtkins: that's a separate thing to consider for scroll snap
<gregwhitworth> astearns: 1. The argument at the end should be dropped - sounds like they should not be
<gregwhitworth> 2. Should scroll snap win when there are no args in SIV - that sounds like there are no arguments against that
<gregwhitworth> fantasai: the two specs conflict
<gregwhitworth> fantasai: the OM spec doesn't ack scroll snap
<dbaron> there seem to be different behaviors for: various a11y things, going to named anchors, focus changes, caret position changes, dom apis to scroll element into view, and some other things (e.g., things related to form autofill popups or devtools)
<gregwhitworth> astearns: does anyone have any objection to making those changes
<gregwhitworth> RESOLVED: We will make the changes to specs as necessary to ack scroll snap when no arguments are provided to ScrollIntoView
<gregwhitworth> fantasai: anything that does scrolling needs to be evaluated
<gregwhitworth> astearns: any objections with not mucking with the ScrollIntoView() args?
<gregwhitworth> RESOLVED: To keep scrollIntoView() options as they are