The current direction of #12336 is that animations are associated with triggers via names (dashed idents). I’m filing this issue so that we can resolve on 2 questions related to name clashes:

1. How should name clashes between elements be resolved?
   For example:

#source1 {
 event-trigger-name: --trigger;
}
#source2 {
 event-trigger-name: --trigger;
}
#target {
 animation-trigger: --trigger;
}

Should #target get the trigger on #source1 or on #source2?
In theory we could specify that the above CSS attaches 2 triggers to #target’s animation. However, 1. that's probably not in line with the way dashed idents typically work & 2. we’ve resolved in #12399 to allow only a single trigger per animation to start - as such, #target needs to pick one trigger.

Some precedents:

• The anchor position pattern: among elements with the same anchor-name, the last in tree-order is selected.
• The timeline-scope pattern: where multiple timelines have the same name within a particular scope, that name is considered to refer to an inactive timeline.

I propose we go with the anchor position pattern because I think it is more author-friendly - an author could use it to "override" a trigger declared higher up in the DOM. The downside of this choice is that an author could accidentally have their animation linked with the wrong trigger. However, I think this problem will be significantly mitigated when we introduce a (to-be-bikeshed) trigger-scope property which limits visibility of trigger names similar to anchor-scope. I also think that from an author's perspective, it is no worse than if the trigger name was simply ruled invalid (the timeline-scope approach).

2. How should name clashes between timeline-trigger and event-trigger be resolved?

#source {
  event-trigger: --trigger;
  timeline-trigger: --trigger;
}
#target {
  animation: ...;
  animation-trigger: --trigger;
}

Does #target’s animation get an EventTrigger or a TimelineTrigger?

I think our options are to:

1. pick a winner: If selecting this option, I would propose timeline-trigger take precedence over event-trigger because because we can think of a TimelineTrigger as a special case of an EventTrigger which has not just a "primary" (i.e. "start") class of events (enter) but also a "secondary" (i.e. "end") class of events (exit), whereas regular EventTriggers simply have "primary" events, e.g. "click", "keypress", "mouseleave", etc, which they associate with a specified action. So timeline-trigger should take precedence when both are present and clash on name.
2. treat this as invalid: I think it would be understandable to an author that declaring an event-trigger and a timeline-trigger of the same name on the same element is an invalid setup. An author might not explicitly do this, e.g. perhaps it could be a conflict between a library an author has imported and their own code, but I think such a naming conflict is an unlikely edge case.

On question 2, I propose we go with option 2. I think option 1 leads us down the path of establishing an order or precedence between present and future trigger types and it might not always be sensible to ask "does trigger type x take precedence over trigger type y?"