Re: SVG animations without SMIL

On Thu, Jun 4, 2015 at 11:32 AM, Paul Hopgood <p_hopgood@verizon.net> wrote:
> Now that we finally have all but Microsoft supporting SVG animation to some
> extent the W3C seems intent on supporting browser developers who can’t be
> bothered to finish off their work and go back to a situation where only one
> or two browser options are available to users who want to view SVG
> animation.

Standards aren't worth the pixels they're printed on if they don't
describe widely-implemented things.  If you can't in practice use
something because it won't be available to ~1/3 of your users, and
there's no realistic path to making that fraction much smaller, it's
something to deprecate and discourage, not continue pretending it's a
useful standard.

> I have no problem with adding STYLE animations to CSS but it is not a
> replacement for CONTENT animation in SMIL. If we end up with two standards
> SVG 1.1 for content animation and SVG 2 for style animation then that would
> be messy but at least then we would again see what browsers will support
> what. If the browsers don’t support the facilities the users want then those
> browsers will not be used.

There is no distinction between "content" and "style" animations.
They are identical.  SMIL has a few facilities that CSS animations
don't, and vice versa, but that's not due to "content" vs "style".
There is no meaningful semantic difference between the two categories;
machines treat them the same.  (Semantics being the way we communicate
our intent to machines, so they can use the page better; we
communicate our meaning to humans with style and presentation.)

> As Chris Lilley explained the path description does all that it was designed
> to do well, it may be a little difficult for a novice to read (but no more
> so than all the Javascript code on the web without any formatting!) but it
> is fairly easy to parse by a tool and as such serves well as a low level
> graphics specification. There are simple additions to the animation of paths
> that could be added (as suggested by Bob & David Duce) without breaking what
> is already there - If it ain’t broke, don’t fix it.

I strongly disagree that <path> does its job well, but that's a
personal opinion. ^_^  But yes, I don't think there's a *short-term*
need to improve anything about it; it would be good as a medium-term
goal.

> I can’t really understand why browser vendors would rather parse CSS than
> SVG, CSS isn’t even XML! - is XML no longer fashionable? ;-)

Correct.  XML has a lot of issues that make it unsuitable for the web,
which is why over 99% of HTML content is written and parsed in the
HTML syntax, not the XHTML syntax.  This argument has been had ad
nauseum, tho, and is not worth repeating; I won't follow up on it.

CSS parsing is completely well-defined with an easy-to-implement spec
and fully-defined error-handling, so it's not a big deal.

> I am adding SMIL animation facilities to www.svg-editor.org and only wish
> the browsers were more complete / consistent but I have no intention of
> providing any tools for CSS editing. CSS can just be edited as text and it
> is likely that it will take even longer for any useful animation tools to
> become available for creating anymore than cosmetic animations in CSS.

For the most part, CSS animations have the same usefulness as SVG
animations; it's just a syntax translation.  There are some things you
can do in either that you can't do in the other, but they mostly
overlap.  We're fixing a bunch of the remaining holes in coverage,
with efforts like this thread.  Tooling one or the other is roughly
equal in complexity.

~TJ

Received on Friday, 5 June 2015 21:18:17 UTC