W3C home > Mailing lists > Public > public-fx@w3.org > January to March 2011

Re: CSS Animations Targeting SVG attributes

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Mon, 14 Mar 2011 13:56:10 -0700
Message-ID: <AANLkTimvhF2xwQs7kiSTug5ooNOQD-72P0FFbXj-EsuY@mail.gmail.com>
To: robert@ocallahan.org
Cc: Dean Jackson <dino@apple.com>, public-fx@w3.org
On Mon, Mar 14, 2011 at 1:48 PM, Robert O'Callahan <robert@ocallahan.org> wrote:
> On Tue, Mar 15, 2011 at 7:47 AM, Dean Jackson <dino@apple.com> wrote:
>> 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.
> What Cameron said --- authors can introduce a CSS animation to do this.

Animations are *not* designed to handle state transitions from one
value to another, and trying to use them as such is an invitation to
infinite pain once you step beyond the most trivial cases.  This must
be usable in Transitions as well, so we can build extensions to
Transitions to make them sufficiently powerful.

>> 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.
> Yes, but you can just reject attr(x) properties outside a @keyframes
> context. Only @keyframes needs to support property storage for attr(x). This
> may be helpful.

Per the above, I strongly object to doing anything just for Animations
that is incompatible with Transitions.

>> Could we investigate option 2 a little more?
> It seems that any version of option 2 is going to require a large number of
> new CSS properties, most of which will only apply to a small number of
> specific SVG elements. They will all have to participate in the cascade, in
> getComputedStyle, in CSSStyleDeclaration, etc. That seems like a significant
> downside to me.

Since they only apply to SVG elements, presumably implementations can
specialize and only add the necessary data structures to SVG elements,
not HTML elements and similar.

Received on Monday, 14 March 2011 20:57:19 UTC

This archive was generated by hypermail 2.3.1 : Monday, 22 June 2015 03:33:45 UTC