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

Is everyone on board for using the promotion of SVG Attributes to properties as opposed to using the attr() notation?  And, have we landed on using -svg-r notation?

>>> 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).

What we have been considering here is that if it is set with the SVGAttribute, it is is stored in the  SVG OM; if it is set with CSS it is stored in the CSS OM.

-----Original Message-----
From: public-fx-request@w3.org [mailto:public-fx-request@w3.org] On Behalf Of Erik Dahlstrom
Sent: Tuesday, March 29, 2011 1:29 AM
To: public-fx@w3.org; Jonathan Watt; Cameron McCormack; Robert O'Callahan
Subject: 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 Wednesday, 30 March 2011 14:02:58 UTC