Re: CSS Animations Targeting SVG attributes

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