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

On Tue, Oct 20, 2015 at 5:05 PM, Lea Verou <lea@verou.me> wrote:
>> On Oct 20, 2015, at 19:58, Xidorn Quan <quanxunzhen@gmail.com> wrote:
>> Interesting use case. Yes it seems like a valid usage, but allowing
>> multiple identifiers per @kerframes rule doesn't seem to make much
>> sense otherwise.
>>
>> Given the rule is that animation occurs when `animation-name` is
>> overridden, what about extending `animation-name` to accept an
>> optional extra component after each animation name, which doesn't have
>> meaning itself, just for triggering the overriding?
>
> I would argue that this is even more hacky. At least allowing aliases on @keyframes is a feature, even though it’s intended to help with a hack and could aid readability in other use cases too (e.g. reusing an animation for different purposes could now use different names). Allowing garbage in animation-name just to trigger changes is very, very conspicuously a hack :P

It's... exactly the same as what you're asking for, just with the
garbage declared in a different spot.  You're just putting the garbage
into the @keyframes rule, while Xidorn is suggesting putting it into
'animation-name'.

Before I read this thread, I'd given it some thought and came up with
the same basic proposal Xidorn did - an explicit way of saying "use
these keyframes, but treat them as a new, unique animation compared
with anything else".  I don't think we even need to make the garbage
explicit - I'm not seeing any immediate use-cases for having multiple
rules need to reference the same "unique" animation.

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.

(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.)

~TJ

Received on Wednesday, 21 October 2015 23:34:23 UTC