- From: Doug Schepers <schepers@w3.org>
- Date: Tue, 24 Mar 2015 01:18:11 -0400
- To: David Dailey <ddailey@zoominternet.net>, www-svg@w3.org
Hi, David– On 3/20/15 7:13 AM, David Dailey wrote: > Yesterday,(Thursday, March 19, 2015 5:43 PM) @minutes /Nikos wrote: ... > [20] https://svgwg.org/specs/animation-elements/ > ---------------------------- > > Thanks for the clarification and reassurance. The extra features that > I see there [20] seem intended merely to fix certain things rather > than to extend SMIL, so perhaps it will not be seen as "extending the > feature set" and therefore not objectionable. Of course I think the > feature set should be expanded (in various interesting ways that seem > to belong more easily to element-based animation, including expanded > ability to re <use> animate elements, animate attributes of animate > elements to add more dynamism, let values of animation elements > follow functions defined by SVG paths (much the way that > animationMotion works) etc.). As I mention in another thread, I think the first priority should be on making sure that Web Animation is solid, well-implemented, and well-tested before trying to extend it. We still don't have many people using animation in SVG yet, and that's partly because of lack of interoperability and dependability. It's more important to me that we get that right first. Then we can build on those fundamentals. I know to those early adopters who've been using SVG and SVG animation for a long time (myself and most of the SVG WG among them!), this seems extremely slow at best; but in some ways we are still in the phase of building the foundations for SVG in browsers, and once we have that down, we can iterate and experiment more quickly. > Perhaps such new features could be > defined through CSS, but it is important to remember, I think, that > the semantics of SVG is different than that of HTML and that > animation is "semantic" rather than "presentational" for much of the > world of graphics. I've seen this argument from various people, but I see it differently. I try to explain my point of view (which I hope captures the majority view of the SVG WG, as well) on the SVG animation wiki page [1]. Functionally, I see no difference between declarative animation via elements vs. CSS syntax. I'd appreciate if you would read that section of the wiki page and offer a different perspective that might change how I (and the SVG WG) see this issue. > Text (whence the T in HTML) is different in that way. It's not merely the fact that it's text that makes it different. It's that over the centuries, we've developed organizational conventions around the presentation of text: heading levels, word boundaries, paragraph boundaries, section boundaries, punctuation, grouping structures, lists, tables, footnotes and endnotes, tables of contents, and many other mnemonics, navigational and wayfinding aids, and reading clarifiers. And HTML defines a simple model that represents many of these conventions. SVG doesn't do that. There are centuries of drawing conventions as well, including perspective, proportion, color use, ratios and layouts, and hundreds of other mechanisms; but SVG doesn't encode those in the same way that HTML encodes document conventions; in fact, SVG adopts the document structure conventions as much as it does drawing conventions. With regards to drawing conventions, SVG is semantically "flat", and defines only simple geometry and styling. There are some specific drawing conventions that we are starting to tackle in the SVG-Accessibility Task Force, specifically those with well-defined visual vocabularies like data visualizations and maps, but even that is meant to be applied at a meta-layer, as ARIA attributes. > I am still not clear on whether or not the idea of allowing HTML > <img> to allow SVG mouse events would be okay. That was what prompted > the heated discussion in the first place, I believe. Yes, we aren't quite clear on that either. I'm sympathetic to this, and I suspect others on the SVG WG are as well. > I don't think it would require much activity on the part of a > speccing group like SVG-WG -- one would just change the part that > says "don't allow" to "allow" and the work is done, ¿que no? No. That assumes a much more passive and unthinking role for a working group than the reality. We first need to think through how this affects existing content, how browsers will specifically have to implement this (including what the DOM representation will be for the event model… currently, <img> content doesn't have a DOM per se, and so no event model), decide how this should work in different scenarios such as <img> vs CSS background image, make sure that our assumptions are correct around security and privacy, gauge (and maybe influence) implementer interest, establish some priorities based on other things we also want to do with SVG, build consensus around the final approach with implementers and the community (and maybe iterate over the decision until we get it right), coordinate with other working groups (in this case, the CSS and HTML WGs) to make sure that we aren't stepping on their toes or doing something they disagree with, define it clearly and unambiguously, write multiple tests to make sure that we have interoperability, and actually do the testing itself. And since most of the SVG WG are also implementers, this means also implementing the code to make this work in browsers and authoring tools, as well as getting permission to do so from managers who might have other priorities for that developer's time. (This would be akin to saying to a teacher, "All you need to do is stand in front of your students and talk, and tell them which books to read, and the work is done, no?" The reality is usually more complicated than the obvious outcome.) This oversimplification of what it takes to spec a feature may contribute to some of the disconnect and discontent that we recently saw flare up on this thread. The SVG WG is interested in the needs of the developer and design community that uses SVG, even when those desires conflict with each other; I know many people who want to see SVG extended, with new features, but I also know many developers and designers who would rather that we concentrate on more precisely defining and testing existing features so they can use them in production environments; and I even know some developers and designers who complain that SVG is too complex and they want it stripped down to bare essentials (though I suspect each of them has their own idea what those essentials might be); it's a balancing act. And we do that balancing act in just part of our time, over hundreds of features of SVG, and many of other technologies. So, some mutual respect, patience, and calm discussion will get more done with less stress. Clear posts with succinct problem statements and use cases, backed with evidence of need and analysis of constraints, are more likely to persuade the SVG community and SVG WG to take positive action and to commit to the extra work requested. > The security thing seems to be > due only for keystroke events and, then, only in the context of > JavaScript, which <img> wouldn't allow anyhow. I think the security/privacy issue can be dealt with in a sane way, and that shouldn't constrain us too much. [1] https://www.w3.org/wiki/SVG/Animation#Animation_Semantics [2] https://lists.w3.org/Archives/Public/www-svg/2015Mar/0069.html Regards– –Doug
Received on Tuesday, 24 March 2015 05:18:16 UTC