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

Re: [CSS3] What about "behavioral extensions to CSS"?

From: Jordan OSETE <jordan.osete@laposte.net>
Date: Sat, 06 May 2006 11:58:59 +0200
Message-ID: <445C7363.8000509@laposte.net>
To: www-style@w3.org

Andrew Fedoniouk wrote:
> As a rule such event handlers constitute closed system of functions - a.k.a. as class. And div {
>       onclick: "handleClick(this)";}
> allows you override methods independently which is wrong.

If I understood it well, in that case, the method defined in the CSS 
"onclick" doesn't override the onclick attribute and/or events defined 
in another way. If there are events defined in another way, they will be 
called as well, in an arbitrary order.
The only thing that would be overridden would be another method defined 
in the same CSS way, depending on the priority of the cascade:

(X)HTML:
     <div id="myid" onclick="method1(this)">...
CSS:
     div#myid{
       onclick: "method2(this)";
       onclick: "method3(this)";}

Here both method1 and method3 would be called, but not method2 because 
it is overridden by method3 in the cascade.

> Better approach is to use
>  div {...
>       prototype: MyBehavior; ....}
> 
> and in script to define:
> var MyBehavior = {
>     onClick: function() {...}       onMouseHover: function() {...} }

I don't know. This way you define the way the application reacts (well, 
its behavior), but CSS' duty would be to only affect presentation, 
wouldn't it?

Note that by defining scripts in CSS, I was only referring to scripts 
used for presentation.

I will take a simple example of why such kind of scripts should be 
specifiable in CSS.
Imagine a website with two (or more) different stylesheets, in wich the 
user can choose the one he likes better. It is often the case in many, 
many websites using CSS nowadays, for example CSSZenGarden (for CSS 
demonstration purposes only), or howtocreate [1].

Now the web developper wants to put animations here and there - menus 
that appear or fade out, some links whose background scrolls slowly when 
mousing over them, etc. - these animations will be done with scripting, 
hopefully in a non required way (ie. if the user disables scripts, the 
website is still functionnal, though it doesn't look as good).

Now what if he wants to have different animations for different styles?
It is obvious why he would want that: depending on the design, some 
animation can either look good or bad on a particular element. Right 
now, the only way to do that is to detect wich CSS file is used in his 
scripts, and call different functions each time. Worse, if styles are 
switched while some animation is running (for example with a timeout), 
he will have to check in each function called by a timeout if the 
choosen CSS file has not changed. That is unnecessaryly complex.

If you can specify scripts in CSS, it solves all of these problems at 
once. In addiction to the "@script{}" and "onevent:" syntax, I proposed 
earlier some other syntaxes:
   @script-onload {...} and
   @script-onunload {...}
With this, we can easyly specify things to do when the CSS file is 
loaded and unloaded, like clearing timeouts.

Kornel Lesinski wrote:
> This is implemented already:
> http://jquery.com/

Andrew Fedoniouk wrote:
> I think that it makes sense to take a look on
> Ben Nolan's work: http://bennolan.com/behaviour/ - same approach is used.
> 
> Andrew Fedoniouk.
> http://terrainformatica.com

Again, though these two libraries look good, it still doesn't allow you 
to specify different scripts for different CSS files in such an easy 
way. To me, it seems more like those kind of libraries exist somehow for 
the purpose of replacing the missing @script and onevent: functionnality 
that I am asking for (though they have other uses as well).
By the way, the getElementsBySelector method used in the second library 
should really be integrated to DOM, it would be really useful.

Jordan OSETE

-------
[1] http://www.howtocreate.co.uk/
Received on Saturday, 6 May 2006 09:58:54 GMT

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