[css-animations-2] Move scroll and event animation triggers to independent namespace

[flackr]

As we're adding more features or types to animation triggers #12314 and as we've mostly decided that triggers should be an independent thing controlling the playback of an animation #12119, I think that we should create triggers in a similar way to view or scroll timelines.

The current spec https://drafts.csswg.org/css-animations-2/#animation-triggers lists some of the trigger related properties and more are being added for event triggers.

TLDR; I propose we have new prefixes that independent from the animation-* longhands for creating named triggers (following pattern of timelines), e.g. timeline-trigger-* combined with a dashed-ident name that can be referenced from the animation-trigger property on an animation (similar to referencing an animation-timeline).

As we're adding all of these features, they each come with a long set of properties. We also expect for event triggers that the source of the events may be on a completely different element. As such, I think these should be set up in a manner similar to view or scroll timelines and referenced from the animations which want to associate with them.

We can of course also have a convenience function for creating anonymous triggers directly from the animation-trigger property but I think it may be confusing and inconvenient to add a bunch of animation-trigger-* longhand properties when triggers, like timelines, are not inherently associated with or part of the definition of an animation and which properties they have depends on the type of trigger.

#12336 (comment) has a good breakout of what all of these properties might look like.

Rough idea, animation-trigger would be a coordinated list similar to animation-timeline specifying either a named trigger or an anonymous trigger construction, e.g.

animation-trigger:
    [ <dashed-ident> |
      timeline(<behavior> <timeline-reference> <entry range> <exit range>) |
      event(<event list>) ]#

The longhands in https://drafts.csswg.org/css-animations-2/#animation-triggers would be changed to set up a named trigger, e.g. timeline-trigger-*, with an additional timeline-trigger-name to set the dashed-ident name that can be referenced from animation-trigger.

cc @szager-chromium @DavMila @birtles

[ydaniv]

TLDR; I propose we have new prefixes that independent from the animation-* longhands for creating named triggers, e.g. timeline-trigger-* combined with a dashed-ident name that can be referenced from the animation-trigger property on an animation (similar to referencing an animation-timeline).

I've thought about this a few times in the past, declaring triggers separately using an ident, and then referencing that ident from animations, but it seems to me that this only needlessly complicates the feature without adding any benefit to authors.

WIth the current syntax you have the following references: animation.trigger -> timeline.
With the proposed change you'll have: animation -> trigger -> timeline.
And if we consider all names are tree-scoped, then we may need to jump through 2 scope-lifting hoops in some cases.
I strongly feel this makes the API much more complicated and without any additional benefit.

I understand we have technical problems overloading/expanding the syntax of animation-trigger to also accommodate event-based triggers, but we shouldn't sacrifice reaching a good design over technical issues.

Another way to escape the double reference would be to make trigger declaration an at-rule, but this also seems like an unnecessary complication to the model.

The problems we're facing now are:

• How to overload animation-trigger to allow singular events along with timelines.
• How to declare those events on elements.

For example, we could do something like adding a longhand like animation-trigger-event, which when set, renders animation-trigger-timeline to none. Since -timeline already accepts a dahsed-ident we could wrap that in an event() function.

Then we need to decide on something like adding a trigger-event property which allows setting a list of events.

[bramus]

One of the things that a separate …-trigger enables is the ability to have one element be the trigger, and then use that trigger as the animation-trigger on a different element. Similar to how a (named) view-timeline can be used as the animation-timeline on a totally different element.

[ydaniv]

One of the things that a separate …-trigger enables is the ability to have one element be the trigger, and then use that trigger as the animation-trigger on a different element. Similar to how a (named) view-timeline can be used as the animation-timeline on a totally different element.

Of course, maybe I wasn't clear in my comment above:

Then we need to decide on something like adding a trigger-event property which allows setting a list of events

We need a new property to allow setting an ident and an event type on an element to declare an event. My placeholder name suggestion trigger-event, that accepts a list of event declarations.
This property will allow declaring an event source.

Then we can add the ability for animation-trigger to accept a reference to an event, could be with another sub-property like animation-trigger-event, only we need to differentiate that from animation-trigger-timeline, so conceptually suggesting a syntax like:

<single-animation-trigger> = <single-animation-trigger-behavior> || [ none | auto | event(<dashed-ident>) | [ [ <dashed-ident> | <scroll()> | <view()> ] [ normal | <length-percentage> | <timeline-range-name> <length-percentage>? ]{0,4} ] ]

Specifically see the event(<dashed-ident>) addition.

What I objected to is removing the entire animation-trigger declaration into a separate no property, since I think that will only complicate the API and won't add any additional ability we don't currently have.

[DavMila]

What I objected to is removing the entire animation-trigger declaration into a separate no property, since I think that will only complicate the API and won't add any additional ability we don't currently have.

I don't think having separate namespaces for timeline- and event- based triggers necessarily overcomplicates things - it's essentially keying off of the basic idea of dashed idents, which is already a familiar concept to authors e.g. anchor-position-name, view-timeline-name, counter-reset.

It seems like a cleaner way to organize the properties so we don't have a longhand (animation-trigger-event or animation-trigger-timeline) which may or may not be relevant to the trigger. I'm not sure if there is precedent for setting one longhand property because another one is set, but that seems like something we should avoid if we can? Without doing that, we have to arbitrarily decide whether animation-trigger-event takes precedence over animation-trigger-timeline when both are set.

There may be two issues we can separate here:

• separate namespaces for timeline- and event- based triggers,
• name scoping

With your suggestion of trigger-event, I would be inclined to have a more comprehensively defined event-trigger which defines and names an event-based trigger that can be referred to from elsewhere than to have a more limited trigger-event property which is referred to by an animation-trigger-event property which isn't quite so.. (for lack of a better term) flush with other animation-trigger longhands.

Perhaps your objection is more strongly towards the second (name scoping) than the first?

Overall I'm imagining the following heirarchy of properties (whose names we can certainly improve ):

• animation-trigger-scope
• animation-trigger
  • animation-trigger-name
  • animation-trigger-behavior
• timeline-trigger
  • timeline-trigger-name
  • timeline-trigger-timeline
  • timeline-trigger-range-start
  • timeline-trigger-range-end
  • timeline-trigger-exit-range-start
  • timeline-trigger-exit-range-end
• event-trigger
  • event-trigger-name
  • event-trigger-type

So you could have:

#scope {
  animation-trigger-scope: –scrolltrigger, –clicktrigger; 
}
#scrollsubject {
  timeline-trigger: –scrolltrigger view() contain 0% contain 100%;
}
#clicksubject {
  event-trigger: –clicktrigger event(click);
}

#scrolltarget {
  animation: …;
  animation-trigger: alternate –scrolltrigger;
}

#clicktarget {
  animation: …;
  animation-trigger: repeat –clicktrigger;
}

and in HTML:

<div id=“scope”>
  <div id=“scroller”>
    <div id=“scrollsubject”></div>
  </div>
  <div id=“scrolltarget”></div>
  …
  <div id=“clicksubject”></div>
  <div id=“clicktarget”></div>
</div>

One point that might be worth highlighting in this scheme is how an author could write the following:

#a { view-timeline-name: --mytl; }
#b { timeline-trigger: --mytr --mytl; }
#c { animation-trigger: --mytr repeat; }

In which case, if element b disappears, then so does the trigger. I don't think this is much of a problem; it just doesn't seem like it would be useful.

On animation-trigger-scope, we could probably file a separate issue on whether to have this property and scope animation-trigger-names similar to view-timelines & timeline-scope or whether the names should be implicitly global.

[ydaniv]

It seems like a cleaner way to organize the properties so we don't have a longhand (animation-trigger-event or animation-trigger-timeline) which may or may not be relevant to the trigger. I'm not sure if there is precedent for setting one longhand property because another one is set, but that seems like something we should avoid if we can? Without doing that, we have to arbitrarily decide whether animation-trigger-event takes precedence over animation-trigger-timeline when both are set.

Yes, it's not optimal, but you can see we already have a syntax like auto | [ <timeline> <ranges> ], so ranges are not allowed with auto. So if both are specified this becomes invalid at parse-time. Same with my suggestion above that includes event(<dashed-ident>).

One point that might be worth highlighting in this scheme is how an author could write the following:

#a { view-timeline-name: --mytl; }
#b { timeline-trigger: --mytr --mytl; }
#c { animation-trigger: --mytr repeat; }

In which case, if element b disappears, then so does the trigger. I don't think this is much of a problem; it just doesn't seem like it would be useful.

The thing we need to acknowledge here is that triggers are not directly associated with elements. And IMO making their declaration a separate property is not a good design.
Of course, if we just take the trivial case of declaring timelines with scroll()/view() then we sort of try to avoid that issue, but like your example above, if an author defines the timeline on one element and references it on the trigger, then the trigger declaration becomes an annoyance.

Regarding scoping, I think if we want to add events to be consumed similarly to timelines then we should have a similar API for events as for timelines, with declaration on elements and a specialized scoping declaration. And then consume those in triggers, same as we do now with timelines.

[DavMila]

Yes, it's not optimal, but you can see we already have a syntax like auto | [ <timeline> <ranges> ], so ranges are not allowed with auto. So if both are specified this becomes invalid at parse-time. Same with my suggestion above that includes event(<dashed-ident>).

It isn't quite the same thing with -timeline and -range-start/end. Here, we aren't arbitrarily picking one over the other or setting one based on what the other is. One property isn't becoming wholesale invalid because another is set. The ranges are to be interpreted in the context of the timeline. auto means "use the document timeline", which works based on time values. We don't currently specify time ranges, but that could be a thing in the future. It's similar to animation-timeline and animation-range.

The thing we need to acknowledge here is that triggers are not directly associated with elements. And IMO making their declaration a separate property is not a good design. Of course, if we just take the trivial case of declaring timelines with scroll()/view() then we sort of try to avoid that issue, but like your example above, if an author defines the timeline on one element and references it on the trigger, then the trigger declaration becomes an annoyance.

I gave that example just as a weird case that would be possible but may not really be useful to authors - I don't think it in any way represents this API format getting in an author's way as they wouldn't need to use a dashed ident.

[DavMila]

It isn't quite the same thing with -timeline and -range-start/end. Here, we aren't arbitrarily picking one over the other or setting one based on what the other is. One property isn't becoming wholesale invalid because another is set. The ranges are to be interpreted in the context of the timeline. auto means "use the document timeline", which works based on time values. We don't currently specify time ranges, but that could be a thing in the future. It's similar to animation-timeline and animation-range.

On the other hand, I guess it would still be pretty well-defined to say that animation-trigger-event takes precedence over animation-trigger-timeline. animation-trigger defaults to a timeline-based trigger, so if animation-trigger-event is present it makes sense to give it priority, I feel. I think I'm okay with keeping animation-trigger and its longhands as we currently have them.

[bramus]

… say that animation-trigger-event takes precedence over animation-trigger-timeline

If it takes precedent, then that’s an argument against it being a separate property design-wise. If the one can be combined with the other, then it’d make sense to split them into two distinct things.

[DavMila]

… say that animation-trigger-event takes precedence over animation-trigger-timeline

If it takes precedent, then that’s an argument against it being a separate property design-wise.

Right, I was considering keeping the current format, but I think it's best we don't.

I've written up a proposal to more fully capture the idea of different namespaces.

Putting this on the agenda so we can get consensus on: should animation-trigger adopt separate namespaces, per the proposal or keep the current format?

[szager-chromium]

@DavMila I have a question about the last example in your proposal:

section {
  timeline-trigger: --t1 once ..., --t2 alternate <same as previous>;
}

.animatable {
  animation: ...;
  animation-trigger: --t1 --t2;
}

Is timeline-trigger a coordinated list? It seems not, but I just want to be sure.

[DavMila]

@DavMila I have a question about the last example in your proposal:

section {
  timeline-trigger: --t1 once ..., --t2 alternate <same as previous>;
}

.animatable {
  animation: ...;
  animation-trigger: --t1 --t2;
}

Is timeline-trigger a coordinated list? It seems not, but I just want to be sure.

That's right - it isn't a coordinated list.