- From: Cameron McCormack <cam@mcc.id.au>
- Date: Tue, 15 Mar 2011 08:54:23 +1300
- To: Dean Jackson <dino@apple.com>
- Cc: public-fx@w3.org
Hi Dean. 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. > > I don't think this is a great solution, for two reasons: > > 1. You lose the ability to do transitions with style changes. Instead > you have to run some script to update the DOM. In most cases I believe > we should be encouraging authors to take a state-based approach via > CSS when building documents. In other words, always try to represent > changes in the document via a single change to a CSS class on an > ancestor element. This is conceptually similar to what :hover does. > Breaking this and requiring script for all updates seems brutal. It would be possible to write a CSS Animation to do the equivalent of the transition, but you would need to write a separate @keyframes per value you could transition to, and you wouldn’t get the auto-reversing behaviour. > Obviously there isn't yet a solution for this, but option 2 was > getting close. (As mentioned on the page, I was in favour of option 2, but nobody else was.) > 2. It requires we change CSS parsing rules to allow attr(x) on the > left side of a rule. While this is only inside @keyframes, I expect > all implementations share the code here with the rest of their CSS > parser. That is a fair point. What did you think about the @keyframes a { from { fill: red } from attributes { width: 100px } to { fill: blue } to attributes { width: 200px } } option? Just as bad (since you need to write a different rule set parser for the “attributes” ones)? > Could we investigate option 2 a little more? > > I haven't thought this through at all, but how about rather than > prefixing attribute names with elements, we could come up with a > generic global prefix that indicates the property is an attribute? > eg. -attr-x is similar to attr(x), but would allow the identifier to > appear on the left side without requiring a change in CSS parsing > rules. Again, in uppercase this time, I HAVE NOT THOUGHT THIS THROUGH > AND IT WILL NOT WORK! I'm just offering something for discussion. Would these represent real properties (i.e., we just introduce a property named -attr-x, and have x="" on <rect> be its presentation attribute? Or does it still mean that you are targeting an attribute, but you are just getting around the CSS parser by not doing attr()? > One of the main reasons I dislike my suggestion is that it implies CSS > is changing the structure of the document (if you consider attributes > to be structure). (I guess you mean that -attr-x means really target the attribute, it’s not a property named -attr-x.) > You'd then have to decide what happens to style rules that are > matching the structure you've just changed. This would be really ugly: > > circle:hover { > -attr-r: 10px; > } > > circle[r=10] { > -attr-r: 20px; > } I think you would leave attribute selectors looking at the actual DOM attribute, and have animations modify animVal, just like SVG animations do. > Here's another probably stupid and unlikely to work suggestion: allow > selectors on SMIL elements. That way, a transition could be something > like this: > > <circle cx="100" cy="100" r="50"> > <set selector=":hover" attributeName="r" attributeValue="100" dur="1s"/> > </circle> That’s kind of like the proposal on the wiki page to give a name="" attribute to SVG animation elements, and allow the animation-name property to reference them. > Lastly, you could still examine moving some of the SVG attributes to > CSS properties (at least the ones that are presentational, such as > radius, width, height, etc) but prefix them with -svg-. That is an option I didn’t think of. To me, doing a comprehensive promotion of SVG attributes to properties and giving them proper names seems cleaner than slipping them in with a -svg- (or -attr-) prefix. > Anyway, my point is that I'm not a fan of option 3, and I think there > are other alternatives we could examine. I'm sure the broader audience > can come up with much better solutions than I'm spitballing. -- Cameron McCormack ≝ http://mcc.id.au/
Received on Monday, 14 March 2011 19:55:05 UTC