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_Animation
>
> 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 01:04:14 UTC