Re: CSS Animations and Transitions on SVG Attributes

On Fri, Dec 2, 2011 at 7:09 AM, Patrick Dengler <patd@microsoft.com> wrote:
> Thanks Dean,
>
> I noticed that (and I think put it in the specification here) but was very excited to see it.
>
> As an update, I will hopefully have a prototype of this proposal running on webkit with a JS file (I have it running on Win8 if anyone wants to try).  The purpose of the prototype is both so this working group can try it, and, if we want to, give it to the open source community to use to retrofit older browsers.
>
> I haven’t seen any rejections of this proposal.  What are our next steps?

I am opposed to part of the proposal, as I noted in an email and you
included in the proposal at the start of this thread:

[in reference to the "type" and "semantic" collision rules]

These are both problematic.  There *aren't* identified rules for what
to do when unit types don't apply to a particular element.  Specific
properties do this with specific keywords ("treat XXX like YYY when
ZZZ"), and the flex() notation for flexbox has a special treatment in
non-flex situations, but these are (1) special-cased each time, and
(2) handled such that they always become a valid (and as much as
possible, reasonable) value.

I don't see how you can handle (2) generally.  You can't just say
"whoops, you can't use a percentage for the 'offset' property on
filter elements!", because what does that mean?  This isn't a
parse-error - you don't know what the element is until at least
specified-value time - so you can't just drop the rule and use one
lower in the cascade.  You've got an invalid value and nothing to fall
back to.  I handle this in Variables, because there is literally no
way to avoid it, but this *can* be avoided here.

I think a better idea would be to deal with Type and Element
collisions by creating a property with a new name, rather than just
sticking with the exact same name as the attribute.

~TJ

Received on Friday, 2 December 2011 16:37:22 UTC