[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