[cssom-view-1] Differentiate programmatic directional scrolls from absolute scrolls

[flackr]

The cssom-view-1 spec currently specifies both scrollTo and scrollBy as if they both invoke the scroll method with the left and top set accordingly. However, I think that we should differentiate these APIs as relative directional scrolls and absolute scrolls as far as they affect several other APIs. The legacy scrollLeft and scrollTop should probably be treated as absolute scrolls as that is usually what they are used for.

Absolute scrolls:

• If interrupting an ongoing scroll, use the specified offset exactly.
• Are treated as intended end position scrolls by scroll snap: https://www.w3.org/TR/css-scroll-snap-1/#scroll-types
• Don't set the last scroll direction for state queries [css-ui][selectors][mediaqueries] Expose current scrolling direction #6400

Relative / directional scrolls:

• If interrupting an ongoing scroll, add their relative offset to the interrupted scroll position. E.g. scrollBy(0, 10) scroll always scroll 10px down rather than potentially scrolling up if there was an ongoing fling scroll.
• Are treated as intended direction and end position by scroll snap: https://www.w3.org/TR/css-scroll-snap-1/#scroll-types
• Change the last scroll direction for state queries [css-ui][selectors][mediaqueries] Expose current scrolling direction #6400

Proposed resolution:
Define a consistent distinction between absolute scrolls and relative scrolls that can be implemented and shared across these affected specs.
Absolute scrolls: scrollTo, scrollLeft, scrollTop, scrollIntoView, anchor fragment scrolls, scroll anchoring, find in page scrolls, focus scroll into view, scroll thumb dragging?
Relative scrolls: scrollBy, arrow key, page up/down, spacebar, home/end?, scrollbar track clicks, scrollbar buttons

Any other ways of scrolling we need to categorize?

@tabatkins

[skobes-chromium]

FYI - scroll anchoring and clamping have "relative" behavior with respect to ongoing scrolls (see ScrollAnimator::AdjustAnimation), but they probably should not set the last scroll direction for state queries. So this feels like a third category (browser-triggered scrolls?)

[tabatkins]

Yeah, "relative" isn't the term for that category; it's "directional" that you want. Scroll anchoring/clamping maybe lack both directionality and position, in the way Scroll Snap defines those terms, so we could make a fourth category explicit there of scrolls that, while they adjust scroll offsets, are designed to maintain a "stasis" rather than actually do a scroll.

[flackr]

we could make a fourth category

How did we get to fourth?

I think scroll anchoring probably is a third category of effectively non-scrolling or internal scrolling, as @tabatkins mentioned it's not really meant to be noticed by the user as a scroll. Alternately we could leave it as a special case and call out that it has elements of relative (combines with ongoing scrolls without interrupting) and absolute (doesn't infer last direction, and while it usually shouldn't change snap selection when it does we would use the absolute strategy rather than relative).

[tabatkins]

There's three categories in the spec! Directional, positional, and direction+positional. Flings are the third, as they have a direction and a desired endpoint, while arrow keys are just directional.

[flackr]

There's three categories in the spec! Directional, positional, and direction+positional. Flings are the third, as they have a direction and a desired endpoint, while arrow keys are just directional.

Ah right. I recently refactored this code as directional and directional + positional was practically the same case, to make them the same case with a few additional args set when doing a fling or paging operation. Semantically a fling or page down operation is not an absolute position at all it is just directional with some minimum / expected displacements - but it is notably not an expected endpoint, it is still a relative distance from the start.

[flackr]

So I propose that for simplicity, we have three categories:

• Absolute target scrolls
• Directional scrolls (can have preferred displacement to handle fling / paging).
• Stationary scrolls (special case for anchor positioning, and potentially other future cases where we technically change offset but don't mean to actually visually scroll).

[css-meeting-bot]

The CSS Working Group just discussed [cssom-view-1] Differentiate programmatic directional scrolls from absolute scrolls, and agreed to the following:

• RESOLVED: Accept the distinction between relative / absolute / stationary scrolls with details to be reviewed

The full IRC log of that discussion

<emilio> scribe+
<emilio> flackr: the CSSOM-view spec doesn't distinguish scrollTo / scrollBy
<emilio> ... however the terms imply that some of them are relative and some absolute
<emilio> ... I think we should encode this in the spec meaningfully
<emilio> q+
<emilio> ... it applies to several scrolling-related actions
<emilio> ... e.g. the way scroll-snap selects snap points depends on the current scroll direction
<emilio> ... while if you have an absolute scroll you can just select the closest snap point
<emilio> ... there's also scroll anchoring
<emilio> ... which isn't scrolling from the user's POV
<emilio> ... I called that a "stationary scroll"
<emilio> ... it wouldn't interrupt ongoing fling operation
<emilio> ... doesn't change the last scroll direction for the proposed scroll-state query either
<emilio> ... high level point is that we have these three conceptual types of scroll
<emilio> ... and we should define them properly rather than making each spec work around it like snap
<emilio> e.g. scrollBy won't scroll backwards if you have a fling
<emilio> astearns: is this a normative spec change?
<emilio> flackr: there are a few differences
<emilio> e.g. scrollBy might behave differently if you have a fling that's past the target
<emilio> ... right now it can scroll backwards
<emilio> ... Are the user facing changes known?
<emilio> s/.../astearns
<emilio> flackr: I suspect some of them will be discovered
<emilio> ... I don't expect this to affect most pages
<emilio> ... bigger change is scroll state queries
<emilio> ... it didn't feel like last scroll direction should be affected by scroll anchoring
<emilio> ... I'd argue absolute scrolls shouldn't either
<astearns> ack emilio
<ydaniv> scribe+
<ydaniv> emilio: in general big +1
<emilio> Gecko has https://searchfox.org/mozilla-central/rev/270c20e4b063d80ce71f029b4adc4ba03a12edc0/layout/generic/ScrollOrigin.h#15
<ydaniv> ... this scroll origin enum to distinguish stuff
<ydaniv> ... I'd argue that some of the absolute scorll that we want to change
<ydaniv> ... implement using absolute scrolling
<ydaniv> flackr: my argument is that use of scroll is absolute behavior, they should use the scrollBy API
<ydaniv> emilio: OK, agree
<ydaniv> ... there's also scroll position restoration, to we want to treat that the same?
<ydaniv> flackr: yeah
<ydaniv> emilio: wonder if those should be grouped the same
<ydaniv> ... it's restoring your last visible position
<ydaniv> ... these APIs already behave differently
<ydaniv> ... with smooth scroll it won't jump etc.
<ydaniv> ... not important in the spec, but sounds great
<ydaniv> astearns: other comments?
<emilio> s/important/encoded
<emilio> astearns: I'd like a report of the implications you've found
<emilio> ... as in here's what has been defined in the spec
<emilio> ... so they can be reviewed
<emilio> ... so proposed resolution is yes, with some of the details TBD
<emilio> RESOLVED: Accept the distinction between relative / absolute / stationary scrolls with details to be reviewed