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

Re: [css3-transitions] Simplification

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Thu, 19 Feb 2009 07:50:14 -0600
Message-ID: <dd0fbad0902190550l77db94acu4fb9323dbee2c77d@mail.gmail.com>
To: Bert Bos <bert@w3.org>
Cc: Www-style <www-style@w3.org>
On Thu, Feb 19, 2009 at 4:34 AM, Bert Bos <bert@w3.org> wrote:
> A thought that I suspect has a flaw, but then again, maybe not...
>
> What uses cases would not be covered (and how bad would that be) if the
> transition property were simplified to just:
>
>    Name:            transition
>    Value:           immediate | gradual
>    Initial:         immediate
>    Applies to:      all elements
>    Percentages:     N/A
>    Media:           interactive
>    Computed value:  specified value
>
> If an element changes from one state (pseudo-class) to another and in the
> latter state the 'transition' property is 'gradual' than the style
> transition is gradual for all properties that are capable of gradual change
> (as listed in the draft). The duration of the (visual, audible or tactile)
> transition is UA dependent and so is the time-to-value mapping for each
> property (it need not be linear), but the duration should be less than a
> second.

I often see two parts of a particular item animate at different
speeds.  For example, the MarkItUp site [1] has animated nav elements
on the left.  The tabs themselves slide out quickly on hover, but the
contents of the tab slide and show slowly.

The effects of removing this control over speed would not be immense
on this site, and likely not in general either.  The differences in
animation speeds are purposely not large.  In the limit, an author
would just continue to use js to do the animations.

Many forms of animation, such as the bounce, are not currently
supported by the current syntax, but could be added at a later date.
This proposal would prevent CSS from embracing further transitions
methods.

In my personal opinion (disclaimer: I am an author that uses almost no
js-based transitions currently, but am planning to do so somewhat more
frequently in the future), this would be acceptable.  It would make
CSS-based transitions absolutely trivial while still addressing the
majority of use-cases, and modern js libraries make the rest of the
use-cases kk!.  This proposal is also compatible with gradual
enhancement - a bare-bones browser will simply ignore the transition
and change immediately, a CSS-transition-enabled browser will perform
the UA-specific transition, and a JS-enabled browser can allow a JS
library to shut off the transition and implement its own.

[1]: http://markitup.jaysalvat.com/home/

~TJ
Received on Thursday, 19 February 2009 13:50:52 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:20:16 GMT