Re: [css-animations] Multiple identifiers per @keyframes rule

> On Oct 21, 2015, at 19:33, Tab Atkins Jr. <jackalmage@gmail.com> wrote:
> 
> The benefit of putting this in 'animation' rather than @keyframes is
> that it keeps the addition localized to the place that needs it.
> Rather than having to edit in two places - add a new name to
> @keyframes, then use that name in 'animation' - you can just declare
> in 'animation' that this needs to be treated as unique. I think it
> captures the semantics a little better, too.

That’s an excellent point!! Yes, you’re right, it should be in animation-name, for precisely this reason.

> (Ultimately, this is all hacks around how the 'animation' property was
> explicitly designed to do "continuous animation while element is in a
> given state", not "one-off animation when element enters/leaves a
> given state".  Transitions uses the desired model, but it's low-power,
> only able to kick off animations for precisely the properties that
> change, and only from previous to the current value.  I had a proposal
> a few years ago to tie them together, allowing someone to kick off a
> keyframe-based animation from a transition, using an early variant of
> custom properties to serve as kick-off proxies.  That way you could,
> for example, apply "input + label { --state: off; } input:checked +
> label { --state: on; }", then have a keyframe-transition based on
> --state changing.  But that never went anywhere, unfortunately.)

Yup, totally agree. I also find it odd how transitions and animations are separate, but have so much in common. It looks like it should have been one spec. Anyhow, it’s too late to change them in a fundamental way, so I think a patch to address the use cases I’m describing is a more viable option at this point (and perhaps it could even make it to L3?).

~Lea

Received on Wednesday, 21 October 2015 23:39:36 UTC