- From: Robert Flack via GitHub <noreply@w3.org>
- Date: Tue, 02 Sep 2025 22:45:20 +0000
- To: public-css-archive@w3.org
> > The boolean stuff is rather confusing. Do we want / is it worth resolving differently for completion vs interruption? Can't stuff technically scroll after the UA resolves the promise, kinda defeating the point of it? > > @emilio I agree the [original resolution](https://github.com/w3c/csswg-drafts/issues/1562) does not include such details, and in our first patch we had the IDL type `Promise<undefined>`. But we found the spec language "resolve a Promise with true/false" far more expressive than "resolve a Promise (with nothing)". During the discussion in which we took the resolution, this was raised as an important point, from https://github.com/w3c/csswg-drafts/issues/1562#issuecomment-389586317: > <dael> Rossen_: Meta point, I don't think anyone objects use case of promise pattern. I think the addition to this is adding some data that describes how this was fulfilled. > <dael> TabAtkins: I can see fulfill with an object that's an enum of completed or interrupted or something like that. > Sure, but promise resolution is async and, in your example scrolled is actually not really whether something scrolled, right? E.g a smooth scroll interrupted by the user will resolve with false but it's not clear what behavior the developer would want... It's more like completedScroll, and it seems rather subtle / hard to use right in presence of user scrolls or what not, right? If a user scrolls before we reach the target then it immediately resolves with false. This is because while we have completed the scrolling that is going to happen for that requested scroll, it was interrupted. In the use cases in the OP it was suggested that developers would use this for things like: > it would be even more useful if scroll method returned a promise so the developer could wait until the scroll finishes before moving on to next set of tasks for things like triggering analytics data after scrolling, unloading resources when they've been scrolled out of view, parallax scrolling, etc. Having this completion state allows the developer to do something different for interrupted scrolls without needing to read back the scroll offset and try to figure out whether it was interrupted which can be hard when using scrollIntoView to determine exactly what offset you should expect to scroll to. Personally, I don't think it should be a boolean but rather a dictionary with an enum so that we could add additional arguments if we think of other things you might want to know about the completed scroll. -- GitHub Notification of comment by flackr Please view or discuss this issue at https://github.com/w3c/csswg-drafts/pull/12355#issuecomment-3247035100 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Tuesday, 2 September 2025 22:45:22 UTC