Skipping.

Xiaocheng: Motivation is they want to play animations … very common pattern when you interact with certain parts of the page that they show animations. When you click a button, some element nearby is rotated by a certain angle that indicates the element has been clicked.

… Currently, events and JavaScript have to be added, which isn't great. They are proposing a declarative syntax in CSS to allow triggering such animations completely off the main thread.

… Regarding their direction, I think this is good, like it a lot. Like when offloading work from the main thread. Starting/stopping an animation is a very traditional topic in CSS.

Martin: What's your view on the name? Right now, it has an animation trigger. One element triggers the animation of another element. Name here seems to add another layer of indirection. May be appropriate? You can have multiple elements to trigger the elements, and multiple elements to respond to the same name… many-to-many relationship.

Xiaocheng: Think they are proposing a many-to-one relationship…?

Martin: They are using ID selectors, but they could be class selectors.

Xiaocheng: Not following what you meant by using a selector? Does this change the relationship?

Martin: No, doesn't change the relationship. … (Can name be replaced with selector?)

Xiaocheng: Replacing the name with a selector? Think they follow the design of anchor positioning. Think they want the trigger element to be unique. Selector might match multiple elements.

Martin: But that could happen with the name as well, as it has a selector attached to it. Right now, they have an ID selector, that's probably only one thing. But if it was a class selector, it could match more elements than one.

Lola: But shouldn't that be left to the developer to decide? What's the impact?

Martin: Is the extra layer of indirection adding value in some way? Not sure what the value of adding the indirection is.

Matthew: See what you're asking, Martin. Should ask what the rationale is. Related question: Struggling to find the bit where they allow other triggers than just click. Can't find where this is specified. Explainer doesn't mention it either.

Xiaocheng: This is where I want to raise a concern. Didn't find it at first as well. Assume that the trigger functions should match the event names in UI Events. Don't think every UI event qualifies as a trigger. Think this part is underspecified.

… Related concern is this is adding coupling between CSS and UI events spec. Not sure if that's a good thing. Wondering if there's a way to define the trigger functions to not couple with UI events spec.

Martin: Can we replace this behavior with existing capabilities? For example, when clicking something, it gains focus, that could change the DOM, activate different CSS, and thereby trigger an animation.

Xiaocheng: Can this avoid the main thread?

Martin: Think so! There'a brief hit on the main thread, as for any action. But the event doesn't necessarily have to invoke JS, but the DOM instead.

Xiaocheng: Think they're trying to trigger UI events in the compositor thread without redefining UI events.

Lola: In terms of next steps, I think we cannot close this yet. Sounds like there's concerns around the design of trigger functions. You can write a comment to put that back to them.

Martin: Just trying to help out… They have drafted some specs, but they didn't incude links in the explainer. Needs more clarity. Looks like someone had an idea. Might need more discussions.

Lola: Is this an early review?

Martin: If it isn't, it should be one.

Xiaocheng: Is not marked as an early review.

Lola: Doesn't look like other browser vendors were involved. Wait for what they respond. Don't think we can close this for now.

Matthew: we had some queries about htis, Martin is particularly interestsed and I agree: why are they adding an extra layer of indiection here, why are they not using selectors? Xiaocheng hasn't come back to clarify.

We did talk about: 1. Asking that (above), 2. it's very underspecified in terms of the set of functions. We assume they come from UI events, but we wouldn't want to use the whole set. but there are things in there that wouldn't make sense as triggering functions.

Looks like no one has asked the question. We could ping Xiaocheng at the plenary, and then I could draft a comment.

Xiaocheng: Discussed this two weeks ago, I was supposed to draft a comment, but didn't do it yet.

… There is a point that Martin raised earlier about the indirection of element names. Could you explain this to me?

https://szager-chromium.github.io/declarative-interactions/#solution-sketch

Matthew: There seems to be a layer of indirection, where you give the animation trigger a name, but we don't understand why. Why not simply selectors? What is the advantage of introducing the name?

… Looked at the spec, and had an idea. Maybe they give them a name, so they can skip the shadow tree, but that doesn't seem necessary. But it comes back to why do we need the name?

Xiaocheng: I think anchor positioning should have the same issue, did we discuss it before?

Matthew: We should check back on that, good point.

… Other concern is that they don't specify where the name for the trigger functions come from, very underspecified.

Xiaocheng: Will check anchor positioning and then draft a comment.

Lola: We will come back to this next week.

Xiaocheng: If we've discussed this before, we could send out the comment this week already.

Matthew: Animation triggers, with layers of indirection, where's that at?

Xiaocheng: Proponents already answered questions.