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:31:34 -0700
To: Brian Kardell <bkardell@gmail.com>
CC: www-style list <www-style@w3.org>, Bobby Mozumder <mozumder@futureclaw.com>
Message-ID: <CD2E8A9B.473B%clint.hill@gmail.com>
Bobby: You should also look to join the Extensible Web community group -
http://prollyfill.org/. We're always looking for things like this in that
group.

From:  Brian Kardell <bkardell@gmail.com>
Date:  Wednesday, January 30, 2013 8:28 AM
To:  Clint Hill <clint.hill@gmail.com>
Cc:  www-style list <www-style@w3.org>, Bobby Mozumder
<mozumder@futureclaw.com>
Subject:  Re: Programmable state-machines in CSS proposal


Quick note: bess was a poc clint and I did a few years ago at work which we
just recently got cleared to move to open source...it isn't currently in a
great state as we are still in the process of refactoring out of concepts
from the work code.

Brian Kardell :: @briankardell :: hitchjs.com <http://hitchjs.com>

On Jan 30, 2013 10:20 AM, "Clint Hill" <clint.hill@gmail.com> wrote:
> 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.
> 
> [1]https://github.com/bkardell/bess
> [2]http://hitchjs.com/
> 
> 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
> 
> Hi,
> 
> 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 { 
>   visibility:hidden;
> }
> #myImage { mouse == click} && #myOtherImage { visibility == hidden } -->
> #myOtherImage { 
>  visibility:visible;
> }
> 
> - 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
> ---
> Bobby Mozumder
> Editor-in-Chief
> FutureClaw Magazine
> mozumder@futureclaw.com
> 1-240-745-5287 <tel:1-240-745-5287>
> www.futureclaw.com <http://www.futureclaw.com>
> www.twitter.com/futureclaw <http://www.twitter.com/futureclaw>
> 
Received on Wednesday, 30 January 2013 15:32:06 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:21:04 GMT