W3C home > Mailing lists > Public > www-style@w3.org > January 2013

Re: Programmable state-machines in CSS proposal

From: Clint Hill <clint.hill@gmail.com>
Date: Wed, 30 Jan 2013 08:18:53 -0700
To: Bobby Mozumder <mozumder@futureclaw.com>, www-style list <www-style@w3.org>
Message-ID: <CD2E8537.471B%clint.hill@gmail.com>
Bobby: This is something that Brian and I have wanted to tackle as well. We
created a project called Behavior Stylesheets nicknamed "bess"[1]. This
library provides nearly exactly the feature you describe here but with a
different approach in the syntax (targeting is done via selector functions
in properties). We would love for you to take a look and give us some
feedback. A related project that we have is called Hitch where we look to
extend the ability of CSS and provide the author the ability to do things
with CSS that aren't achievable in it's native implementations[2]. Our
ultimate goal is to move these two projects into a unified system.

We'd really love to get some feedback about these projects.


From:  Bobby Mozumder <mozumder@futureclaw.com>
Date:  Tuesday, January 29, 2013 5:59 PM
To:  www-style list <www-style@w3.org>
Subject:  Programmable state-machines in CSS proposal
Resent-From:  <www-style@w3.org>
Resent-Date:  Wed, 30 Jan 2013 10:51:37 +0000


A problem I've been dealing with in design is that the pseudo-class selector
:hover signals a state of an element, and that element is the only object
that style can be applied to.

For example, i can only affect the element that :hover applies to:

#myImage {
 color: #000000 ;

 #myImage:hover {
 color: #fffff;

I can't apply it to affect another completely separate element:

#myImage -->  #myOtherImage {
 color: #000000 ;
#myImage:hover -->  #myOtherImage {
 color: #fffff;

I would need to Javascript for this to happen.

This leads me to think that :hover should be a state definition instead of a
pseudo-class.  Which leads me to think that CSS should include state
definitions in general.

So, what's everyone's thoughts on separating state from style element, and
implementing a programmable state machine as part of CSS?  (I have a
hardware background so I speak in terms of state machines..)

A lot of jQuery scripts are based around elements affecting other elements,
for example, interactive elements that affect style of other elements like
scrollbars, graphs, buttons, etc..

Being able to measure state of one element and have it affect another
element would be tremendously useful in reducing all this jQuery scripting.
Having CSS implement a state machine as part of its syntax would pretty much
make it programmable.  The state machine would test not just for :hover
pseudo-class, but for any CSS property, or each element could define its own
properties.  This really needs programmable variables for it to work.
As a rough guideline start (that's very broken), the syntax would be along
the lines of:

 [element] { condition } --> [element] { newProperty }

The :hover pseudo-class should be a state property instead, and the above
example should actually be:

#myImage { mouse != hover } --> #myOtherImage {
 color: #000000 ;
#myImage { mouse == hover } --> #myOtherImage {
 color: #fffff;

Couple of other examples:

- Click on/off

#myImage{ mouse == click } && #myOtherImage{ visibility == visible } -->
#myOtherImage { 
#myImage { mouse == click} && #myOtherImage { visibility == hidden } -->
#myOtherImage { 

- Animation  (assuming some default timer)

#myImage { opacity < 1 } --> #myImage {
  opacity: #myImage{opacity} + ..01;

Anyways, a programmable CSS system is needed, as I fear Javascript is too
slow & power inefficient to handle complex interaction with high frame rates
for upcoming high complexity app-sites.  I could do everything with
Javascript/Jquery, but frame rates would be much slower while consuming more
power than if the browser could be programmed through CSS.

Bobby Mozumder
FutureClaw Magazine
www.futureclaw.com <http://www.futureclaw.com>
www.twitter.com/futureclaw <http://www.twitter.com/futureclaw>
Received on Wednesday, 30 January 2013 15:19:28 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:08:25 UTC