- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 21 Dec 2022 18:03:18 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[scroll-animations] Behavior of scroll-linked animations in the first frame`, and agreed to the following: * `RESOLVED: Newly-discovered timelines trigger a new layout at the RO portion fo the frame lifecycle. (Maybe other times, tbd.)` <details><summary>The full IRC log of that discussion</summary> <TabAtkins> flackr: So SLA are based on layout of elements<br> <TabAtkins> flackr: but they can be discovered during style parse<br> <TabAtkins> flackr: and SLA can affect the style and layout<br> <TabAtkins> flackr: So we need to define the interaction during the initial lifecycle update<br> <TabAtkins> flackr: I have a PR that updates similarly to RO - after doing style and layout, you can do one more loop to handle SLA you've found. Unlike RO it's bounded to a single loop, and it runs in parallel with ResizeObserver so it's not an additional loop on top of that.<br> <TabAtkins> flackr: Anders prefers the approach where JS-constructred scroll timelines, we also don't freshen their time until after style and layout, so authors can observe they don't have a time initially, but after the style/layout update we'd repeat with times. I don't have a strong pref so I'm okay with that unless people feel we should force a style/layout immediately<br> <TabAtkins> +1<br> <TabAtkins> emilio: What are implications of not doing this second pass?<br> <TabAtkins> emilio: Is it just we don't start a timeline bc theres no scroller, so they see it next frame?<br> <TabAtkins> flackr: Yes, the first frame is incorrect because no SLA is done. Often completely missing th eanimation style, which I think is unacceptable due to likely flickering<br> <TabAtkins> smfr: Is this unique to SLA becuase the scroll position is input and you don't know it until layout?<br> <TabAtkins> flackr: No... sorta<br> <TabAtkins> smfr: Unsure why it's not a problem with nromal animations<br> <TabAtkins> flackr: We update animations at the point they're discovered-- you're right, determining the timeline time requires a layout update<br> <TabAtkins> emilio: And when are you proposing to run the second pass? unconditionally, or only when you discover new timeline aniamtions?<br> <TabAtkins> flackr: ONly when discovering new animations, adn only once per lifecycle update<br> <TabAtkins> flackr: We can define it to either be animations discovered during the style/layout cycle - idea is we'd have a flag on these timelines and check if it's a non-empty set<br> <TabAtkins> emilio: Do we want to do it with script-triggered udpates, or more like RO where it's only [...] loop?<br> <TabAtkins> flackr: My proposal is to only do RO<br> <TabAtkins> emilio: I think that's slightly better<br> <TabAtkins> emilio: We have some things that do similar, like focus fixup and stuff<br> <TabAtkins> emilio: Just we ahve several things that can trigger multiple passes and need to make sure they're properly defined<br> <TabAtkins> emilio: what happens if you do two script queries?<br> <TabAtkins> emilio: You ahve a pending style change, do gBCR(), and that discovers new timelines<br> <TabAtkins> emilio: Would a second gBCR() return a different result?<br> <ydaniv> q+<br> <TabAtkins> flackr: By spec, no. SCroll timelines only update their time at the start of the frame and during this discovery, at RO time.<br> <TabAtkins> emilio: Okay as long as this doesn't make us return something inconsistent during a single frame i think that's fine<br> <TabAtkins> ydaniv: The point where times are incorrect is just when the page loads and there's no scroll, right?<br> <TabAtkins> flackr: This can happen for any inserted content<br> <TabAtkins> flackr: So if you insert a scroller that's not laid out yet, it'll happen too<br> <TabAtkins> emilio: Or if display property changes<br> <TabAtkins> ydaniv: so it might require devs to have something like "always pull once on rAF" to make sure they have the correct time?<br> <TabAtkins> flackr: If you waited for rAF... yeah you'd have to poll it once<br> <smfr> s/pull/poll/ ?<br> <Rossen_> ack ydaniv<br> <ydaniv> poll (:<br> <TabAtkins> flackr: because the scroll timeline would not have determiend its correct time yet<br> <TabAtkins> flackr: It will be the time the frame is produced, but rAF happens before that<br> <TabAtkins> ydaniv: might be a good idea to prevent - sounds like a footgun to me if any change might get us into a wrong current timeline<br> <TabAtkins> flackr: This goes back to emilio's comment about JS-forced updates<br> <TabAtkins> flackr: If we decided it did, it would give you the correct result in these cases, but it also makes it a larger potential perf footgun<br> <TabAtkins> flackr: My argument for why this is okay is that this is consistent with RO - it'll be wrong at the same times.<br> <TabAtkins> flackr: So not inventing a new footgun, just following the path of an existing one.<br> <TabAtkins> emilio: main concern is that RO... you can't query RO arbitrarily, only get your callback invoked<br> <TabAtkins> emilio: So if there are use-cases to get the right answer from script, that might be slightly preferable<br> <TabAtkins> emilio: But my pref is also to have a well-defined time during the frame that does the right thing<br> <TabAtkins> Rossen_: Given we're over time, we can take this to the issue or do you have a scoped part of this resolution to take up?<br> <TabAtkins> flackr: I think we can resolve that we will repeat the layout for newly-discovered timelines in the lifecycle, but leave to the side whether forced style updates will do this as well<br> <TabAtkins> Rossen_: Objections to the scoped reoslution?<br> <TabAtkins> emilio: works for me<br> <TabAtkins> RESOLVED: Newly-discovered timelines trigger a new layout at the RO portion fo the frame lifecycle. (Maybe other times, tbd.)<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/5261#issuecomment-1361776886 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 21 December 2022 18:03:20 UTC