Re: [csswg-drafts] [cssom-view-1] Scroll methods in Element and Window return Promises (#12355)

> > In the discussion we talked about the argument to the promise being an object which would tell the developer the result of the scroll, e.g. to know if it was cancelled / interrupted as was brought up a few times as a common thing to need to know.
> 
> That's correct. The problem is that it not yet defined how the promise would be resolved to mark scroll completion vs interruption. I can update this PR to resolve with a `true` to mark completion and `false` "otherwise"

I would suggest that it not resolve with a boolean but rather with an object, e.g. define a ScrollResult, that we can add to if we later discover that we want to pass additional information. That said, having a boolean there and opening an issue for whether we should change it is a good thing.

> but I am hesitant because of a few reasons:
> 
> 1. It is perhaps not okay to add normative things w/o discussion, right?  E.g. we don't know if we should use a Boolean here vs an enum.

This is normal, the resolution we have is effectively to pursue specifying and prototyping the feature. It's fully expected that in the process of doing this the implementor may make some opinionated decisions in writing the spec and bring those decisions back to the working group. Having something implemented will make it easier to have examples where we can show how the value would be used. 

> 2. What does that "otherwise" mean to be precise?  Does one programmatic scroll request interrupt all pending promises?  Or only the pending ones for the same scroller?

It would be valuable to define this to mean what we think makes the most sense. IMO this is anything that prevents completing the original scroll request. A programmatic scroll request on an unrelated scroller probably should not interrupt it. A scroll on the same scroller would mean that we are no longer actively scrolling to the originally requested location.

> 3. We _may_ need additional text in the current scroll algorithms to "collect" pending scrolling requests.  To me a follow-up PR after this one seems cleaner.
> 
> I am proposing to land this PR as "closing" #1562, staring a new spec issue to discuss 1+2 above, and then hash out 3 in the PR for that new issue.

It is better to have the boolean there and to add an inline issue in the spec that says we need to agree on the type and when it is successful / unsuccessful. This shows spec readers that the API is likely to change, demonstrates the use case and can even point to the issue for people to add their feedback. Here's an example from css-images-5: https://github.com/w3c/csswg-drafts/blob/b5312ce985daef0e0a2f070130472d58892512cc/css-images-5/Overview.bs#L55

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


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

Received on Thursday, 10 July 2025 16:09:42 UTC