Re: [css3-transitions] Simplification

On Feb 19, 2009, at 2:34 AM, Bert Bos 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.

We've found that in practice, the UA can't always pick a duration and  
transition function that looks good and matches what the author wants.  
We have made a number of demos of CSS Transitions, and we've often had  
to adjust the duration and transition function, and to control what  
properties transition, to get something that looks good. Heuristics  
cannot reasonably achieve achieve what hand-tuning can. And it's  
important for transitions to be aesthetically pleasing - after all,  
that is largely the point of doing an animated transition in the first  
place.

I note that in many other places, CSS gives authors fine-grained  
control over various details, even though a simpler approach might  
satisfy a lot of needs. For example, exact 24-bit hex values can be  
used to specify colors, even though the color keywords alone would  
meet most basic needs. Similarly, explicit positioning and sizing  
support is provided, even though usually automatic layout is good  
enough. These days, transition effects are an important consideration  
for designers, as much as colors, sizes, images and typography.


In a separate email:

On Feb 19, 2009, at 5:50 AM, Tab Atkins Jr. wrote:
>
> 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!.

The basic case of applying a transition is equally trivial. It is  
important to accomodate author hand-tuning without having to escape to  
JavaScript. JS-driven animations are not amenable to hardware  
acceleration, and are likely to consume more CPU and more battery life  
on mobile devices. It's important to have a design for transitions  
that can work well across a range of devices. Furthermore, if CSS  
provides for transitions at all, it should try to be reasonably  
complete and not force the use of scripts solely for presentational  
effects. Scripting should be left to cases where actual behavior or  
application logic must be implemented.

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

This is already possible with the current design. Browsers that don't  
support CSS Transitions will simply transition immediately. In  
addition, there are even JS libraries that will parse the CSS  
Transitions syntax and perform a script-driven version of the  
transition on browsers that do not support CSS Transitions natively.

Regards,
Maciej

Received on Thursday, 19 February 2009 19:06:14 UTC