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

Laurens,

thanks, you are right. That's the way I did it. All extensions of CSS
pseudo-classes describe states and not actions. For instance, a CSS^NG
rule with the selector *:onclick(2n+1) specifies the styling for
elements that where clicked once, thrice, etc. A CSS^NG rule with this
selector does not match, if the element was clicked twice, four times etc.

> Also, styling and behaviour should be separated; the things that you
> currently can’t do with CSS should be solved with that in mind.

You mean that dynamic pseudo-classes in CSS like :hover were a bad idea?
I appreciate these dynamic pseudo-classes because you can specify
behavior rather easily without scripting. I definitely agree that
scripting is needed for many applications.

However, the goal of CSS^NG is to avoid scripting for as many
applications as possible using declarative rules. CSS^NG does not focus
on scripting like the Behavioral Extensions to CSS or XBL. Let the
author of a style sheet decide whether static styling and dynamic
styling should be separated or not.

Kind regards,
Christoph


Laurens Holst schrieb:
> 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
>>>
>>>
>>>     
>>
>>
>>   
> 
>