W3C home > Mailing lists > Public > public-fx@w3.org > April to June 2011

Re: transform attribute vs property (was: Re: Minutes: 3 April 2011 FXTF telcon)

From: Erik Dahlstrom <ed@opera.com>
Date: Mon, 18 Apr 2011 11:04:57 +0200
To: "Doug Schepers" <schepers@w3.org>, "Cameron McCormack" <cam@mcc.id.au>
Cc: public-fx@w3.org
Message-ID: <op.vt4l6j0igeuyw5@localhost>
On Wed, 13 Apr 2011 04:15:41 +0200, Cameron McCormack <cam@mcc.id.au>  
wrote:

> I’m sorry I wasn’t able to attend this telcon.  A comment below:
>
> Minutes, via Doug Schepers:
...
>>    Resolution: pending further discussion with other stakeholders, we
>>    will not define @transform as a presentation attribute
>
> In my opinion, it would be confusing to have two different transforms,
> one specified with the attribute and another via a styling property.  I
> don’t think we want to introduce new cases where SVG animations have
> different behaviour depending on whether attributeType="CSS" or
> attributeType="XML" is specified, either.

It's two different ways of specifying the transform, but in the end it's  
just one transform that gets applied (possibly after multiplying them  
together, or one overriding the other). If we go for the option that was  
proposed on the call then the transform attribute would not be upgraded to  
a presentation attribute. That would solve the issues with the SVG DOM  
objects corresponding to the transform because the SVG DOM would only  
reflect what's in the attribute and nothing else (just like it is at the  
moment). How the CSS transform applies to svg content would be almost the  
same as the transforms spec describes, though it was suggested on the call  
that it should be post-multiplied to the svg transform.

> It is true that if transform="" is a presentation attribute for the
> transform property, and either
>
> * we want to allow the additional transform item types defined in the
>   CSS 2D transforms spec to be specified in the presentation attribute;
>   or

If transform is a presentation attribute then yes, I'd assume you'd want  
the same syntax mostly (though perhaps not require units?).

> * we don’t want to allow this, but we do want the
>   SVGAnimatedTransformList to expose CSS animated or computed values
>   (Robert’s 3b and 3c proposals)
>
> then we will need to define how those transform items are exposed in the
> SVGAnimatedTransformList.  This isn’t a difficult problem, however.

It may not be difficult, but it's different to the existing presentation  
attributes in svg which only provide access via CSSOM. Should we expose  
all presentation attributes in the same way in that case? Or should the  
CSS transforms only be reachable via CSSOM?

> I’m not sure what backward compatibility concerns there are with
> promotion of transform to a property.  As far as I can see, all of the
> options presented in Robert’s mail won’t break existing content.

Yes, I think that's right, but the issue of the SVGAnimatedTransformList  
object and how it relates to the CSS transforms needs to be resolved.


-- 
Erik Dahlstrom, Core Technology Developer, Opera Software
Co-Chair, W3C SVG Working Group
Personal blog: http://my.opera.com/macdev_ed
Received on Monday, 18 April 2011 09:05:57 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 18 April 2011 09:05:57 GMT