W3C home > Mailing lists > Public > public-css-archive@w3.org > June 2020

Re: [csswg-drafts] [scroll-animations] Behavior of scroll-linked animations in the first frame (#5261)

From: andruud via GitHub <sysbot+gh@w3.org>
Date: Fri, 26 Jun 2020 10:23:43 +0000
To: public-css-archive@w3.org
Message-ID: <issue_comment.created-650106577-1593167022-sysbot+gh@w3.org>
OK, sounds like there's support for trying (2) (possibly for lack of a better option).

> What's the definition of a ScrollTimeline being created in the current cycle for animation-timeline/@scroll-timeline? Is it that the computed value of animation-timeline changes and that the name matches a @scroll-timeline with the source matching an element?

Yes, except the source doesn't necessarily have to match an element at that time. (And it doesn't have to be a response to a change in animation-timeline specifically. It could also happen e.g. if a `@scroll-timeline` is inserted.

> Would we ever need to have more than two passes?

I don't think so. I think we'll do at most one additional pass, and then if the source still lacks a layout box for whatever reason, then the timeline is just inactive that frame.

> Could we have a situation where animation-timeline flips back and forth for each style/layout pass?

I don't think so, but if we do at most one extra pass, it should anyway be fine?


More thinking out loud on approach (2):

 - This is not only a "first frame" problem, but can also happen e.g. if we already have an existing `@scroll-timeline` with some source `#foo` that initially doesn't exist, and then `#foo` appears at some time later. (And similar scenarios).
 - Hence we could possibly define the approach approximately like this: if, after style calculation, there's a timeline with a _source_ that's layout-dirty, do another pass. (With a max of one additional pass).
 - I would be super-sceptical to (2) if ResizeObserver didn't already do multiple passes. (So ... thank you ResizeObserver!)
 - I slightly wonder how sustainable it is to keep adding passes for new features, but at least our extra pass should be shareable with ResizeObserver passes (I think/hope). So at least it's not additive.
 - getComputedStyle would return the "wrong" result before the first frame has been run. I assume this must also be the case for some ResizeObserver scenarios.
 - My initial thought is that the JS API should behave the same way, just so we have less "unique" behaviors.
 - Watch out for features that deliberately leave the tree in a dirty state, e.g. display locking. (I don't remember the current name of this feature).

-- 
GitHub Notification of comment by andruud
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/5261#issuecomment-650106577 using your GitHub account
Received on Friday, 26 June 2020 10:23:46 UTC

This archive was generated by hypermail 2.4.0 : Tuesday, 19 October 2021 01:31:28 UTC