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