W3C home > Mailing lists > Public > www-style@w3.org > October 2015

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

From: Lewis Dexter Litanzios / ldexterldesign <mail@ldexterldesign.co.uk>
Date: Thu, 22 Oct 2015 20:34:53 +0200
To: www-style@w3.org
Message-ID: <56292C4D.9070201@ldexterldesign.co.uk>

Yea, if I understand correctly some BEM-style naming conventions will go 
a long way here

To date the most advance methodology I've discovered is 

Slightly OT I know, but hope it's useful


On 22/10/2015 01:39, Lea Verou wrote:
>> 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

ldexterldesign ldexterldesign <http://www.ldexterldesign.co.uk/>
Lewis Dexter Litanzios
User Experience Designer
+44 7504 907 304

Received on Friday, 23 October 2015 16:18:15 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:08:57 UTC