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

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

From: Martijn <martijn.martijn@gmail.com>
Date: Mon, 8 May 2006 17:39:33 +0200
Message-ID: <6c97b8b10605080839l238aca87x1969b88714317ac1@mail.gmail.com>
To: "Laurens Holst" <lholst@students.cs.uu.nl>
Cc: www-style@w3.org

On 5/8/06, Laurens Holst <lholst@students.cs.uu.nl> wrote:
> 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.

Well, kinda off-topic maybe, I think I would like to have :activated
pseudo-class then, where one time activating (clicking) makes it
:activated and another time clicking makes it deactivated. It would be
more or less be like :checked, except :checked can only be used for
elements that can be in the :checked state, which are only checkboxes
and radio buttons in html, afaik.

> 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

In Mozilla there doesn't seem to be any limitations on which elements
can be :active.?
Afaik, all elements in Mozilla that are stylable can be :active.
Even something like <input type="text" disabled> can be :active in Mozilla.

CSS2.1 has this to say:
http://www.w3.org/TR/CSS21/selector.html#dynamic-pseudo-classes
"CSS doesn't define which elements may be in the above states, or how
the states are entered and left."
So, afaict, user agents may decide for themselves which elements can
be :active. It doesn't even precisely define in what ways you can
activate an element (it only gives an example).

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

Not sure what you mean here, you mean a script should be able to make
an element :active?
I tried this: http://wargers.org/mozilla/domactive.htm
I thought dispatching a DOMActivate event might do the trick in
Mozilla, since DOMActivate seems equivalent to :active for me.
It doesn't work, which I more or less expected, but I can also see a
problem. How long should the element in question be :active when a
DOMActivate event is dispatched to it?

Regards,
Martijn

> - 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.
>
>
>
>
Received on Monday, 8 May 2006 15:39:43 GMT

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