Re: SMIL / element-based animation syntax

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