Re: [csswg-drafts] [cssom-view] Consider making scroll methods return promises

The Working Group just discussed `Consider making scroll methods return promises`, and agreed to the following:

* `RESOLVED: add returning a promise to all scroll functions`

<details><summary>The full IRC log of that discussion</summary>
&lt;dael> Topic: Consider making scroll methods return promises<br>
&lt;dael> github: https://github.com/w3c/csswg-drafts/issues/1562<br>
&lt;dael> TabAtkins: Right now all scrolling methods are void, return undefined. When they were instant that wwas fine. Now that there's smoothe scrolling it may be worthwhile to have something tell you when it's finished. Someone suggested that scroll methods return promises.<br>
&lt;dael> TabAtkins: I don't think they would ever fail.<br>
&lt;dael> TabAtkins: Upgrading void methods into promise returning is a standard way to do this and should be compat. As long as there's no impl I'd like to add.<br>
&lt;dael> Rossen_: Defined behavior for overlapping scroll timelines?<br>
&lt;dael> TabAtkins: Don't know, use case?<br>
&lt;dael> Rossen_: You want to impl your own overscroll behavior for a spring effect. When your scroll is complete you want to scroll down and back. I can see someone doing that. So I start a scroll for something fairly long in time and then I'll wait for the promise to do the little overscroll. But another scroll in the opposite dir happens.<br>
&lt;dael> TabAtkins: If a scroll is started and interrupted it's done and you fulfill promise.<br>
&lt;dael> Rossen_: So inturupt or complete fulfils.<br>
&lt;dael> TabAtkins: We only reject promises on errors and there's no sense the scroll throws an error<br>
&lt;dael> dbaron: You might want data on if inturpt.<br>
&lt;dael> TabAtkins: Agree. Should fulfill, but argument should give data<br>
&lt;dael> majidvp: Can you not read scroll offset with actual offset and it means inturrupt?<br>
&lt;dael> TabAtkins: No because you're interrupted mid-way. Using that as a method an interrupted will be forever pending unless you hit it by luck.<br>
&lt;dael> dbaron: I think it's an alternative to data, not tot he promise.<br>
&lt;dael> dbaron: That said, I think there are a bunch of scrolling operations where you don't know destination offset. YOu can cause scroll by page and you don't know pixel.<br>
&lt;dael> TabAtkins: And scroll into view is at least difficutl to cal<br>
&lt;dael> Rossen_: I would want to have something cleaner and richer for hints. When you intersect this with scroll snapping and you stop for a different reason...if you scroll by and need to scroll up more because a scroll snap has a mandatory scroll you'll overscroll based on target.<br>
&lt;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.<br>
&lt;dael> TabAtkins: I can see fulfill with an object that's an enum of completed or interrupted or something like that.<br>
&lt;dael> AmeliaBR: I suggest looking at web animations spec. Smoothe scroll is a type of animation and web animation uses lots of promises and chaining things like web animation after a complete smooth scroll. Compat here is useful.<br>
&lt;dael> TabAtkins: Agree. I didn't know about that but I will take a look at it.<br>
&lt;dael> majidvp: Another case is a scroll-into-view where we scroll multi scrollers and we need details on when we fulfill. I imagine after all scrolls are complete.<br>
&lt;dael> TabAtkins: Yes, if you have 2 nested scrollers inner is a bit and outer is a lot so inner completes fast. Makes sense. Good detail.<br>
&lt;dael> Rossen_: Is there a reason we wouldn't want this as an event that you can subscribe instead of adding promises to all scroll functions?<br>
&lt;AmeliaBR> s/promises and chaining/promises and I could see a use case for chaining/<br>
&lt;dbaron> https://developer.mozilla.org/en-US/docs/Web/Events/scroll<br>
&lt;dael> TabAtkins: Possibly. But if you only care about a given scroll you have to subscribe and then unsubscribe. Also there may be another scroll and you might get the wrong one. Event is useful, but doesn't do the use case of I want to know when this scroll is complete.<br>
&lt;dael> Rossen_: Okay. Makes sense.<br>
&lt;dael> Rossen_: Sounds like a feature that merits addition of promise. Likely details to work out.<br>
&lt;dael> Rossen_: Additional comments or objections to add returning a promise from all scroll functions?<br>
&lt;dael> RESOLVED: add returning a promise to all scroll functions<br>
</details>


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

Received on Wednesday, 16 May 2018 16:41:45 UTC