- From: Tab Atkins Jr. <jackalmage@gmail.com>
- Date: Fri, 5 Jun 2015 14:17:29 -0700
- To: Paul Hopgood <p_hopgood@verizon.net>
- Cc: www-svg <www-svg@w3.org>
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