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

Re: [CSS3] transition effects -why not use proper scripting backed up by the correct DOM methods?

From: Jordan OSETE <jordan.osete@laposte.net>
Date: Wed, 10 May 2006 11:43:52 +0200
Message-ID: <4461B5D8.2050009@laposte.net>
CC: www-style@w3.org

Andrew Fedoniouk a écrit :
>> That is exactly why events in CSS are here for. I am sorry i have not 
>> explained this well, but it's possible with that. If the script taking 
>> care of animations, transitions or whatever are with the main 
>> "behavioral" script (as it is the case right now, since there is no 
>> way to separate them), then there is no way for the UA to understand 
>> wich script does what. If you allow to put script in CSS, then the 
>> user agent can just have a "disable scripts defined in CSS" option, 
>> that will just do what you want.
>>
>> Jordan Osete
>>
> 
> I have two objections to scripts inlined in CSS:
> 
> 1) Too easy to abuse. You'll see a lot of things in such inline scripts
> what you will not expect to be there.

Yes, but that is the developper's duty to make sure he does things right
and puts the scripts where they should be. Right now, webdeveloppers are
forced to include presentation in the main scripts, it is not good
either. If we allow the choice (scripts in CSS or scripts in the page),
we at least allow them to really separate presentation and behavior.
Then they can put presentation things (scripts and CSS properties)
somewhere in the CSS, and behavior (elements and scripts) elsewhere, in
the core of the page. I think the current situation is worse, because it
forces the wrong way of mixing everyghing.

> 2) Embedding two (possibly more) different but close
> syntax constructions into one chunk of text is difficult
> (read: expect unreliable implementations) and sometimes
> is just impossible. E.g. think about string literals in script code
> and rules of escapement in this case.

Embedding scripts in CSS forces some limitations, unfortunately.
Still, the BECSS draft [1] gives a good syntax, and a good summary of
those limitations, i think:

@script "text/javascript";  /*specifies the default script language*/
@script "text/javascript" url("myscript.js"); /*loads script file*/

@script {		/*  inline script  */
   if(window.something){
     var count = 0;}
   ...some more script...
}

It states explicitly:
<< While the contents of an @script block is scripting language
dependent, parentheses (( )), brackets ([ ]), braces ({ }), single (')
and double quotes (")  must always occur in matching pairs. Any
unmatched occurrences of these characters must be escaped. Scripts
within @script rules are evaluated once per document when the containing
style sheet is first applied to the document. >>

As for simple onevent attributes, the script can just be enclosed in
double quotes (like it is for inline onevent attributes specified in
html). I don't know if it would be wise to enclose it in single quotes,
though. Existing implementations might not like it. Then if it is not
enclosed in any quotes, it would be considered a simple function name to
call on event.

Then, if a simple string is not enough to define behaviour, have it call
a function defined in an @script block. And if the script is really
huge, we can still put it in external .js files, and include it with
@script "myjsfile.js";

If we were to allow as well @script-onload, and @script-onunload, they
would have the same syntax and limitations as a simple @script block.
While transitions, if allowed, would have a syntax compatible to those
of onevent.

> ----------------------
> I tried in fact "to marry" CSS and JS once - idea was
> close to yours (more ambitious I would say):
> 
> #something
> {
>    color: black;
>    onclick: function( el )
>    {
>        el.text = "Got click";
>        el.state.active = true;
>    };
> }
> #something:active
> {
>    color: red;
> }
>

I don't know if scripts are the right thing to do states changes, at
least in this way. As i said in a previous mail, it could conflict with
the browser, (since states changes are usually handled by the UA),
unless you can override the whole behavior of something (but this is a
more complex task, and XBL or something like that is more suited for
that). For now I will stick to classes for that, since to allow or not
the scripts to change states of an object is a different matter.

> Got a picture at the end:
> "Mortification of Beatiful Idea by Disgustful Fact".
> CSS notation especially things like font shortcut attribute and
> funny nmtokens with minuses inside - it does not work to be short.

With the proposed syntax, you could do:
   #something {
     onclick: "this.text='Got click';
       this.className='active';";
     /* or call a function defined elsewhere */
     onclick: handleClick; /*overrides the onclick property above */
   }

   @script {
     function handleClick(){
       this.text="Got click";
       this.className="active";}
   }

Well actually in that particular case, if the item may have another
class, you would create and use some function like addClass or
something, to avoid overriding the existing classes.

Jordan OSETE

[1] http://www.w3.org/TR/1999/WD-becss-19990804
Received on Wednesday, 10 May 2006 09:43:11 GMT

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