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

Laurens Holst wrote :
> As far as scripts in CSS go, I think that IE’s ‘expressions’ shows that 
> it’s extremely hard to implement this while still performing well.

Not sure about that. AFAIK, IE's expressions are expressions that need 
to be automatically updated for each element they are applied to, each 
time something changes. That is probably the source of the performance 
problems.
But CSS-driven events are just some CSS properties that depend on 
existing cascading rules. Each item has a computed CSS value for 
"onclick", and that will be called each time the event happen.

> Also, styling and behaviour should be separated; the things that you 
> currently can’t do with CSS should be solved with that in mind. Some 
> examples:
> 
> - a ‘push’ button effect using :active currently only works on elements 
> that can be activated. OTOH, maybe this is good, because if the script 
> that handles the click is disabled, there is no point in having the 
> styling layer still pretend that something is being clicked. I don’t 
> know what XBL can do here, but I’d say it would be nice if the scripting 
> layer could control an element’s :active state.

If a state should be activated with scripts, we can just create a class 
'activated' or so, and apply the css to elements who match rules with 
that class. I don't know if it's the "right" way to do things, but if 
scripts could change some pseudo-classes values that should normally be 
kept track of by the browser, that could make the whole thing quite more 
complex (unless you override the whole behavior of an item).

> - transition effects; it’s fine for the CSS to specify transition 
> effects (actually, that would be great to have!), e.g. with an 
> imaginative ‘animate-properties: background-color, left, top’, but this 
> should be done based on state. The behavioural layer (script) can then 
> take care of the real behavioural stuff, being the changes in state.

Transitions are indeed a good idea. Actually they are so much of a good 
idea that I would (almost) even forget about the onevent: syntax i was 
talking about before. I will answer it in the "transition effects" 
thread soon.
As for behavior in CSS, there is something not to forget: if the author 
of a page wants some visually appealing effect on mouse over, on click, 
or on anything with some elements, and if he cannot do this with pure 
CSS (wich is the actual case, since you cannot put scripts in CSS, nor 
animations or anything), then he _will_ do this in a separate script 
file. Wich means he will, as well, put presentationnal stuff where it 
shouldn't be.

On the other hand, if script inclusion can be done with CSS, he will be 
able to include animations scripts with the following advantages:
  -if more than one CSS styles are possible for a same page, the 
animations will change "on the fly" when selecting another style. This 
would be easyly possible with the @script-onload {...} and 
@script-onunload {...} that i proposed before. Also, when disabling CSS, 
it will only disable the scripts used for presentation, meaning that 
other scripts still work (well, in practice that will not happen very 
often).
  -the author of a page can, with this, easyly separate behavior from 
presentation. That is because "behavior" doesn't equal "script" and 
presentation doesn't equal "CSS properties". That is also what i meant 
before, and what Andrew Fedoniouk told just better than me: the line 
between presentation and behavior is subjective, and depends on the 
application. The idea would be here to let the developper decide, 
instead of forbidding him to do something he would want to do.
  -the four syntaxes onevent:, @script, @script-onload and 
@script-onunload are easy to understand and to use, and they allow 
overriding of some event handlers while keeping others (wich is, afaik, 
not the case with behavior: or XBL). That can be useful in a lot of 
situations.

But of course there are also some concerns:
  -overriding scripts incorrectly can make some page buggy, so the 
developper will need to test extensively his styles.
  -since this would allow script inclusion in CSS, this is a potential 
security threat. This is because often, sites like CSSZenGarden allow 
anyone to submit stylesheets, so anyone could then execute scripts with 
the privileges of the calling page. This can be avoided by, for example, 
only executing scripts in CSS file wich are trusted. Those files could 
be linked with "text/css+script" instead of "text/css", for example, to 
keep the compatibility with older browsers and pages: browsers wich 
don't understand "text/css+script" just won't load the stylesheet.

Well, i hope i have forgotten nothing.

Jordan OSETE

Received on Tuesday, 9 May 2006 14:22:50 UTC