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

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

From: Laurens Holst <lholst@students.cs.uu.nl>
Date: Tue, 09 May 2006 13:29:35 +0200
Message-ID: <44607D1F.8070506@students.cs.uu.nl>
To: Christoph Wieser <wieser@cip.ifi.lmu.de>
Cc: www-style@w3.org, Francois Bry <bry@ifi.lmu.de>
Christoph Wieser schreef:
> 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.
>   

I think that if you use this onclick you propose in applications in 
practice, 99% of this can be caught entirely in states (as-in on/off, 
true/false, maybe some tri-states), and this is purely a behavioural 
extension to CSS.

For example, collapsing and expanding some kind of navigation panel. 
When the head is clicked, it expands, and when it is clicked again, it 
collapses. With your model available, you would use ‘:onclick(2n)’ and 
‘:onclick(2n+1)’ to achieve this.

In the model as it should be, scripting (or some other behavioural 
language) is used to bind the user interaction (the click) to a change 
in the state (in this case, toggle the selected state). The styling then 
styles purely based on whether the control is in ‘:selected’ (whatever 
it’s called) state or not, and whether it is or not does not depend on 
whether it is clicked once or twice or thrice, but on whether the 
behavioural layer put it into selected state at some point (e.g. it 
might also happen after a timeout, or by keyboard navigation).

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

No, I do not mean that at all.

Behaviour is the definition of how user interactions influence the 
model, it couples user interactions to actions and state changes. E.g. 
click on this button and this file is loaded, or this element is 
activated, or this control is put in selected state.

Technically spoken, yes there is some behavioural binding for ‘when the 
mouse is over this element, the :hover state is set’, however this is a 
convenient predefined state-change in the CSS implementation itself, and 
the CSS only defines the styling of the different states. This is no 
different from for example the state change for :checked being 
implemented by the host language (like HTML) automatically and you 
usually do not need to specify the state change explicitly in your 
scripts. The reason why it is reasonably OK for :hover’s behaviour to be 
part of the CSS specification is that in the end, :hover is simply used 
as a common stylistic effect.

I see your point in that :hover is not all that different from 
:onclick(), but once you start adding and using :onclick(1), etc. I 
think you’re moving too much of behavioural code into CSS. It’s not 
scripting —which is why expression() is bad, which is what I was mostly 
referring to—, but it’s getting way closer as you can very easily define 
different handlers for different user interactions (e.g. make it have 
steps in a wizard), basically allowing people to iteratively change the 
application through CSS, and that’s just the wrong place to do that.

Instead this should be handled by the host language or a behavioural 
layer therein (e.g. Javascript of XBL), and they should couple the 
number of clicks to changes in state, e.g. for the wizard functionality 
remove the ‘selected’ state and put it on the next element in the list. 
The CSS can then style the wizard pages to show or hide based on whether 
they are selected or no.

Basically, what I’m saying is that in some very small cases :onclick() 
could be useful, but in the majority of cases it can either be done with 
one of the existing (or maybe new) states, or it is behaviour defined in 
CSS. And that is why it should imho not be part of CSS.


~Grauw

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




Received on Tuesday, 9 May 2006 11:39:40 GMT

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