W3C home > Mailing lists > Public > www-style@w3.org > February 2012

Re: [css3-animations] Editability of CSS 3 Animations

From: Simon Fraser <smfr@me.com>
Date: Sun, 05 Feb 2012 10:03:31 +0100
Cc: Daniel Glazman <daniel.glazman@disruptive-innovations.com>, www-style@w3.org
Message-id: <FB476DFE-7BD1-446F-A253-86EC59428716@me.com>
To: "Tab Atkins Jr." <jackalmage@gmail.com>
On Feb 3, 2012, at 4:08 PM, Tab Atkins Jr. wrote:

> On Fri, Feb 3, 2012 at 7:01 AM, Daniel Glazman
> <daniel.glazman@disruptive-innovations.com> wrote:
>> Le 03/02/12 15:54, Tab Atkins Jr. a écrit :
>>> I meant make up some reasonable defaults *for the purpose of
>>> previewing*.  You even suggest that perhaps 1s would be a good default
>>> duration.  Just use that in your preview to show the general effects
>>> of the keyframes while people are editting them.
>> You understand that from a UX point of view, having 0s animations
>> look like 1s animations is a catastrophe ?
>> Similarly, all animations that will run with an animation-delay
>> that is not set in the rule setting animation-name
>> will appear starting at 0s... Urgh.
>> I perfectly understand the compromise you're proposing, and I am
>> saying this compromise is here to save a technical change at the
>> cost of editability and UX. Given the importance of CSS 3 Animations,
>> I think editability is a too major feature to go that way.
>> I'd love to hear from Apple people here.
> You're in charge of the editor.  You can, *when people are editting
> the 'animation' property*, preview the actual duration/delay/etc
> they're using at that point, and even call out a 0s duration as "you
> probably didn't mean to do that".  Just use the defaults when you're
> previewing the @keyframes rule specifically.
> Even if you bake default durations into the @keyframes rule, people
> can change it at the point of use.  It seems like the same argument
> for why this is bad would apply.

I agree with Tab. It seems like your editor is trying to impose a timeline
structure on something that doesn't have one. If your tool is all-encompassing
(meaning that the author uses it to control what JS runs when, and therefore
when the "dynamic" style gets applied), then the problem goes away because
you know when the animation is going to run.

If you replace animation-* with some other property with a shorthand, like border-*,
why is the problem different?

Received on Sunday, 5 February 2012 12:09:23 UTC

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