Re: CSS Animations Targeting SVG attributes

Dean Jackson:
> > 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.

Tab Atkins Jr.:
> 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).

We decided to:

* float #2 and #2-with-attr-prefix in the CSS WG to see how the feel
  about it (and about #3 with attr() on the LHS of colons in @keyframes)

* go back to the SVG WG saying that the CSS people on the call didn’t
  like #3, and that they think the property profileration argument isn’t
  strong enough to discount #2, but that we’ll get a better sense of
  this once it is floated in the CSS WG

> 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 “what should we do about <rect> geometry properties” has
sidetracked the SVG WG in the past, when discussing whether certain
attributes should be promoted to properties, FWIW.

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

I don’t think it is worth it in this case.

> <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 );
> }

:o

This does mean that if you want to animate just the radius (say) then it
is more difficult than with SVG animations.

Although I think it is an interesting idea, it would probably be
confusing for authors.

> …
> 
> 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>?

I don’t think the name “left” always makes sense here, e.g. with RTL
text the x positions give the right edge of the glyphs.

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

This one could work.

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

I think author friendliness for animating these geometry attributes/
properties should win over the implementation complexity hit here, which
I don’t believe is insurmountable.

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

Received on Tuesday, 15 March 2011 01:28:36 UTC