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: Mon, 08 May 2006 00:30:12 +0200
Message-ID: <445E74F4.8090109@laposte.net>
To: Andrew Fedoniouk <news@terrainformatica.com>
CC: www-style@w3.org

syntaxes?
Andrew Fedoniouk wrote :
 >> 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.
 > For example why CSS purists think that pure CSS popup menu
 > is presentational thing and select with popup list is not?

You got me there.
I guess i got a little carried away, this is my "CSS purist" side ;)
I agree that presentation cannot always be completely separated from 
behavior; still, a well designed web application will allow what we 
could call "CSS skins", that change the apparence, animations (with 
scripts), and possibly slightly the behavior (with scripts as well), 
without changing what the application fundamentally does.

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

Yes, but it can sometimes be useful to be able to override only one of 
the two. For example let's say a simple link with class "anibg". There 
would be a behavior.css file, that is always included, and an optionnal 
skin.css.
On behavior.css, we define something like that:
   .anibg {
     onmouseover: "this.tid=setTimer(animatebg, 100, true, [this]);";
     onmouseout: "clearTimer(this.tid);";}

Now we can just have, in our skin.css, something like:
   .anibg {
     onmouseover: "this.tid=setTimer(animatebg2, 200, true, [this]);";}

Since the only change are the interval (from 100 to 200) and the name of 
the callback, there is no need to redefine the onmouseout, wich would be 
the same as in behavior.css.
Of course in this very simple example, it wouldn't be too hard to 
replace the onmouseout, but this is to show why i think assumptions like 
that can be dangerous. Another example would be for the onmousedown and 
onmouseup events. Since they can be used for drag & drop, we could 
consider to link them and force the redefining of both at the same time. 
But this is just making an assumption. If for some reason the person 
only wants to activate drag & drop on doubleclick, then it is useless 
forcing the person to define an onclick event.

It would also be not consistent with other event models, since neither 
in the DOM nor in the event attribute syntax you have to define both 
events at the same time.

> 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:
>   [some code here]
> This way background and behavior will be overrided atomicly
> by later definition.
> 
> 2) To define behavior (precisely: to bind matching element  to
> some "behavior" implemented elsewhere ) by just some single abstract name.

As I explained above, this is not needed if we let the developper change 
the events as will. This may also be too complex (see previous mail) for 
the simple purpose.
I think it is the developper's duty to check that the application he 
writes is well-written and can be easyly extended, and the CSS 
designer's duty to check that the CSS he writes is compatible with the 
application and has the expected effect (in case they are two different 
people, of course).
It would be only restrictive to force the changing of both events at the 
same time (or of all the events, with a behavior). And even if we force 
it, there is no guarantee that the result will be correct if the 
person(s) who creates the application doesn't test it enough.

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

I agree. The onsomething: event in the CSS doesn't depend on the 
onsomething event specified with the DOM or html attributes. If there is 
a CSS event, it will be called, wether there is(are) the same event(s) 
defined in another way or not. Same goes for DOM and attributes 
specified events.

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

Interresting idea, but isn't there a risk to conflict with future CSS, 
if a "transition" property with different meaning or syntax is defined 
in the future?

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

Maybe, but what if the designer wants a transition that isn't 
implemented by default? Designers nowadays have tons of imagination...

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

Again, that fits perfectly the need of an application, but it is too 
complex for the purpose of defining simple scripts for the web, and 
even- more-too-complex for simple animations. ;)


By the way, you are developping an UA, right? How hard would it be to 
implement the four following syntaxes?:
   onevent: something;
   @script "text/javascript" {...}
   @script-onload {...}
   @script-onunload {...}

I said before that it wouldn't probably take too much time and effort 
(well, "too much" is quite subjective here...), because only the 
existing CSS parser and script engine would be needed, but I may have 
been completely wrong.

Jordan OSETE
Received on Sunday, 7 May 2006 22:27:00 GMT

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