Re: [csswg-drafts] [cssom-view] How to fulfill programmatic scroll promises? (#12495)

> This is a follow-up issue for [#1562](https://github.com/w3c/csswg-drafts/issues/1562) where we already have the resolution that programmatic scroll methods in `Element` and `Window` would return Promises, and that for backward compatibility those Promises won't ever be rejected. Certain details of those Promises still need attention:
> 
> 1. How will we fulfill the Promises to mark scroll completion vs interruption vs error?  The [PR](https://github.com/w3c/csswg-drafts/pull/12355) for the issue above minimally covers this with Boolean values (true for completion and false otherwise).  Perhaps an enum would be better?

Fulfilling with an object would be the most future proof. We could add other members to that object in the future if there is additional information about the completion of a scroll that might be useful.

E.g. Promise<ScrollCompletion> where for now ScrollCompletion = { interrupted: boolean }

Perhaps we should also consider whether we should provide information in this structure about the multiple scrolls that you get with scrollIntoView (could be added later as needed) or scrollIntoView could return an array of promises for each of the ongoing scrolls (might be an awkward api, you'd regularly want to use Promise.all to wait for all of them anyways).

> 2. Does one programmatic scroll request interrupt all pending promises? Or only the pending ones for the same scroller?  The PR above assumes the latter.  Is this the best choice?

This should mirror the actual underlying scrolling going on. If the previously requested scrolling still has ongoing updates, then we should not resolve until those updates are completed. I.e. only pending promises for interrupted scrolls should be resolved.

> 3. `Element.scrollIntoView()` affects the ancestor scrollers of the element.  How will a programmatic scroll request on any of those ancestors interrupt the first request?  Synchronously at the time of the second request (no matter which of those ancestors are scrolling at the time of the second request)?  Or asynchronously only if the both requests happen to be scrolling a common element at the same moment?

This should be the same as point 2 above. The scrollIntoView promise should resolve when all of its requested scrolling is either  completed or interrupted. If the second scrollIntoView call interrupts all of the scrolling from the first, then I would expect the first promise to resolve immediately with an interrupted status.

-- 
GitHub Notification of comment by flackr
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/12495#issuecomment-3328299259 using your GitHub account


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

Received on Wednesday, 24 September 2025 12:59:19 UTC