W3C home > Mailing lists > Public > www-style@w3.org > May 2006

Re: [CSS3] transition effects

From: Laurens Holst <lholst@students.cs.uu.nl>
Date: Sun, 14 May 2006 13:59:00 +0200
Message-ID: <44671B84.205@students.cs.uu.nl>
To: Mark Birbeck <mark.birbeck@x-port.net>
Cc: www-style@w3.org
Mark Birbeck schreef:
> 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:
>   

Yes, for ‘events’ one should utilise the CSS pseudo-classes that result 
from it.

>   xf\:case:select
>   {
>     effect                 : slideup(duration:0);
>   }
>
>   xf\:case:deselect
>   {
>     effect                 : slidedown(duration:1);
>   }
>   

I think the ‘slideup’ or ‘slidedown’ are particularly bad ideas -_-;;. 
In my proposal you would just animate the ‘top’ or ‘bottom’ properties 
from their original values to a new value, and the animation properties 
have no sense of direction. Animating ‘top’ and ‘left’ at the same time 
would allow animation in any direction, not just up and down.

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

Well, you should not use events directly... Basically, CSS describes the 
state an element is in, and not the events that drive it. In your 
example, there should be no :deselect or :select ‘event-states’, but 
simply a :selected. CSS3 UI already defines a lot of these states, such 
as :checked which is awkwardly named but I think basically the same as 
:selected.

> 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();
>   }
>   

Ah, well, ‘flashing’ animations is something my proposal indeed doesn’t 
catch directly. My proposal is simply to have the usual CSS styling 
changes by state, but animate them instead of make them happen instantly.

I could imagine something complex that would make different kinds (e.g.) 
flashing animations possible as well:

  :changed {
    animate-pattern: flashing;
  }
  @animation-pattern flashing {
    @animation-position 50% {
      color: yellow;
    }
  }

This would animate from the current colour to yellow to the current 
colour again. If :changed has a color property set and 
animate-properties: color, then it would animate from the old colour to 
yellow to the new colour.

But maybe it should rather be something like this, where the application 
changes into a state like :changed temporarily (temporarily? sounds like 
a bad idea), so that accessibility applications can also act differently 
on the change in state:

  :changed {
    animate-properties: color;
    color: #ffff00;
  }

Anyway, I actually think that for animations as complex as that, CSS 
isn’t the place for it, and they should rather be done in SMIL or a 
similar language. And if that’s not an option, they can always be 
achieved using the declarative animations I specified and changing 
states and classes in script.

So basically ignore the two examples I gave above, I think they should 
not be in CSS :).

> 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');
>   }
>   

In my proposal:

:invalid {
    animate-properties: color;
    color: #ff0000;
}

And it will animate from the colour that was set before it became 
invalid to #ff0000, like it normally would do on UAs that wouldn’t 
support this, but then without animation.

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

Agreed :).


~Grauw

-- 
Ushiko-san! Kimi wa doushite, Ushiko-san!!
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Laurens Holst, student, university of Utrecht, the Netherlands.
Website: www.grauw.nl. Backbase employee; www.backbase.com.




Received on Sunday, 14 May 2006 11:59:01 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 27 April 2009 13:54:45 GMT