RE: CSS Animations Targeting SVG attributes

I saw Robert's response on this, and I just wanted to chime in and further what Cameron has said.

Folks have been down the path of "promoting" attributes to properties.  There are more technical problems to this, not just the problem with doubling the size of CSS properties or aligning names (or adding aliases).  I originally thought that properties was the way to go.  
The biggest problem is that an attribute in SVG can have different underlying types or semantics depending upon which element it is for.  This is not the case for a property.

Our proposal is animate/transition attributes with the existing attr() function for right-side eval.  I proposed an initial set of simple types that already have interpolations defined (number, float).  The discussion at the WG was to considered all animatable attributes.  Since the SVG spec has already thought through this interpolations for SMIL, it probably won't be too hard to ultimate introduce "d" for example.  I kept it simple, scenario based (size/movement, gradients, filters) to see if we across group could actually push something out :)



-----Original Message-----
From: public-fx-request@w3.org [mailto:public-fx-request@w3.org] On Behalf Of Tab Atkins Jr.
Sent: Monday, March 14, 2011 6:03 PM
To: Dean Jackson
Cc: public-fx@w3.org
Subject: Re: CSS Animations Targeting SVG attributes

On Mon, Mar 14, 2011 at 11:47 AM, Dean Jackson <dino@apple.com> wrote:
> I cannot attend today's conference call, so I'm reading the 
> conclusions from 
> http://www.w3.org/Graphics/SVG/WG/wiki/Talk:F2F/Auckland_2011/CSS_Anim

> ation
>
> It seems that the SVG WG would like to propose option 3 to the FX TF.

Just to loop back quickly, we decided instead to go with #2, or something close to it (such as your idea to use an 'attr-' prefix).

I'm writing the summary email of the discussion for the CSSWG right now, and I had a thought.  One of the arguments that has been raised against option 1/2 is that it would involve introducing a bunch of new properties to CSS, which raises the memory footprint of *all* elements.

Can we reduce this at least somewhat by folding SVG attributes into existing CSS properties?  For example, the general layout model of SVG is basically CSS's absolute positioning.  Thus, x/y/width/height on <rect>, for example, could be mapped very faithfully to CSS's left/top/width/height.

This doesn't get us *too* far, unfortunately.  There's no way to map <line>'s x1/y1/x2/y2 attributes into CSS properties, for example, unless we say something like x1/y1 map to left/top and then invent a new pair of properties for x2/y2 to map to.

<circle> presents a more interesting problem. cx/cy/r *should* be mappable into left/top/width/height automatically with calc():

circle {
  left:   calc( attr(cx,length) - attr(r,length) );
  top:    calc( attr(cy,length) - attr(r,length) );
  width:  calc( attr(r,length) * 2 );
  height: calc( attr(r,length) * 2 );
}

And the same with <ellipse>:

ellipse {
  left:   calc( attr(cx,length) - attr(rx,length) );
  top:    calc( attr(cy,length) - attr(ry,length) );
  width:  calc( attr(rx,length) * 2 );
  height: calc( attr(ry,length) * 2 );
}

Let's see... from the list at
<http://www.w3.org/Graphics/SVG/WG/wiki/F2F/Auckland_2011/CSS_Animation#Regular_Attributes>
(ignoring filter attributes), we're left with:

* x2 (on <line>/<linearGradient>)
* y2 (on <line>/<linearGradient>)
* fx (on <radialGradient>)
* fy (on <radialGradient>)
* x (on <text>/<tspan>)
* startOffset (on textPath)

x2/y2 would need new properties, unless we're okay with using width/height and letting them go negative (probably a non-starter).
Maybe left-end/top-end?

fx/fy definitely need new properties, perhaps width-inner/height-inner?

x on <text> has a different structure than 'left', but still represents a similar functionality.  Perhaps we can just extend the syntax of 'left' to be list-valued, with only the first value being used for elements other than <text>/<tspan>?

startOffset is *almost* text-indent, if text-indent resolved percentages relative to the line length rather than the containing block width.  Is it possible to just have different processing rules for %s on text-indent based on the context?


So, reviewing this approach, it could involve adding only four properties, and altering the syntax/interpretation of two others.  It also means that some attributes are mapped in a non-direct way into properties.  I don't know how well this would scale to animating more attributes.

I'm definitely not convinced this is a good direction to head in, but it's an interesting path to explore.

~TJ

Received on Tuesday, 15 March 2011 14:26:21 UTC