Re: Animating SVG with CSS

Hmm,.. is there any viable alternative to SMIL other than using  
javascript? If not I suggest keeping it alive by whatever means needed as  
javascript is far too taxing on the brains of many. Somehow the idea of  
making the web accessible to all by simplifying matters has been throw out  
of the window I feel.

Having a SVG canvas API like suggested here would be nice though. And  
while at it, could there be a WebGl one too? Would be really interesting  
to be able to make a nice UI layout in SVG and splash it into either WebGL  
or Canvas. That way we can make authoring content for web context and  
other contects a lot more straightforward and we don't end up with doing  
the same work over and over again.

I'm pretty sure the larger part of graphics designers is far more  
interested in SVG than browser vendors seem to realise. Having something  
like SMIL actually work would make them cry with joy. So far the only  
thing holding back SMIL has been Microsoft trying to enforce it's own  
standards on the world that clearly rejected that idea. As sore losers  
they now still refuse to implement the one standard people have been  
waiting for. However, for the wider world of mobility, MS can be ignored  
as a player anyway and that is where it really happens these days.

iOS8 does webGL and even MS jumped on the train, so making a webGL API to  
SVG would seem like a rather important step. No doubt you can do 3d  
transformations in webGL of whatever SVG content you would throw at it,  
making for interesting interactions.

Canvas to my idea is as dead as doorknob for the simple reason that it  
only uses javascript and is a hell of a lot work to get anything shown but  
a bitmap. Nor is its content searchable. Basically its back to flash but  
then worse. I, for one, cannot be arsed to use that crap.

What authors want is something that enable them to make rich visual  
content with good typography that shows up in search engines AND can be  
used in multiple context ignoring output resolutions. They also prefer  
something intelligible to make things move and interact. SVG and SMIL tick  
those bills and javascript and CSS really do not.

Authors in general couldn't care less what renders their content and speed  
has been a relative issue for as long as the web exist. As long as it is  
rendered the way they intended it they will be thrilled. Simple methods to  
make that happen is what they're after and not having to optimise their  
brainchild to every bloody pixel but have the computer calculate it would  
make them cry with joy.

Regards,

Jelle



On Fri, 19 Sep 2014 10:13:13 +0800, L2L 2L <emanuelallen@hotmail.com>  
wrote:

> 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 07:09:42 UTC