Re: Animating SVG with CSS

GUYS, GUYS.... And uh gals... The subject is animating SVG with CSS. Since not all SVG attribute can be animated with CSS, I suggest we look toward an canvas.getContext("svg"); . It's the interface that people would be more interested in than it actually being SVG; meaning that this will defined all--and in reality, there are only few-- SVG elements, via a api for canvas... Uh, like so:
var svg = canvas.getContext("svg");

And implementing the dying SMIL spec in this to work with the SVG canvas API to add more animation control and feature.

I vote that Tab Atkins leads this spec.

E-S4L
N-S4L
J-S4L

> On Sep 18, 2014, at 6:49 PM, "Tab Atkins Jr." <jackalmage@gmail.com> wrote:
> 
> On Thu, Sep 18, 2014 at 1:47 PM, Juergen Roethig
> <roethig@dhbw-karlsruhe.de> wrote:
>> Tab Atkins Jr. wrote:
>>> On Thu, Sep 18, 2014 at 1:01 PM, Juergen Roethig
>>> <roethig@dhbw-karlsruhe.de> wrote:
>>>> Then let's take the CSS rule
>>>> * { width: 10px; }
>>>> which was and is valid in the context of HTML and which now even makes
>>>> all
>>>> my nice SVG rectangles have the same size under the assumption that
>>>> "width"
>>>> becomes a presentation attribute. But probably, some clever guy has
>>>> already
>>>> built a usage counter in Chrome for SVG's <rect> object which gave the
>>>> result that <rect> is used by less than 10% of all SVG documents and
>>>> therefore negligible ...
>>> 
>>> Luckily, that's an extremely ridiculous sort of rule to write in a
>>> page, and thus not something to worry about.
>> 
>> Poooh, we are so lucky to have the high jury's decision that this rule is so
>> extremely ridiculous ;-)
> 
> I'm really not sure how to take this.  Do you think people actually
> write `* { width: XXX; }` in their pages?  At least, enough to make us
> care about compat?
> 
> You're not raising a theoretical issue, but a practical one.  Whether
> or not this causes a problem in practice is the question, and the
> types of rules you've given as examples aren't going to show up in
> practice.  Is there something you're thinking of that might actually
> show up on real pages?
> 
>>>>> This is part of the reason why CSS does *not* expose unknown
>>>>> properties to the author; this discourages unknown properties from
>>>>> being used/abused in this manner.
>>>> 
>>>> If you could explain to a dumb non-native English speaker what you mean
>>>> by
>>>> "CSS does *not* expose unknown properties to the author", please ???
>>> 
>>> Hey now, no need to disparage yourself.
>>> 
>>> I meant that CSS throws away unknown properties, with no way for the
>>> page to know that they were there; there's no interface or API to tell
>>> you that an unknown property was ever specified.
>> 
>> Is this something special, and isn't this already implied by the term
>> "ignore"? And on the other hand, "this also does *not* discourage unknown
>> properties from being used/abused", since it does *not* throw an
>> error/exception/whatever for using unknown properties ...
> 
> In CSS, "ignore" is indeed defined to mean this, but, for example, in
> SVG you can create elements with unknown names, or put unknown
> attributes on elements, and they'll stick around in the DOM and be
> inspectable.  They don't get thrown away at parse time, like CSS does
> for unknown properties.
> 
> I'm not sure what you mean by "throw an exception", since CSS doesn't
> have a concept of exceptions.  If you're suggesting it might make
> sense to have CSS simply stop working when it encounters an unknown
> property, I'll remind you that all *new* properties are "unknown" in
> old browsers; forwards compatibility (defining things such that UAs
> handle future additions safely) is also important.
> 
> ~TJ
>

Received on Friday, 19 September 2014 02:13:45 UTC