[scroll-animations] Broader scope of scroll timelines

From #7047, it might be worth looking into the ability to split the declaration of a timeline (together with its scoping) from its actual attachment to a scroll container.

This would allow authors, for example, to declare a name on a subtree and make it available to all descendants of that subtree, and attach it to a scroll container that is a descendant within the subtree. (At the top level, declaring the name on the root element would make it global.)

Maybe something like scroll-timeline-attachment: local | defer | ancestor | closest where:

local has the current behavior of binding the name to this element’s scroll container
defer declares and scopes the name, but does not bind it to a scroll container
ancestor looks up the ancestor chain for a matching timeline name and attaches to that instance; failing a match, declares it locally
closest looks back up the tree including previous siblings for a matching timeline name (same lookup as animation-timeline), and attaches to the first matching instance; failing a match, declares it locally

The CSS Working Group just discussed scope of named timelines.

The full IRC log of that discussion

<TabAtkins> Topic: scope of named timelines
<TabAtkins> github: https://github.com//issues/7047
<fantasai> github: https://github.com//issues/7047#issuecomment-1239820755
<TabAtkins> fantasai: we talked about the scop eand came up with a default answer
<TabAtkins> fantasai: also what we might do to give power to people who want to do something more far-ranging than just "prev sibling" or "ancestor"
<TabAtkins> fantasai: so i came up with a suggestion to declare a timeline name but not attach it to a scroll container, and then attach it to one in the sibling/descendants
<TabAtkins> fantasai: suggestion is a property called scroll-timeline-attachment
<TabAtkins> 'local' is the default, binds to the element you're on
<TabAtkins> 'defer' will declare the name, but attach it to somethign else
<TabAtkins> fantasai: And another element can say "attach me to the timeline" of a given name
<TabAtkins> fantasai: so if i want a global scope
<TabAtkins> fantasai: can se the scroll-timeline-name:foo on the root , and scroll-timeline-attachment:defer
<TabAtkins> then on something else in the tree set scroll-timeline-name:foo and scroll-timeline-attachment: ancestor
<TabAtkins> fantasai: and it'll attach to that timeline scoped to the root
<TabAtkins> fantasai: i'm ambivalent about putting this in current spec, but wanted opinions on idea
<flackr> q+
<TabAtkins> zakim, open queue
<Zakim> ok, TabAtkins, the speaker queue is open
<TabAtkins> flackr: two thoughts
<TabAtkins> flackr: if you can name a timeline that's deferred, i don't think there's any need for the ancestor selection anymore, bc you could just name that timeline?
<TabAtkins> fantasai: defer says you're planning to attach the name to something else
<TabAtkins> fantasai: but if the element is also a scroll container
<TabAtkins> fantasai: it doesn't actually bind the timeline to its own scroller
<TabAtkins> flackr: okay so i misunderstood, 'ancestor' is the name lookup
<TabAtkins> flackr: yeah i proposed something similar earlier
<TabAtkins> flackr: so two, we havne't explored this idea too far yet, t5o see if there's a need for it
<TabAtkins> flackr: i guess it sovles every use-case since you can do global timelines
<TabAtkins> flackr: but i'm interested to see in practice how often people need these other scopes
<TabAtkins> flackr: anyway if we do need this power, i think this is a reasonable approach
<TabAtkins> astearns: maybe this could be an open issue to put in the next level if needed?
<TabAtkins> fantasai: yup
<TabAtkins> astearns: unless it would be good to put in the current draft to get more eyes on it, and punt if needed later
<TabAtkins> fantasai: i defer that judgement to flackr
<TabAtkins> flackr: I think we can add this later
<fantasai> github: https://github.com//issues/7759

Can we use this proposal to simplify the lookup of animation-timeline even further? I.e. if we can declare names on an ancestor and bind them later then we don't need the previous sibling lookup right? Just to make sure I understand this proposal fully is this something like:

<style>
#parent {
  scroll-timeline-name: scroller;
  scroll-timeline-attachment: defer;
}
#scroller {
  scroll-timeline-name: scroller;
  scroll-timeline-attachment: ancestor;
}
#animated {
  animation-timeline: scroller;
}
</style>

<div id="parent">
  <div>
    <div id="animated"></div>
  </div>
  <div id="scroller"></div>
</div>

@flackr

Agenda+ to discuss @flackr's suggestion to narrow the default scope to ancestors.

@andruud

@andruud any concerns with the proposal to instead allow pre-declaring a scroll/view timeline in an ancestor allowing the use of scrollers that have not been discovered yet? I imagine this may introduce some complexity to the implementation but it is certainly nice from an authoring POV, and would mean that we could eliminate the sibling scope visibility since authors could always move the declaration of the name to an ancestor element instead.

@flackr

@flackr That seems possible only if the attachment (i.e. connection between scroller and timeline) is part of the timeline's snapshot (that's taken at the start of the frame). That means that any "dynamic reattachment" of scrollers would not take effect until the next frame. This seems aligned with how scroll timelines work already, so should be totally fine IMO.

If we can remove sibling scope visibility because of this, then it might be a net positive in terms of impl. complexity. :-)

The CSS Working Group just discussed [scroll-animations] Broader scope of scroll timelines , and agreed to the following:

RESOLVED: Reduce default scoping to ancestors only, add scroll-timeline-attachment as proposed in the issue

The full IRC log of that discussion

<emilio> flackr: we previously deferred this, but it came up that this could actually simplify timeline-name lookup
<emilio> ... where if you can define timeline names on ancestors we don't need sibling lookups
<emilio> ... this is probably architecturally simpler and already have a reasonable API for this
<emilio> fantasai: to summarize there's three options: do nothing (lookup would be ancestors and prev-siblings), adapt this explicit exposing mechanism proposed in the issue and narrow default to ancestors only, or narrow it to ancestors only for now but acknowledging we can expand in the future
<emilio> ... [describes proposal]
<Rossen_> q?
<emilio> ... so you can do attachment with my timeline name or saying "I'm an ancestor and I can declare a name etc"
<emilio> q+
<emilio> flackr: there's some hierarchies where this defer attachment is required for
<emilio> ... and it nicely generalizes
<fantasai> scribe+
<emilio> ... so I'd like to adapt it including the stricter scoping
<Rossen_> ack emilio
<fantasai> emilio: Just wanted to confirm that the proposal included dropping the sibling lookup?
<fantasai> emilio: otherwise sounds good to me
<emilio> flackr: yeah I propose dropping sibling and having deferred attachment drop those
<emilio> emilio: sgtm
<emilio> Rossen_: that's option 3 right?
<emilio> fantasai: yes
<bramus> q+
<fantasai> s/3/2/
<emilio> bramus: what's the default mechanism here/
<Rossen_> ack bramus
<emilio> fantasai: it'd look up the ancestors
<emilio> not siblings
<emilio> bramus: so if you want to include preceding siblings you'd have to define the attachment somewhere?
<emilio> fantasai: you'd declare a name in the common ancestor and the scroller would attach to that name
<emilio> flackr: my comment from sept. 7 has an example of this
<Rossen_> q?
<fantasai> PROPOSAL: Reduce default scoping to ancestors only, add scroll-timeline-attachment as proposed in the issue
<fantasai> s/proposed/described/
<emilio> RESOLVED: Reduce default scoping to ancestors only, add scroll-timeline-attachment as proposed in the issue

In true staircase wit, thinking things over last night, I would like to reconsider – at least discuss things a bit more.

As it stands now, with scroll-timeline-attachment, an author needs to do three adjustments to hook onto a scroller that’s not a parent:

Find a common ancestor and duplicate the scroll-timeline-name there
Set scroll-timeline-attachment to defer on that ancestor
Set scroll-timeline-attachment to ancestor on the scroller

This is pretty verbose imo, and I think this should be shorter. Only step 1 should be necessary.

Looking at CSS Toggles, it uses a toggle-root property to establish a toggle. Maybe we could use something similar for Scroll Timelines, e.g. scroll-timeline-root?

With it, only one adjustment would be needed by authors:

Find a common ancestor and set the scroll-timeline-root there

Reworking flackr’s example, the resulting code would then look like this:

<style>
#parent {
  scroll-timeline-root: scroller; /* Establish scope for `scroller` */
}
#scroller {
  scroll-timeline-name: scroller;
}
#animated {
  animation-timeline: scroller;
}
</style>

<div id="parent">
  <div>
    <div id="animated"></div>
  </div>
  <div id="scroller"></div>
</div>

Added benefit is that there’s less room for confusion: by using a separate property, you can easily see you’re only declaring the scroll-timeline.

For author convenience, we can maybe also reconsider for the lookup of timelines to remain “up and out” instead of ancestors only? That way no scroll-timeline-root is needed when attaching to a preceding sibling.

@bramus

@bramus I agree the original syntax is pretty verbose at the moment and I think the main thing we want is just to solve the use case. Your proposal looks like a nice improvement and seems workable to me. So defining scroll-timeline-name in the absence of a root is an implicit root right?

A couple questions came up from @andruud:

Handling multiple timelines attempting to attach to the same deferred timeline is complicated. Can we consider this an error?

I think it's reasonable to consider this an error (i.e. results in no timeline). In general a developer should have a particular scroller they are intending to observe when they declare a deferred scroll timeline name.

Is this intentionally only for scroll timelines?

I believe there are strong use cases for observing non-ancestor timelines for both scroll timelines and view timelines so we should have it for both.

[scroll-animations-1] names declared with timeline-scope are locally …

[scroll-animations-1] Clarify that timeline identity is also not cycled.

[scroll-animations-1] Replace timeline-attachment with timeline-scope #…

[scroll-animations-1] names declared with timeline-scope are locally …

[scroll-animations-1] Clarify that timeline identity is also not cycled.

Edits have been folded into scroll-animations-1 for timeline-scope for now.

See follow-up issue #8915

Bug 1835021 [wpt PR 40218] - [scroll-animations] Avoid scroll/view-ti…

Bug 1833167 [wpt PR 40012] - [scroll-animations] Add parsing for time…

Bug 1835021 [wpt PR 40218] - [scroll-animations] Avoid scroll/view-ti…

Navigation Menu

Repository navigation

[scroll-animations] Broader scope of scroll timelines #7759

117 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

[scroll-animations] Broader scope of scroll timelines #7759

Description

Activity

css-meeting-bot commented on Sep 17, 2022

flackr commented on Sep 17, 2022

fantasai commented on Dec 7, 2022

flackr commented on Jan 31, 2023

andruud commented on Feb 2, 2023

css-meeting-bot commented on Mar 20, 2023

bramus commented on Mar 21, 2023

flackr commented on Mar 23, 2023

117 remaining items

fantasai commented on Jun 6, 2023

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions