Re: Apple's Proposal for CSS Animation

On Nov 7, 2007, at 11:46 AM, Bjoern Hoehrmann wrote:

> The autostart semantics of animations are rather worrying. It seems
> quite likely that authors would want to trigger animations based on
> things not readily available through CSS selectors like DOM events; to
> accounts for those we'd have to constantly add new selectors...

Yes, please. More user action pseudo-classes in the selectors,  
please. Even if I never use animation or transitions (not that I  
won't, but just for the sake of argument), I want more of the user  
action pseudo-classes. Specifically:

:click
If ":active" = "mousedown", then ":click" would be a "mouseup". It  
would allow me to change the style of something as a result of that  
something being clicked on, and would permanently put that element  
into a "clicked" state. Similar to :visited, if :visited could be  
used on any element (can it?), except that :visited means you clicked  
or activated the element once per session, and :clicked would mean  
once per page load.

:visited
Should work on any element that has been clicked on our otherwise  
activated during the session, even if you went to another page and  
back. Should include such things as SELECT OPTION and SELECT  
OPTGROUP. Also :active should work on any element you are moused down  
on or otherwise activated, if it doesn't already.

:checked
This is in the LC for selectors already, but only for UI elements  
like checkboxes and radio buttons. Since it acts, in effect, as a  
toggle, it would be nice to be able to apply it to other elements as  
well, in order to toggle them between two different visual (or aural,  
etc.) states. The default on all other elements would be unchecked,  
of course.

:click-every[m + n]
Would allow for separate styling for every number of clicks in  
multiples of m, plus n number of clicks (where "n" is less than "m",  
and both would be non-negative). Thus, if I wanted to toggle between  
3 different visual states with each click, I would define them with  
":click-every[3 + 0]", ":click-every[3 + 1]", and ":click-every[3 +  
2]". Total number of clicks = ((number of completed iterations) times  
m) + n + 1. If we had this, then ":checked" on elements that start  
out as not-checked would  be equivalent to ":click-every[2 + 0]".

:dragging and :dragged-on
These would work on any HTML elements that are draggable, as they are  
being dragged or being dragged onto, assuming there is such a thing  
or that a "draggable" attribute is ever created for HTML.

:keydown and :keyup
These would be combined with other pseudo-classes, such  
as :focus, :active, and :hover, to register keyboard activity in  
those states. Optionally it could be used without them in order to  
register any keyboard activity on the page, but then it wouldn't  
really matter what you attached it to. That would, in essence, be  
equivalent to "body:focus:keydown" or "body:focus:keyup".


I see these as being useful for creating new UI elements or styling  
existing ones, without having to rely on JavaScript for applying the  
styles. Also, I use hover all the time, including to set the display  
attributes of child elements, and more events like that would open up  
more creative possibilities without having to rely on JavaScript for  
basic styling that responds to user interaction.