Re: [csswg-drafts] [css-animations-2] Declarative syntax for GroupEffects (#9554)

>  I think the order property is a useful precedent for this sort of property. However it's a bit different because for layout normally the source order and the layout order match so you only need to specify order occasionally.

Yes, that was my intention. To have some sensible defaults that we carefully need to work out because it's not as simple as DOM order.

> It's probably less common for source order and temporal order to match, however? Sometimes they will match (e.g. when you're animating a list in or out), and sometimes the order of animations in the animation-name property could provide the correct group ordering, but when you're animating the elements of a screen layout, for example, neither the source order not the animation-name order is likely to provide a suitable group ordering and the animation-group-ordinal property will be needed.

I can currently think of 4 use-cases,  there are probably more. You mentioned 3 of them above:

1. synching different effects on same element
2. synching same effect on a list of siblings
3. synching same effect on a grid - siblings but order is not trivial
4. synching separate effects on non-sibling elements(not 2 or 3)

For 1 we could default to the order of effects in `animation-name`.
For 2 we could default to DOM order.
For 3 we could still default to DOM order, but an override might be required.
For 4 we could also default to DOM order but very likely it will require an override.

It's also possible to see a mixture of case 1 together with one of the cases 2-4. So maybe you'll have an index per element, plus extra indices per animation on each element.

------

> Forgive me if you've covered this elsewhere, but I'm curious if there was a particular reason for taking a bottom-up approach vs a top-down one such as defining the group children via an @ rule instead?

I followed the design we already have for `view/scroll-timeline` and `timeline-scope`. The goal here is to have a property on the element with the `animation` property that opts it out of being active automatically, and instead adds it into a group. I guess doing that with a property like `animation-ref` could have the same effect as an `animation-group` property.

If we consider again the use-cases above, in some having a bottom-up is more convenient, and in others rather the top-down.
For case 1 the top-down one could be more  handy, where you have a small number of specific effects and you could name each effect and then reference them in a group.
Same could be for case 4.
In cases 2 and 3, however, you could have a single effect (or a single group effect) and a large number of elements with that effect. So naming the effect doesn't provide much benefit here, but rather opting-in to a group is more straight forward.

Having an @ rule could be handy for declaring a reusable group. However, you're still left with defining the activation of the group. You still need to specify it somehow on an element for it to become active. I can't find a proper way to do that for multiple elements, other than the way suggested above.

In your suggestion above using `animation-ref` and `@animation-group` the activation is implicitly spread across the group children, rather than have a single point of activation. Although, I think have a an alternative form of naming the child effects could be very comfortable in the case 1 above.

Perhaps we could have sort of an anonymous group definition for that case with single element and multiple effects? And have a named group for the single effect with multiple elements case?

-- 
GitHub Notification of comment by ydaniv
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9554#issuecomment-1804353838 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Thursday, 9 November 2023 18:35:49 UTC