[scroll-animations-1] Define how the source member of a ScrollTimeline corresponding to a scroll() timeline is updated

[birtles]

https://drafts.csswg.org/scroll-animations-1/#dom-scrolltimelineoptions-source

I might be misunderstanding how all this works but if I define an anonymous scroll timeline in CSS using the scroll() notation, then inspect the corresponding Animation object's timeline I assume I can inspect the ScrollTimeline.source to see what element root or nearest resolved to.

If I then modify the CSS of an ancestor element such that root or nearest resolve to a different element, is the same ScrollTimeline object updated? If so do we need to specify a procedure for updating the source of a ScrollTimeline? Or is a new ScrollTimeline minted? In either case we'd need to define it because the result would be observable.

[fantasai]

This is a good question, and imho it would make the most sense to mint a new ScrollTimeline, because conceptually it's not the same timeline being referenced. @flackr ?

[bramus]

Hmm, tricky. I guess there’s something to say for both, but leaning towards updating only the source as it essentially still is the same scroll() definition.

[ydaniv]

Changing source will also change currentTime and may render the timeline active/inactive. Not sure I understand the specifics of minting a new ScrollTimeline, but we'll need to reflect more change than just the source.

[fantasai]

@bramus That also brings up the question of, if I have multiple scroll() functions and a named timeline all referencing the same scroll container, do they share the same identity?

[flackr]

FYI @kevers-google

In the implementation, we currently use the same timeline instance and it resolves the actual source and returns that from the instance - but it is impossible to construct a JS scroll timeline which refers to the nearest ancestor. From the JS side this doesn't seem too different from how animation timing is updated from CSS except when you updateTiming from the JS side overriding it. Each ScrollTimeline is currently a different instance, especially as different elements have different reference elements in the internal scroll timeline details. The owning element concept also feels similar: https://drafts.csswg.org/css-animations-2/#owning-element - an internal detail that affects the JS behavior but is not exposed.

[flackr]

My proposal would be that we spec the chromium behavior. That similar to an animation object, a timeline object is created for the element which defines it and that same object is used until an explicit style change causes us to create a new one.

The source is computed when you ask for it (like computed styles). Normally this occurs once per frame when we update the time but querying from script can result in freshening style and layout to determine the current source. Of course it may be more consistent if we allow the source to be stale just as the time returned is the one most recently used and just as the current time of an AnimationTimeline is the time when the current frame was generated - not the current time.

[css-meeting-bot]

The CSS Working Group just discussed [scroll-animations-1] Define how the `source` member of a `ScrollTimeline` corresponding to a `scroll()` timeline is updated, and agreed to the following:

• RESOLVED: Each anonymous scroll timeline is a different object. The source is updated at the same time as the currentTime.

The full IRC log of that discussion

<argyle> astearns: next.
<argyle> astearns: this is brians issue, rob
<argyle> astearns: this is brians issue, rob?
<argyle> flackr: so brian pointed out that since we have a programmatic api to access a scroll timeline source, and scroll timelines for that matter, it needs to be well defined when that changes and when it's created
<argyle> flackr: fantasia suggested having the scroll timeline change everytime the thing that would be the source changes, and having it be unique per source
<argyle> flackr: i suggested that we follow the current chrome implementation which is more closely aligned to animation objects, where the element holds a scroll timeline entry and internally it points to
<argyle> flackr: the source and updates that when queried or when generating new times
<argyle> flackr: as we have implemented right now
<argyle> fantasai: i'm not 100% clear on this. question is, if i have multiple references to the same scroll container scroll timeline, does that mean each reference is unique and i wouldnt be able to tell if they reference the same thing unless i reference the source values
<argyle> flackr: correct, have to compare the source.
<argyle> astearns: wolud you have to do to fiddle with the objects before you do the sourece comparison?
<argyle> flackr: depends, if we want to mimmick whats happening in computed style, then querying the source will calculate what would be the updated source
<argyle> flackr: if it's stale
<argyle> flackr: however, it's a bit odd that makes the sourece inconsistent with the time value, which is intentionally stale. kevin correct me there?
<argyle> kekvin ellis: timeline time would only be updated once with the frame. if the source changed, it would update to the next frame
<argyle> flackr: that's a good reason to either revisit the decision or leave the source stale. to be consistent.
<argyle> astearns: to be consistent with the time, only leave source stale until next frame
<argyle> flackr: yes
<argyle> fantasai: i think that makes sense for them to be in sync
<argyle> flackr: agree
<argyle> fantasai: not sure about unique identities per reference, but i just dont know which way makes mroe sense. happy to go with what other people think is the right thing to do
<argyle> flackr: they would be the same if they used a named timeline. but this is anonymous timelines, generated on the fly for that element, and it can change
<argyle> flackr: there'd be a lot of non trivial ocmplexity updating those if we needed them to be identity functions to the scroller. they'd also need idendity functions with all the args. which…
<argyle> flackr: and i think animations have set a precedent that is consistent with my proposal
<argyle> fantasai: ok
<argyle> astearns: other opinions?
<argyle> astearns: i'm fine resolving that the source is computed when you ask for it and it's updated at the same time as other data on the object
<argyle> astearns: any concerns?
<argyle> astearns: objections?
<flackr> Proposed resolution: Each anonymous scroll timeline is a different object. The source is updated at the same time as the currentTime.
<argyle> RESOLVED: Each anonymous scroll timeline is a different object. The source is updated at the same time as the currentTime.
<argyle> astearns: next thing we got…
<argyle> astearns: animation iteration count

[fantasai]

@flackr I committed fantasai@947f69b and filed #8541 as a PR because I wasn't quite sure what exactly I should be speccing. Please have a look, and if it looks good rebase+merge and close out this issue. :)

[flackr]

Fixed by #8541.