[scroll-animations-1] blocking effects of timeline-scope

[fantasai]

We added timeline-scope in #7759:

timeline-scope: none | <custom-ident>

Based on some clarifications from @flackr it seems the intention is not only to pull up the scope of a named descendant timeline, but also to block it from being further pulled up by a higher ancestor. (Also, due to error-handling, names declared that have zero or multiple possible descendant timeline bindings are treated as declaring an inactive timeline.) Put together, that gives a definition that looks like:

This property declares the scope of the specified timeline names to extend across this element’s subtree.
This allows a named timeline (such as a named scroll progress timeline or named view progress timeline) to be referenced by elements outside the timeline-defining element’s subtree—for example, by siblings, cousins, or ancestors.
It also blocks descendant timelines with the specified names from being referenced from outside this subtree, and ancestor timelines with the specified names from being referenced within this subtree.

I'm opening this issue:

1. to confirm that we want to have this blocking behavior.
2. to ask if we want to add
   • a keyword to perform this blocking function on all possible timeline names (contain?)
   • a keyword to perform this blocking function all timeline names declared by this element (local?)

[flackr]

Making timeline-scope block propagation of a named timeline allows subtrees to use named timelines without worrying about conflicts with ancestors using the same names. e.g.

<div style="timeline-scope: --timeline">
  ....
  <div id="subtree" style="timeline-scope: --timeline">
    ...
    <!-- This is the --timeline used by anything inside of #subtree -->
    <div id="inner-timeline" style="view-timeline: --timeline;"></div>
  </div>
  ...
  <!-- This is the --timeline used by anything outside of #subtree -->
  <div id="outer-timeline" style="view-timeline: --timeline;"></div>
</div>

The downside is if you actually wanted to use the #inner-timeline named timeline you wouldn't have access to it without removing the intermediate timeline-scope declaration. Removing this would not break things in pages which did not separately define a timeline in the outer scope so as long as a developer controls the subtree it seems flexible.

IMO this allows for similar setups to custom variables where the #subtree can redefine a timeline such that it has a different timeline for that subtree.

If we don't block the propagation, the --timeline in the outer tree becomes invalid due to multiple timelines attaching to that name and so developers have to be careful to not use names that could conflict with an ancestor named timeline.

[bramus]

Hadn’t considered this before, but must say I am OK with the current behavior. It would allow re-use of the CSS – e.g. a utility-class – when nesting elements with timelines and – as flackr@ mentioned – wouldn’t break things because no two timelines want to attach to the same scope.

Should a more broader scope be needed, an author can always move up the timeline-scope declaration. I think this is something they’d want to be very explicit about, without external factors _(read: outer components) suddenly doing so while breaking things along the way.

[fantasai]

Thinking about it more, keywords here probably should be contain-all and contain-self if we go down the adding-keywords route.

[css-meeting-bot]

The CSS Working Group just discussed [scroll-animations-1] blocking effects of timeline-scope, and agreed to the following:

• RESOLVED: A timeline-scope also prevents the timeline from being scoped even higher.
• RESOLVED: contain:style prevents timeline names from leaking out past it
• RESOLVED: Don't add any additional keywords to timeline-scope for this use-case (for now)

The full IRC log of that discussion

<TabAtkins> fantasai: I just wanted to confirm with the WG the behavior
<TabAtkins> fantasai: The timelie-scope property is defined to pull the scope of a timeline name up to an ancestor, which makes it available to a larger subtree
<TabAtkins> fantasai: as we were drafting, robert clarified that it also blocks the timeline from being pulled further up into a higher ancestor
<TabAtkins> fantasai: so i'm just confirming that it desired behavior
<TabAtkins> fantasai: and second to ask if we want to add keywords to make this blockign behavior work for all timeline names on an element
<TabAtkins> flackr: the motivation is that if you define a timeline scope for an element, you're isolating the effects of the timeline named there from affecting anything outside that element
<TabAtkins> flackr: so it's similar to containment in a way
<TabAtkins> fantasai: so any thoughts or comments about this blockign behavior?
<TabAtkins> fantasai: if it seems good we can resolve on that
<TabAtkins> (don't really have an opinion, seems fine)
<TabAtkins> astearns: objections?
<TabAtkins> RESOLVED: A timeline-scope also prevents the timeline from being scoped even higher.
<TabAtkins> fantasai: do we want to add keywords that add this scope-blocking on all possible names in a subtree, or all names declared by the element with timeline-scope?
<TabAtkins> fantasai: So if you're doing a bunch on a subtree, you want none of the timleine names to escape the subtree, you don't want to list them all out
<TabAtkins> fantasai: or if you're declaring several that you want to be scoped but you don't wnat to block your children from lifting their scopes, maybe a local thing
<TabAtkins> astearns: apologies, not actually clear what this would do, i assume rob and others have an opinion?
<TabAtkins> fantasai: will explain again. if you declare scroll-timeline on a scroller it's available to its descendants only
<TabAtkins> fantasai: If you want that timeline avaialble higher, you ahve to use timeline-scope on an ancestor referring to it, then it's visible to the scoping element's descendants.
<TabAtkins> fantasai: The blocking effect we jsut talked about means it can't go even higher
<TabAtkins> fantasai: [explains in more detail]
<TabAtkins> fantasai: if you want to encapsulate all the possible scrollers inside you, you might not know all the names on your contents
<flackr> q+
<TabAtkins> fantasai: if you're in a component or whatever
<astearns> ack fremy
<TabAtkins> fantasai: some higher element in your chain might say "timeline-scope: foo" and not be looking for your "foo" timeline, but another one it knows about. but it finds yours instead.
<TabAtkins> fantasai: To prevent this you ahve to preemptively timeline-scope all of your names.
<astearns> ack flackr
<TabAtkins> fantasai: so do we want to make this easier
<TabAtkins> flackr: it feels a bit odd to re-use timeline-scope for this since you're not raising the scope
<TabAtkins> flackr: coudl we say contain:style prevents the leakage or would that be too restrictive?
<TabAtkins> fantasai: think that's a good idea anyway
<TabAtkins> flackr: if we need that, do we need a timeline-scope:all?
<TabAtkins> fantasai: we might bea ble to get away without it, yeah
<TabAtkins> I agree that contain:style should prevent names leaking out
<TabAtkins> that's the point
<TabAtkins> flackr: so that's my proposal, use contain:style
<TabAtkins> fantasai: sounds good
<TabAtkins> astearns: yeah makes sense
<ydaniv> +1
<TabAtkins> astearns: any other opinions?
<TabAtkins> astearns: objections?
<emilio> q+
<TabAtkins> emilio: are there use-cases for scoping timeline names but not counters?
<TabAtkins> astearns: whether or not there is, shoudl contain:style scope both anyway?
<TabAtkins> emilio: it should yeah
<TabAtkins> astearns: so i think we can resolve on contain:style and then your question is about maybe still adding a separate control
<emilio> ack emilio
<TabAtkins> astearns: so any objections to contain:style?
<TabAtkins> RESOLVED: contain:style prevents timeline names from leaking out past it
<TabAtkins> astearns: so emilio's question is an argument for adding a keyword to do just the one thing
<TabAtkins> astearns: i can't immediatly think of a case where you'd want to do them separately
<TabAtkins> fantasai: If we did add the keywords, i just thought of 'contain-all' and 'contain-self'
<flackr> q+
<TabAtkins> astearns: i suggest we leave the keywords out until we have evidence that just using contain:style is insufficient
<astearns> ack flackr
<TabAtkins> flackr: if we did have an "all" on timeline scope, I'd also expect them to raise the scopes they captured
<TabAtkins> fantasai: yeah that's why i thought of the "contain-*" names to separate them a little more from that concept
<TabAtkins> flackr: ah right. but for now I think we're comfortable with not doing this
<TabAtkins> fantasai: so proposed resolution is to not add keywords for ow
<TabAtkins> astearns: objections?
<TabAtkins> RESOLVED: Don't add any additional keywords to timeline-scope for this use-case (for now)
<fantasai> Side comment: 'contain: style' should probably also affect anchor-name