Re: Are CSS animations a done deal?

On Tue, 06 Apr 2010 20:58:27 +0200, Lars Gunther <gunther@keryx.se> wrote:
> 2010-04-05 18:07, Anne van Kesteren skrev:
>> It also re-invents CSS syntax elsewhere for no good reason. It actually
>> has a higher barrier to entry for designers, who would need to learn
>> ECMAScript.
>
> I think not. They would only learn how to put key-value pairs in JSON, a  
> /very/ small subset of ECMAScript, very similar to CSS.
>
> The point being is that it is now an object that can be applied to any  
> event.
>
> And we do not need to differentiate between on-entry and on-exit. We  
> have those already:
>
> - focus/blur
> - mouseover/mouseout (mouseenter/mouseleave would be a better fit, but  
> there is no universal support yet, though)
> - mousedown/mouseup
> - load/unload
> Etc.

You can do the same with class names and some script and then you don't  
have to learn key-value pairs in JSON. I don't see the point.


>> It also fails to separate logic and style, by putting all
>> kinds of stylistic information in the scripting layer. E.g. colors, etc.
>
> If scripts start with a JSON-definition section or if those are kept in  
> a separate file, there is still separation of concerns and logic.
>
> I think that it is telling that in the long threads about CSS animation  
> syntax nobody is addressing probable real world use cases:
>
> - S5 presentations, where slides and bullet points animate.
> - Prezi-style animated presentations.
> - Image slideshows.
> - Advertising (yes, that is where well see much of this being put to  
> use!)
> - Notifications information sent from the server (EventSource and XHR)
> - HTML5 details (yes, designers are going to want to control the effect)
> - Various forms of menus.

I don't see why this wouldn't work. You might need some script, but that's  
not a problem.


> And of course:
> - Switching between pages on a site. Why not animate the whole page?

These seems somewhat fundamentally different and would require a separate  
solution regardless of how we go about things.


> While I am at it, I was asked about when animation carry information and  
> is not purely decorative.
>
> First of all, who could imagine Bespin when Canvas was first thought up?  
> Yet, here we are with endless discussions about how to make canvas  
> accessible.

Bespin is not really a good example of why <canvas> needs to be  
accessible. Bespin demonstrates how awful contenteditable="" is or how  
non-existent highlighting support is for e.g. <textarea>.


> I think it is quite easy to imagine information coming in and out of  
> view, using animations. The user pushes a button or moves the pointer  
> and large parts of the information on the screen has changed. If that  
> occurs using CSS-animations only, how would non-sighted users know?
>
> We have seen examples of a Star Wars walker, done using CSS-animations.  
> The technique is powerful. Is it that hard to imagine someone using it  
> to convey information?

No, but I'm not seeing your point.


> Yes, it brakes the model of what one is supposed to do using CSS, but it  
> will happen. Why not prepare for it?

I'm not sure it breaks the model. Animation seems an essential aspect of  
presenting information.


> Or should that preparation just be to add a few sentences like this to  
> the spec:
>
> "Animations is a technique intended for presentational purposes only.  
> Under no circumstances should authors attempt to use it to convey any  
> information. And all ninjas be damned if they try!"

I'm still not sure what your point is, but you will have exactly the same  
problem if you move everything to JSON. All you have done then is created  
a new syntax, with all of the same problems.


-- 
Anne van Kesteren
http://annevankesteren.nl/

Received on Wednesday, 7 April 2010 16:23:16 UTC