[scroll-animations] Broader scope of scroll timelines

[fantasai]

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

[css-meeting-bot]

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

[flackr]

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>

[fantasai]

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

[flackr]

@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.

[andruud]

@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. :-)

[css-meeting-bot]

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

[bramus]

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:

1. Find a common ancestor and duplicate the scroll-timeline-name there
2. Set scroll-timeline-attachment to defer on that ancestor
3. 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:

1. 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.

[flackr]

@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:

1. 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.

2. 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.

[bramus]

So defining scroll-timeline-name in the absence of a root is an implicit root right?

Correct.

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

Could the cascade help here to determine the winner? Sure, it’s not the same element that’s being targeted here, but it’s the same scroll-timeline-root that’s being targeted. Totally fine with deferring this, as it would only complicate things for now.

2. 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.

Not quite following here. How can you track an element’s position within a non-parent scroller? It’s view-timeline inside that non-parent scroller would always be inactive, no?

[bramus]

@fantasai Could you shine your light on this? We have video-documentation on this that is being in the first week of April, so a resolution is urgent.

[flackr]

Not quite following here. How can you track an element’s position within a non-parent scroller? It’s view-timeline inside that non-parent scroller would always be inactive, no?

No, the named view timeline would still track some element's progress within its nearest scroller, but that view timeline could drive an animation on another element.

[bramus]

Oh yeah, of course – I was too focused on animating the subject itself 🤦‍♂️. Makes sense to add it.

[fantasai]

This is pretty verbose imo, and I think this should be shorter.

@bramus I don't think it's very verbose?

.root { scroll-timeline: carousel defer; }
.scroller { scroll-timeline: carousel ancestor; }
.animator { animation-timeline: carousel; }

I'm not super against using a separate property to declare a scope, but having a handshake like this reduces conflicts like some other element defining timeline with the same name and expecting it to bind locally. It also allows for recursion, which re-using the same property doesn't.

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.

There were two benefits to removing the sibling lookup:

• Improves performance and implementation simplicity.
• Removes asymmetry between previous and next siblings, which could cause the author to order things unnaturally in the source (which affects a11y and other operations on the source tree).

[fantasai]

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

See follow-up issue #8915