SMIL / element-based animation syntax [was RE: Minutes, 16 March 2015 SVG WG telcon]

Yesterday,(Thursday, March 19, 2015 5:43 PM) @minutes /Nikos wrote:

---------
    shepazu: there has been a lot of heat and not a lot of light
    regarding smil
    ... on the mailing list
    ... my understanding is that the element based animation syntax
    will be supported by the animation model

    birtles: right

    shepazu: and all this gloom and doom about smil is not
    neccessary

    birtles: I believe so
    ... think part of the concern is that google says they're not
    interested in extending the feature set of element based
    animation

    shepazu: ok, but old stuff will work

    birtles: though there was some indication there might be slight
    changes in the behaviour

    ed: that's in the engine itself. doesn't have to affect content

    shepazu: I'm going to make a wiki page that spells this out
    ... think if we're going to have this element based syntax it
    should be in a spec right?

    birtles: yes. I started writing a spec called 'Animation
    Elements'
    ... don't have much time to work on it at the moment
    ... main problem with the draft is that I started adding extra
    features

    <AmeliaBR> [20]https://svgwg.org/specs/animation-elements/

      [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.). 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. Text (whence the T in HTML) is different in that way.

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. 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? 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.

Regards
David

Received on Friday, 20 March 2015 11:13:52 UTC