SVG Working Group Teleconference -- 30 Apr 2015

<trackbot> Date: 30 April 2015

<smailus> I've got to leave in 30 so will only be able to enjoy the first 1/2 the mtg.

<scribe> scribenick: birtles

<scribe> scribe: birtles

telcon day

<heycam> http://doodle.com/8mfbynbh3rkr3myb

heycam: it looks we can't change the day, sorry Brian
... we'll stick with the current day and time

blink's intent to deprecate SMIL

<heycam> https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/5o0yiO440LM

heycam: you would have seen this on the blink-dev mailing list
... the blink team want to deprecate SMIL (as opposed to remove it)
... i.e. add warnings when the features are removed
... and I think they want to evangelize people to use CSS animations etc. instead
... and I was wondering if people thought we should do something about that in the spec
... and how we think it impacts the future of that spec

shepazu: if I recall correctly, we already decided to remove SMIL from SVG2 correct?

heycam: no

shepazu: I thought we had decided to remove it from SVG2 and put it in its own animation-based spec (Animation Elements spec)

heycam: that was the general plan, but since Brian hasn't had time to get that spec it is still in SVG2

Tav: is there anything in SMIL not in Web Animations?

birtles: not really, but Web Animations doesn't have a declarative syntax
... so you couldn't, for example, animate the points on a path using in a declarative way
... so you couldn't make an SVG-in-OpenType font where the shape of the glyphs morphs (since you can't run script in that context)

nikos_: were they proposing to remove tear-off support?

(i.e. animVal/baseVal)

heycam: I think that may be the intention

nikos_: I'd like to remove that from WebKit

shepazu: how was this brought to the WG?
... it presents a challenge to standardization if implementors don't keep us in the loop with their intentions

Rossen: I sympathize with what you're saying, but I think choosing to support something or not is ultimately a business decision
... it was communicated publicly

shepazu: I'm surprised it wasn't communicated to the WG
... it makes it hard to respond

(some discussion about splitting animation into a separate spec)

Tav: can we get something like declarative animation for paths into a spec other than SMIL?

heycam: I think that's a good question
... if we're coming to the reality that SMIL might not continue then we need to look at the features not available through CSS
... Dirk recently worked on CSS Motion which helps with that
... that probably gives us a good basis for working on path morphing

Tav: I'd be really unhappy to lose that

birtles: yes, it's also hard to animate the points on a path so if we were to work on something new we might be able to fix that as well

heycam: my feeling is that, at a minimum, we should add a notice saying this feature might be deprecated
... others seem to be suggesting that we move it out into another spec

Rossen: deprecate on what basis?

<AmeliaBR> The other key features of SMIL not supported in CSS are (a) multiple independent animations on the same element (with CSS, you need to nest lots of <div> or <g>, each animating a different property)

heycam: given that Blink is not removing the feature, just adding deprecation warnings, then maybe that is the message we should have in the spec as well

<AmeliaBR> (b) chaining animations (can be done with CSS preprocessors, but it's messy)

heycam: removing from the spec, so we can acknowledge that it's definitely not going to be in one of the major implementations, might be the better thing to do

<AmeliaBR> (c) event-driven beyond the CSS pseudoclasses (need to use JavaScript / Web animations)

Rossen: on what basis do we deprecate it? simply because of Chrome?

shepazu: the main reason I think we should remove SMIL is that IE does not implement it and we want interop
... if there is a further signal from Chrome that they want to remove it then that brings it to the fore

Rossen: so who supports it?

shepazu: Chrome, Firefox, Safari, Presto, Batik?

Rossen: so we'd still have 2 implementations

shepazu: 2 implementations is not enough, we want something that has interoperability

heycam: I thought there was a hope at one point that Microsoft might implement once Web Animations was bedded down

shepazu: SVG2 was our first opportunity to deprecate things
... when Microsoft said they were not going to implement SVG fonts and SMIL we started the conversation

Rossen: are we considering removing SMIL? If so, I'm in full support

shepazu: I like the feature but I don't think we can tell developers in good conscience that there is interop so I think we should put it in a separate spec

<AmeliaBR> Could we remove animation elements to a separate spec, without officially deprecating them in SVG 2? Don't want this to hold up recommendation status on the rest of SVG 2.

Tav: Until we have a substitute I don't think we should remove it
... specifically for the three items (a-c above) AmeliaBR raised

heycam: I think (c) you can listen to mouse events and begin the animations explicitly

and for (b) you can listen to events on the animation and start off other animations

<AmeliaBR> To confirm: these are limitations of CSS animations. You can do all the above with JavaScript / web animations.

<AmeliaBR> (but not in SVG-as-image)

birtles: for (b) I think you shouldn't do that, you'll get gaps between the animation

(discussion about (a)--again, you can do with Web Animations, but not in a declarative way)

shepazu: I would suggest that having these features in another module is functionally equivalent to having it in SVG2
... but if half the browsers are intent on removing this feature it doesn't help us to keep it in SVG2
... of the four or so rendering agents that are in major use, if only 2 might support this, then we couldn't in good faith put this in SVG2
... developers need strong interoperability

nikos_: the pain of supporting the SVG in WebKIt is significant [animVal/baseVal I think]

heycam: deciding about this could be the impetus for us to investigate the remaining gaps between SVG animation and CSS animation
... I don't think leaving it in the spec is really doing anyone any favours
... it's probably not going to change any implementor's view of whether or not to support the feature
... and while we could technically ship the spec with just 2 implementations, I think it's more useful for the wider community to indicate what's implemented

shepazu: we've done something similar with markers

Tav: the reason for that was timing

shepazu: well the timing for SMIL is similar, when will IE implement it?

Rossen: never

heycam: if we're going to look into this gap (e.g. animating paths etc.) soon, should we remove this feature now?
... rather than removing it at the LC-stage
... better sooner than later

shepazu: I'd like to point out that this was decided a while ago
... we were going to split out the animation features into a separate spec
... I'm very unhappy about this
... I would like to continue to lobby for element-based animations based on Web Animations [Animation Elements]
... I think this is a feature that people have good reason for wanting
... and I don't think the battleground should be the SVG2 spec
... the battleground, the point of discussion, should be that dedicated spec

Rossen: I agree with shepazu
... we'll be considering all these things for Edge
... but not for "IE", that's why I said IE will never support it

heycam: I really just wanted to raise the topic but it sounds like we are close to a decision
... does anyone object to moving the SMIL chapter to a separate spec?

nikos_: I think, considering that it's likely to be deprecated, it's a smart move and will make the work easier in the future

<AmeliaBR> Sorry to throw a wrench in the works, but there is a complication: What to do about all the element interfaces in SVG 2 that include baseVal/animVal?

RESOLUTION: Move the SVG Animation features to a separate spec

heycam: it's a good question (as raised by AmeliaBR)
... because people do rely on those things existing, but I'm not sure to what level
... we do need to resolve that
... but it's not a gating factor

shepazu: I suggest we remove them as well, but I don't want to have that discussion now
... I wonder if someone could write a polyfill were someone could detect what is meant by those

heycam: so there are 2 things to investigate: (1) animVal/baseVal, (2) looking into the gaps between CSS Animations / SVG Animation
... does anyone want to look into those things?

shepazu: heycam you've looked into (1) before right?

<scribe> ACTION: heycam to look into animVal/baseVal [recorded in http://www.w3.org/2015/04/30-svg-minutes.html#action01]

<trackbot> Created ACTION-3785 - Look into animval/baseval [on Cameron McCormack - due 2015-05-07].

shepazu: birtles it seems like you've already started the work, do you have anything for (2)?

birtles: yeah, I wrote up a gap analysis many years ago
... but I think the bigger issue is actually proposing new specs to fill the gaps

<scribe> ACTION: heycam to coordinate a gap analysis between features in SVG animation and CSS animations/transitions [recorded in http://www.w3.org/2015/04/30-svg-minutes.html#action02]

<trackbot> Created ACTION-3786 - Coordinate a gap analysis between features in svg animation and css animations/transitions [on Cameron McCormack - due 2015-05-07].

SVG2 issues

<heycam> https://svgwg.org/svg2-draft/embedded.html#issue4

heycam: last time we were looking at the embedded content chapter
... defining the interactions between x/y, width/height media fragments on image elements
... because you can use preserveAspectRatio attributes on image element to choose which part of the image to show
... but the #xywh syntax also lets you choose an image
... so we need to decide which order these apply in
... I think #xywh should probably happen afterwards
... but we need some text for that

Tav: if they're doing the same thing, shouldn't one replace the other?

heycam: they do similar things and my mental model of what #xywh does it a bit different

<AmeliaBR> #xywh is equivalent to viewBox, not preserveAspectRatio

heycam: #xywh can apply to any kind of image, I think it would make sense to apply after doing any SVG-specific processing
... I'm not sure if anyone actually implements this, by the way
... yes, that's right, #xywh is more like viewBox
... I don't think it should replace the viewBox

nikos_: if you did that you'd throw the expected coordinate system out of whack
... you more likely want a window into the existing image

heycam: you just want to choose which subregion to render
... so I think we can resolve that #xywh happens later
... but I wonder if people are actually implementing this?

<scribe> ACTION: heycam to investigate if #xywh is being implemented [recorded in http://www.w3.org/2015/04/30-svg-minutes.html#action03]

<trackbot> Created ACTION-3787 - Investigate if #xywh is being implemented [on Cameron McCormack - due 2015-05-07].

heycam: I think scripting is one of the few chapters that we still haven't discussed
... I wonder how close are we to finishing this

- DRAFT -

SVG Working Group Teleconference

30 Apr 2015

Attendees

Contents

telcon day

blink's intent to deprecate SMIL

SVG2 issues

Summary of Action Items

Scribe.perl diagnostic output