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

I’m sorry I wasn’t able to attend this telcon.  A comment below:

Minutes, via Doug Schepers:
>    anthony: seems like people are leaning toward roc's option 1a: "1a)
>    Introduce a UA style rule that sets transform-origin to "top left"
>    for all SVG elements."
>    ... would this apply before or after the transform is applied?
> 
>    smfr: SVG or CSS transform?
> 
>    anthony: I thought we were doing a 1-1 mapping?
> 
>    smfr: not sure how they interact
> 
>    shepazu: do CSS transforms override or supplement SVG transforms?
> 
>    ChrisL: depends on if @transform is promoted to a CSS property
> 
>    <ChrisL> if its promoted toa property then a style rule overrides.
>    if not,then they could be defined to combine. Depends what we want
> 
>    ed: I did an experimental implementation that did a post-multiply,
>    and it seemed easy enough to use, but felt a bit strange not to have
>    @transform as a presentation attribute
> 
>    <ChrisL> Not promoting transform to a property minimises the
>    backwards compatibility issues and means the dom still works as it
>    did before
> 
>    ed: didn't experiment much, but that was the easiest way
> 
>    anthony: what about animation?
> 
>    shepazu: still works for animating with CSS animations
> 
>    ChrisL: I think the simpler path is not promoting @transform to a
>    property, and just define how they combine
> 
>    shepazu: I tend to agree, though ed's point is taken
> 
>    ed: yeah, that solves the DOM issues as well
> 
>    shepazu: my only concern would be for SVG UAs that don't support
>    CSS, but I think those are dwindling
> 
>    anthony: would CSS transforms still apply to SVG
> 
>    ChrisL: yes, they would be separate sources of transformation, and
>    you would simply post-multiply them
> 
>    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 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

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

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.

-- 
Cameron McCormack ≝ http://mcc.id.au/

Received on Wednesday, 13 April 2011 02:16:14 UTC