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