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

----- Original Message ----- 
From: "Jordan OSETE" <jordan.osete@laposte.net>


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

"The only thing that would be overridden would be another method defined
in the same CSS way, depending on the priority of the cascade:"

And this is not good I hink.  Again, code has its own inheritance rules
( think about e.g. Java classes, not only about ECMAScript ) and
CSS cascading here will create just a mess.
I mean that as a rule you will want to define onMouseHover and onMouseLeave
and it is not good if e.g. someone will override (by CSS) onMouseHover
and will left onMouseLeave in place.

There are two solutions here as far as I can see:

1) To drop flat structure of the CSS style definition so e.g. background
or the behavior will be defined as:

div#myid{
   background: {  image:url(...); repeat: no-repeat; width:.. height: ...; 
x:...; y:...  }
   behavior: {  on-mouse-enter: "..."; on-mouse-leave: "..." }
}

This way background and behavior will be overrided atomicly
by later definition like:

div#myid{
   background: {  color: red; }
   behavior: {  on-click: "...";  }
}

2) To define behavior (precisely: to bind matching element  to
some "behavior" implemented elsewhere ) by just some single abstract name.
Main idea here - CSS should not know anything about DOM events.
DOM events are seperate entity and defined in different specifications.
(Loosely coupled specs have better chance to survive)

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

Well, "this horse is beaten to death already" as they say.
Presentational style, behavioral style - who will draw border
between them?

Animation ( e.g. sliding transintion from collapsed to expanded state ) -
is it presentational or behavioral?

Things like "pure CSS menus" - are they presentational or behavioral?
( http://www.meyerweb.com/eric/css/edge/menus/demo.html )

The only fact which is known pretty well : in UI presentation and
behavior are closely related to each other. At least presentation layer
shall know about possible states element/behavior can be in.

OT #1: I think that we need to define meaning of 'presentation' word
in context of CSS,  in real life presentation means some
dynamic process / act. But for some reason in CSS related
discussions 'presentation' means something close to 'rendereing'
(like static snapshot).
For example why CSS purists think that pure CSS popup menu
is presentational thing and select with popup list is not?

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

Yep, I trust you personaly, but see above.

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

OT  {

  I did this in my h-smile engine (htmlayout/sciter) by introducing
  'transition' css attribute.

  transition: none/blend/slide;

  It defines style of transition of the element from one state/style to 
another.

  In ideal world such transitions shall not be a business
  of the script.

}

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

Andrew Fedoniouk.
http://terrainformatica.com

------------------------------------------------------
In h-smile engine there are no dedicated <input> elements.
<input> there is just a plain DOM element with correspondent
behavior applied through the "master style sheet". It has lines like:

   input[type="text"] {  ...; behavior: edit;  }

And it is perfectly fine there to define:

#mytable td { behavior: edit; }
to transform the table into
something like "editable grid".

URL is:
http://www.terrainformatica.com/htmlayout/HTMLayoutDemo.zip
Folders:
  html_samples/behaviors/
  html_samples/animations/

Source of various behaviors are in full SDK distribution:
/include/behaviors/*.cpp

-------------------------------------------------EOF

Received on Saturday, 6 May 2006 20:12:20 UTC