RE: [CSS3] transition effects

Hi Jordan,

We've also done some work in this direction, but our stuff combines animated
effects with XForms states. To give an example, whenever an XForms <case> is
toggled 'on' within a <switch> it receives the xforms-select notification
event, and the <case> that is being 'hidden' receives the xforms-deselected
event. Ideally these events would have a pseudo-class that mirrors them, but
whilst they don't, we do things like this:

  xf\:case
  {
    -event-xforms-deselect : fx-Effect-SlideUp(duration:0);
    -event-xforms-select   : fx-Effect-SlideDown(duration:1);
  }

The syntax for the effect is actually a copy of the Scriptaculous
functions...no coincidence since we've embedded the library into
formsPlayer, our XForms processor! But it's just an experiment, since
ideally some version of CSS would define a set of effects and which library
is used to implement them is immaterial.

As I said, the 'event name' syntax is just an experiment; I don't really
like making CSS rules aware of event names, so ideally I'd like to see
something like this defined:

  xf\:case:select
  {
    effect                 : slideup(duration:0);
  }

  xf\:case:deselect
  {
    effect                 : slidedown(duration:1);
  }

However, this means that you would need a 'state' (or pseudo-class) to
reflect every event, so as a quick way of getting access to effects in our
forms we just added this event name/function pairing.

To give a few more examples of the kind of thing that becomes easy in
XForms, to get the standard 'yellow fade' effect on *any* XForms control
whose value changes, we only have to do this:

  xf\:*
  {
    -event-xforms-value-changed : fx-Effect-Highlight();
  }

To fade from red on an *invalid* form control, we do this:

  :invalid
  {
    -event-xforms-invalid : fx-Effect-Highlight(startcolor: '#ff0000');
  }

Note of course the weakness of our temporary solution though, the
duplication; a control becoming 'invalid' always receives the invalid event,
but you don't need to monitor both the state and the event. As before, this
should ideally be something like:

  :invalid
  {
    effect : highlight(startcolor: '#ff0000');
  }

To see what we're doing in the context of real forms, see this:

  <http://skimstone.x-port.net/node/105>

Anyway, it's great to hear that people are talking about this kind of thing,
and we would love to see something like this in a CSS 3 module.

Regards,

Mark


Mark Birbeck
CEO
x-port.net Ltd.

e: Mark.Birbeck@x-port.net
t: +44 (0) 20 7689 9232
b: http://internet-apps.blogspot.com/
w: http://www.formsPlayer.com/

Download our XForms processor from
http://www.formsPlayer.com/

> -----Original Message-----
> From: www-style-request@w3.org 
> [mailto:www-style-request@w3.org] On Behalf Of Jordan OSETE
> Sent: 09 May 2006 17:05
> To: Martijn; www-style@w3.org
> Subject: 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 22:05:49 UTC