Re: Some practical issues integrating the SVG transform attribute with CSS transform properties

On Fri, 25 Mar 2011 06:01:10 +0100, Robert O'Callahan  
<robert@ocallahan.org> wrote:

> I assume we want to make the SVG 'transform' attribute a presentational
> attribute that maps onto the CSS 'transform' property. A few issues have
> come up, and many of them will apply to other attributes that we map up  
> to
> CSS, so they're worth discussing.
...
> 3) What should SVG 'animVal' reflect? Here are a few options:

Just note that no other presentation attributes have a corresponding  
animVal construct, we get this because of the change from attribute ->  
property.

> 3a) 'animVal' returns the animated attribute value as set by SMIL if  
> there
> is one, otherwise the baseVal. It does not reflect any CSS styling,
> including any CSS transitions or animations, nor does it reflect any CSS
> values animated by SMIL.

That sounds consistent and backwards-compat-friendly.

> 3b) 'animVal' returns the animated CSS value as set by SMIL if there is  
> one,
> otherwise the animated attribute value as set by SMIL, otherwise the
> baseVal. It does not reflect any other CSS styling, including any CSS
> transitions or animations

Not as compatible, but possibly handy for getting typed DOM access to the  
transform. It's actually not described anywhere how to get the CSSMatrix  
object, note that elm.style.transform is just a DOMString. Also would need  
to define how to represent the CSS value as a corresponding  
SVGTransformList object, like how to deal with CSS units in translate()  
and rotate(), and the new methods translateX/Y and scaleX/Y.

> 3c) 'animVal' returns the CSS computed value, including CSS transitions  
> and
> animations, and the effects of any CSS rules overriding the style.
> I suspect 3c is most intuitive for authors. However, there is a problem:
> unlike attribute values, CSS computed style changes happen at  
> unpredictable
> times, often asynchronously, and can be coalesced, and we don't want the
> presence or absence of coalescing to be observable via the identity of
> transform objects in the animVal list.

Another option is to deprecate SVGAnimatedTransformList and point people  
to CSSOM, or whatever way there is in CSS to get the (animated or not)  
transform value as a higher level object (CSSMatrix or equivalent, not  
DOMString).


-- 
Erik Dahlstrom, Core Technology Developer, Opera Software
Co-Chair, W3C SVG Working Group
Personal blog: http://my.opera.com/macdev_ed

Received on Tuesday, 29 March 2011 08:29:44 UTC