Re: Dropping angle-bracket syntax for animation

Hi Folks,

In my opinion we shouldn't remove SMIL based animations from SVG. And like some people mentioned before, we have a lot of SVG content with SMIL animation out there. SMIL animation is a well-though-out specification that grows and got better over time. Instead of removing or replacing SVG animations, we should think about moving to SMIL animations 3.0 for SVG. It's bad that SVG animations and SMIL animations gets more and more incompatible. I'd suggest to remove most content of SVG animation and rely to SMIL 3.0 animations instead. Just animateTransform and path animations need to get specified on SVG. If someone still find issues with SMIL, they should get reported to the competent WG anyway.

Also I don't think that we can define a new specification for declarative animations form the scratch without making new failures. CSS animations and transitions are great! But the simplicity of the syntax is marginal as well. If they get new features like declarative animations, it can easily get a lot more complex than SMIL. I definitely support using CSS for animations as much as possible. But in my opinion it is better to have a simple syntax with some basic animations for CSS.  If web developer need more power, they can take SVG animations.

I agree to Vincent as well. In the past CSS was just responsible to properties in SVG. Web developers could set theses properties with attributes as well, but they are still CSS properties. If we want to do more CSS work to other attributes, they should get CSS properties as well. But first we have to clarify how to handle the different SVG types within CSS. The best example is the attribute 'x'. For a rect, x is of the type SVGLength and can just take one value. For texts x is from the type SVGLengthList with multiple values! How do you handle that in CSS? We have the same issue with CSSTransform and SVGTransform. IIRC the only practical solution I heard so far, is that we do not mix both. Means you can not set the CSSTransform with the attribute 'transform' in the DOM, and the CSSTransform does not replace the content of the 'transform' attribute. Instead we end up with two different transforms and one gets post multiplied to the other.

Cheers,
Dirk

Received on Wednesday, 3 August 2011 07:38:24 UTC