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

On Tue, Mar 29, 2011 at 9:28 PM, Erik Dahlstrom <ed@opera.com> wrote:

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


Indeed.


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


We could use TYPE_UNKNOWN for CSS transforms that can't be represented in
SVG, until SVG is extended to represent them.


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

We could do that, but that API doesn't exist yet and we still have to
determine how .animVal behaves.

Is your preferred position 3a + push authors to CSSOM?

Rob
-- 
"Now the Bereans were of more noble character than the Thessalonians, for
they received the message with great eagerness and examined the Scriptures
every day to see if what Paul said was true." [Acts 17:11]