- From: Cameron McCormack <cam@mcc.id.au>
- Date: Tue, 15 Mar 2011 14:27:52 +1300
- To: "Tab Atkins Jr." <jackalmage@gmail.com>
- Cc: Dean Jackson <dino@apple.com>, public-fx@w3.org
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