Re: [csswg-drafts] [cssom-view-1] Differentiate programmatic directional scrolls from absolute scrolls (#12394)

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`

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


-- 
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/12394#issuecomment-3200604694 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Tuesday, 19 August 2025 12:42:45 UTC