- From: CSS Meeting Bot via GitHub <noreply@w3.org>
- Date: Wed, 11 Mar 2026 16:55:39 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[cssom-view] How to fulfill programmatic scroll promises?`, and agreed to the following: * `RESOLVED: Rob update the spec per his comment. Can dig into particular details as needed.` <details><summary>The full IRC log of that discussion</summary> <TabAtkins> flackr: we're resolved to have promises when you invoke scrolling methods<br> <TabAtkins> flackr: there were open questions about two main things, I think<br> <TabAtkins> flackr: one, in the original resolution we discussed having a way to tell the difference between a scroll that was interrupted and one that was completed. but that didn't make it into the spec text. we'd like to resolve the promise with a scroll result dictionary that tells the status<br> <TabAtkins> flackr: happy to bikeshed on the property for that<br> <TabAtkins> flackr: two, how to handle interruption of particular promises<br> <TabAtkins> flackr: points 2 and 3 in the issue<br> <TabAtkins> flackr: for 2, we expect only scrolls that interrupt a particular scroller will resolve the promise for that scroller<br> <TabAtkins> flackr: for 3, a scroll promise for scrollIntoView is effectively like waiting for all the affected scrollers. so until all the scrolls are interrupted or completed it doesn't resolve. and when they are all resolved, we resolve the whole thing<br> <smfr> q+<br> <TabAtkins> q+<br> <astearns> ack smfr<br> <TabAtkins> smfr: i'm curious about scrollIntoView. on a nested scroller it might not scroll enclosing scrollers if they don't need to<br> <TabAtkins> smfr: so do they interrupt an ancestor scroll only *if* they need to change a position?<br> <TabAtkins> flackr: the intention is to track what the browser actually does with the scroll<br> <TabAtkins> flackr: so if you have an ongoing smooth scroll and you call scrollIntoView(), does it cancel the smooth scroll? If so, it should cancel the promise too<br> <TabAtkins> flackr: I believe it *should* cancel, you presumably want to stop the earlier scroll to honor the scrollIntoView request<br> <TabAtkins> smfr: seems reasonable<br> <ydaniv> q+<br> <TabAtkins> smfr: there's also a lot of logic in webkit to coalesce user scrolls<br> <TabAtkins> smfr: if you scroll with smooth and and then without smooth, the second clobbers. I guess that means the first is canceled<br> <TabAtkins> flackr: yes<br> <astearns> ack TabAtkins<br> <fantasai> TabAtkins: For scroll-into-view, are you planning to re-use existing promise machinery?<br> <fantasai> TabAtkins: so will get back array of scroll results, or something else?<br> <smfr> q+<br> <fantasai> flackr: Was thinking to have a single scroll result. Hard for developers to reason about an array<br> <fantasai> flackr: [missed]<br> <astearns> ack ydaniv<br> <TabAtkins> ydaniv: regarding rejecting the promise, a canceled scroll. should be consistent with how we reject on canceled animations, with aborterror<br> <TabAtkins> flackr: therew was a prior discussion on scroll promises where we're not rejecting them. it would raise compat issues due to a surprising new error<br> <TabAtkins> flackr: so we instead resolve successfully, with a result that says it's interrupted, not a rejection<br> <astearns> ack smfr<br> <TabAtkins> (agree, it's fine for this to be a non-exceptional result)<br> <TabAtkins> smfr: just checking, scrollIntoView() returns a promise?<br> <TabAtkins> flackr: yes<br> <TabAtkins> smfr: what about implicit ones like focus?<br> <TabAtkins> flackr: the dev can't get at that promise<br> <TabAtkins> smfr: okay, so you're not planning on exposing the indirect scrolls' promises<br> <TabAtkins> flackr: no<br> <TabAtkins> smfr: that's fine<br> <TabAtkins> astearns: are we going to resolve to let Rob do what he thinks is reasonable here, or be more explicit?<br> <emilio> More explicit is better :)<br> <emilio> But what rob said sounds good<br> <fantasai> TabAtkins: Everything Rob said sounds good, so happy to defer to him<br> <fantasai> PROPOSED: flackr to update spec with what he's outlined<br> <TabAtkins> RESOLVED: Rob update the spec per his comment. Can dig into particular details as needed.<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/12495#issuecomment-4040657058 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 11 March 2026 16:55:40 UTC