- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Mon, 16 Sep 2019 04:36:42 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `Scroll Anchoring`. <details><summary>The full IRC log of that discussion</summary> <fantasai> Topic: Scroll Anchoring<br> <myles> emilio: Is this microphone on?<br> <astearns> github: https://github.com/w3c/csswg-drafts/issues/4239<br> <myles> emilio: The spec sepcifices a few situations where if a given style chagne happens, you don't apply any scrolling adjustments in thecontainer. This is done to avoid manual sticky effects. This is done to prevent them to breaking.<br> <myles> emilio: even with this heuristic, we have still found either broken pages that for example, once you scroll to the bottom you can't scroll back up, or they do things that in the regular cases you want scroll anchoring to apply, or pages that get burn a bunch of CPU in infinite scroll event listeners because scrolling triggers more scrolling listeners. This is possible in both chrome and firefox.<br> <myles> emilio: What I did to fix it is to never apply any adjustment for scroll anchoring if you are processing a scroll event listener for htat node.<br> <myles> emilio: When you fire the scroll event listener, you remember the target of the event, and if the element matches, you don't re-fire<br> <myles> emilio: this is mainly to prevent bad scroll events. I'm just interested in feedback from implementors<br> <myles> <missed>: Chrome implementors are in agreement<br> <myles> emilio: Ian Scopes is no longer working on this<br> <myles> eae: No one is working on it now<br> <myles> chrishtr: What about it are you itnerested in?<br> <heycam> s/Scopes/Skobes/<br> <TabAtkins> s/Ian Skobes/Steve Kobes/<br> <heycam> s/Ian Skobes/Steve Kobes/<br> <myles> emilio: scroll anchoring restores positions so the offset relative to the scroller is preserved. There are cases where that's undesirable, or break,s if the page is doing stuff like scroll effects. So if you change a static position thing to be below, the anchor node goes up, and then you need another scroll event, and the page realizes that the thing is no longer sticking to the viewport, et.c<br> <myles> emilio: Chrome fixed this by, when changing from in-flow to out-of-flow, don't do the scroll adjustment.<br> <myles> eae: Yes, that's how it works today.<br> <myles> emilio: Even with this heuristic, pages burn CPU by firing infinite scroll events, which is not great. Pages that get locked up on scrolling if you get to the bottom.<br> <myles> emilio: Those cases are not easy to identify generically, because a particular style change happened. The style didn't change, it's a case that scrolling wants to fix. The only thing that's happening is a scroll event listener. Instead of Chrome's heuristics, it would be simpler to not adjust scroll offsets if you're doing scroll anchoring if it's happening during a scroll event listener<br> <myles> eae: We tried that and rejected it, but I don't remember why. Our current behavior is the one that worked the best in the best number of cases.<br> <myles> chrishtr: If something dirties layout that changes scroll offset in a scroll event listener... you want that readback to not take into account anchoring?<br> <myles> emilio: Yes.<br> <myles> eae: That sounds reasonable. If we can't figure out why we can't do that, we should try it agian and see if it's workable<br> <myles> chrishtr: Is the code doing this loop synchronously?<br> <myles> emilio: I know pages in Chrome that burn CPU because the scroll offset keeps changing<br> <myles> emilio: It changes back and forth, and triggers two scroll events<br> <myles> eae: We try to detect that and short-circuit if we go back and forth more than a few times, but it may not always work.<br> <myles> atotic: If you have feedbakc, that would be great, because we're using a heuristic now<br> <myles> chrishtr: If layout is dirtied and syncrhonously read back in teh same handler .... what does reading it back have to do with ....<br> <smfr> q+<br> <myles> emilio: While the page is measurin gsomething, so if you insert something, measure it, then remove it, that measurement triggers a scrolloffset update. If you measure again, you'd get the opposite scrolloffset update. That needs to update the scroll offset<br> <myles> chrishtr: Are you proposing that forced layouts don't do this?<br> <astearns> ack smfr<br> <myles> emilio: I'm proposing that Scroll offsets don't do anchoring<br> <myles> smfr: Is the time that scroll anchoring is applied defined in terms of HTML5 event loop.<br> <myles> emilio: no. This is an issue. Mostly for this heuristic, if we can remove it, we don't need that, but the main issue is that it's udnefined when this calculation occurs. We are aware of this.<br> <myles> emilio: Scroll anchoring runs after updating styles but before updating layout.<br> <myles> emilio: In order to have hte tree in the state you want it to, you have to run it every layout<br> <myles> smfr: Scrolls triggered by scroll anchoring fire scroll events?<br> <myles> emilio: yes<br> <myles> smfr: that's necessary?<br> <myles> smfr: yes<br> <myles> emilio: yes<br> <myles> chrishtr: What you're proposing is worth investigating. Chrome can invest engineers to page back in our history here.<br> <myles> eae: If you're impelmenting now, we shoudl revesolve this<br> <myles> astearns: Do we need a resolution? Should we change the spec?<br> <myles> emilio: These heuristics are still implemented in Chrome and Firefox. I want to remove them in Firefox.<br> <myles> emilio: I don't see any reason to remove them now.<br> <myles> chrishtr: We need more investigation.<br> <smfr> q+<br> <myles> dbaron: You talked about, in a certain case, not doing scroll anchoring. Are there are reasons to record but defer the adjustment until later?<br> <myles> dbaron: I haven't thought about it that much. It feels like not doing it sometimes runs the risk of dropping something that you might have wanted<br> <myles> emilio: That may be another approach. And then we can move it to the "update the rendering steps" in HTML5<br> <myles> emilio: The main reason case where you don't want scroll anchroning adjustments is when you're reacting to scroll events yourself<br> <myles> atotic: Part of the problem in Chrome is that, by the time we're in layout, we don't know which handler cuased it. If you can make it work in Firefox, maybe it's possible in Chrome. But we don't have anyone working on it<br> <myles> emilio: Yeah, but you can set a flag....<br> <myles> atotic: We'd have to pass the flag around....<br> <myles> emilio: Yeah, it's possible<br> <myles> smfr: High level comment about spec: The spec is unusual because it describes a behavior which is making up for the fact that web developers often make mistakes and cause scroll jank. With specs like this, we need to be careful. We risk a scenario where some UAs implement this, papering over the bad stuff, and authors may only test in UAs that implemented it. In other UAs whcih haven't implemented in it, there's a lot more scroll jank than the other UAs. This<br> <myles> spec increases the disparity between user agents. We need to be careful not to make too many of these in the future<br> <myles> astearns: There are lots of CSS features which are improving the rendering of a page. If a browser doens't implement that feature, that browser will look worse.<br> <myles> smfr: It's invisible to authors. The browser jsut fixes up content. It's easy for authors to create scroll-jank if they don't test in chrome<br> <myles> iank_: there is precidence. Text autosizing behavior is automatic.<br> <myles> astearns: Can we move on?<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/4239#issuecomment-531638186 using your GitHub account
Received on Monday, 16 September 2019 04:36:44 UTC