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

----- Original Message ----- 
From: "Martijn" <martijn.martijn@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.

Let's imagine that we have 'behavior' CSS attribute with syntax:

behavior: 'check'  || 'radio' || etc.

And somewhere in the specification to have definition like this:
<definition>
behavior:check triggers value of :checked state flag so
each even element activation sets :checked to 'true' and each
odd activation sets it to 'false'.
</definition>

This way you will have your :activated done. Also this
will allow to implement "collapsible trees" and many other things.

behavior: radio can be used for implementation of  tabular views
and other similar effects.

In fact list of typical behaviors is pretty limited - 6 or so and
they can be well formalized. Having them will eliminate many
cases when we need script now.

Andrew Fedoniouk.
http://terrainformatica.com


|
| > 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 22:10:31 UTC