- From: Tab Atkins Jr. <jackalmage@gmail.com>
- Date: Mon, 14 Mar 2011 18:03:23 -0700
- To: Dean Jackson <dino@apple.com>
- Cc: public-fx@w3.org
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