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

Christoph,

I think if anything, what you propose should work based on *states* 
(such as the existing :active, :selected, whatever) and not operations 
such as ‘click’. That way, the styling can be changed by setting a 
different state on the base element, all subelements will style 
accordingly, and the correct styling can be resolved at any time based 
on the current state, instead of retracing the number of clicks that 
have been done, etc.

This is a much more solid method, and will cause much less bugs and 
problems in the styling. E.g. try to create a ‘button push’ effect using 
JavaScript, I promise it’ll give you headaches because you treat the 
separate events individually, while it’s trivial to do using CSS its 
‘:active’ pseudo-class.

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.

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.

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


~Grauw

Christoph Wieser schreef:
> Hello,
>
> just like me, :). The "Behavioral Extensions to CSS" would be beneficial
> for many applications! I just finished my diploma thesis about extending
> CSS with dynamic document rendering features (supervisor François Bry).
>
> The set of extensions is called CSS^NG. CSS^NG is rather similar to the
> "Behavioral Extensions to CSS". The main goal of CSS^NG is to make
> scripting languages unnecessary for as many applications as possible.
> The following examples demonstrate one feature of CSS^NG:
>
> ---- Example 1: Dynamic Styling --------------------------
> a:onclick(1) { color: green; }
>
> After one click on an HTML anchor its color changes to green.
> ----------------------------------------------------------
>
> ---- Example 2: Dynamic Styling using CSS Combinators ----
> tab:onclick(2n+1) + * { display:none; }
> tab:onclick(2n+2) + * { display:block; }
>
> After an _odd_ number of clicks on a tab element
>  the following sibling is _"folded"_ and
> after an _even_ number of clicks on a tab element
>  the following sibling is _"unfolded"_.
> ----------------------------------------------------------
>
> These examples are taken from the following paper:
> http://www.pms.ifi.lmu.de/publikationen/PMS-FB/PMS-FB-2006-9/css-ng.pdf
>
> The diploma thesis with details on CSS^NG can be found here:
> http://www.pms.ifi.lmu.de/publikationen/diplomarbeiten/Christoph.Wieser/thesis.pdf
>
> I hope that CSS^NG can revive the discussion on dynamic styling of Web
> pages.
>
> Kind regards,
> Christoph
>
>
> ----
> Christoph Wieser
> http://www.wieser.info
>
>
>
>
> Jordan OSETE wrote:
>   
>> Hello everyone,
>>
>> I was wondering what was going on about the "Behavioral extensions to
>> CSS" working draft [1]. It hasn't been updated since 1999, but it seems
>> very interresting extensions to me.
>>
>> Specifically, in the first part, the "Event Properties", and "Script
>> blocks" paragraphs seem to me quite stable, and maybe not too hard to
>> implement by user agents (since they only use existing technologies: CSS
>> parser, script interpreter, and events). It would also help
>> webdeveloppers a lot.
>>
>> Why hasn't this WD been updated since then? Is no one in the W3C
>> interested in it, or is it because of technical difficulties at the time?
>>
>> The "Open issues" part at the end of the document says that:
>> 1.    it depends on the DOM Level 2, wich was a WD at the time, but is
>> now a Recommendation, so this point is now useless, and that
>> 2.    the order of event handler invocation needs to be specified (in
>> wich order the DOM events, events specified in HTML attributes and
>> events specified in CSS will be called). I don't know if it is that
>> important to specify a specific order now. Maybe it could be left to the
>> UA, or if the developper really needs a specific order (wich will
>> probably be very rare), he would tell it in the CSS. I see 2 easy ways
>> to do this:
>>   a) on a per-event basis, after the quoted script, like this:
>>     onclick: "myEventListener(this)" order(attrEvents, CSSEvents,
>> DOMEvents);
>>   b) Or on an element basis:
>>     div {
>>       onclick: "handleClick(this)";
>>       onmouseover: "handleMouseOver(this)";
>>       eventsorder: attrEvents, CSSEvents, DOMEvents;
>>     }
>>
>> Hope it helps.
>>
>> Jordan Osete
>>
>> ---
>> [1] http://www.w3.org/TR/1999/WD-becss-19990804
>>
>>
>>     
>
>
>   


-- 
Ushiko-san! Kimi wa doushite, Ushiko-san!!
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Laurens Holst, student, university of Utrecht, the Netherlands.
Website: www.grauw.nl. Backbase employee; www.backbase.com.