Re: [CSS3] transition effects

Martijn wrote :
> 
> On 5/8/06, Laurens Holst <lholst@students.cs.uu.nl> wrote:
> 
>> Example:
>>
>> a {
>>    background-color: yellow;
>>    animate-properties: background-color;
>>    animate-duration: 2s;
>>    animate-motion: logarithmic;
>> }
>> a:hover {
>>    background-color: orange;
>> }
>>
>> Thank you for your attention.
>>
> 
> I like the idea. Not sure whether the properties are all a good idea
> (especially I have a problem with animate-motion ), but I haven't
> really thought about it.
> I would also like to have a delay option, something like animate-delay: 2s;
> 
>> From your example, it is not clear when the animation should begin.

Transitions effects are indeed a good idea. But the proposed syntax is 
not really clear (sorry). I would propose something like:
   selector {
     transition-enter: sometransition;
     transition-leave: sometransition;
   }

Now when any element starts to validate the selector, the 
transition-enter transition is used. If later this element doesn't 
validate the selector anymore, the transition-leave is used. Let's take 
or usual css-driven menu example. Instead of:
   li>ul {
     display: none;}
   li:hover>ul{
     display: block;}
We would have:
   li>ul {
     display: none;}
   li:hover>ul{
     transition-enter: slide-in(top-to-bottom, 0.5s);
     display: block;
     transition-leave: slide-out(bottom-to-top, 0.5s);
   }

We could even put more than one transitions at once:
   li>ul{
     display: none;}
   li.opened>ul{
     transition-enter: slide-in(center-to-sides, 0.5s),
       animate(opacity, from(0) to (1), 0.3s);
     transition-leave: slide-out(sides-to-center, 0.5s),
       animate(opacity, from(1) to (0), from(0.2s) to(0.5s));
     display: block;
   }

Obviously, the syntax of the core transition is messy here, but you get 
the important point: the transition-leave and transition-enter. They 
trigger something when the element matches the selector for the first 
time, or stops matching the selector.

Note that the effect for the last example i gave was that, when an li's 
class change to something that contains "opened", it will:
  1-a) set display to block
  1-b) put the object in the state needed for the transition-enter 
animation. That means it will start fully transparent, and the visible 
area of the item will be a rectangle of 0*0px positionned in its 
(computed) center. Note that since it will be done _exactly_ at the same 
time as 1-a, the intended effect will happen, and the element will not 
be displayed even for a blink.
  2) then the transition-enter animation starts and complete. In this 
case, it will make the item's coputed opacity move from 0 to 1 in 0.3 
seconds, and make the visible area of the item will be a growing 
rectangle, from 0*0 at 0s, to 100%*100% at 0.5s (percentage of the 
item's computed width and heigth, respectively).
  3) then, since the transition has ended, the style will continue to apply.

When the class "opened" is deleted from the class attribute of the li, 
it basically goes the reverse way: the visible area of the item 
gradually reduces from a rectangle of 100%*100% to a rectangle of 0*0 in 
its center (in 0.5s), and in the meantime opacity goes from 1 to 0 in 
the last 0.3 seconds of the animation.

I still see some limitations to that:
  -it implies defining a whole new syntax for transitions. Implementing 
it would not be an easy task either.
  -it somehow duplicates some of the smil animation syntax, i believe, 
in a messy way. It would be better if we could specify those animations 
in a smil-compatible way.
  -Then, again, you won't ever be able to create a syntax for every 
effect that people designing websites will want. That is simply not 
possible. So people will still need scripts. Actually, script is needed 
for animation, except the most common cases (like in the example above). 
I know i will be scolded at, but I'm still sticking to scripts. I think 
there should be, at least, a way to specify original transitions in 
script, so that if the proposed transitions are not enough, webdesigners 
can create their own. The syntax I am thinking about right now is just 
some extension of the onevent: syntax i was talking about in the other 
topic: putting some script as the value of the transition-... properties.

The main problem with that is that it (besides putting script in CSS, 
wich is evil) creates a risk of infinite loops:
   .myclass {
     transition-enter: "this.className='';";	//leaves immediately
     transition-leave: "this.className='myclass';";	//re-enters immediately
   }
Now it makes a deadloop if any item ever happens to have 'myclass' in 
its classname. This is the main drawback of scripts as transitions in 
CSS. Besides their power, scripts allow deadloops. Then, it's not worse 
than any deadloop that can occur in a normal script, and if CSS and 
scripts are put together in a separate thread (wich should already be 
the case for scripts anyway, since scripts can create deadloops), the 
worse will be avoided.

Jordan Osete

Received on Tuesday, 9 May 2006 16:05:20 UTC