See also: IRC log
<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
<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
<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].
<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
This is scribe.perl Revision: 1.140 of Date: 2014-11-06 18:16:30 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/but this/put this/ Succeeded: s/leaving anyone/doing anyone/ Found ScribeNick: birtles Found Scribe: birtles Inferring ScribeNick: birtles Default Present: Doug_Schepers, [IPcaller], heycam, Thomas_Smailus, stakagi, Rossen, birtles, Tav, Rich_Schwerdtfeger Present: Doug_Schepers [IPcaller] heycam Thomas_Smailus stakagi Rossen birtles Tav Rich_Schwerdtfeger Regrets: Amelia Brian Erik Dirk Agenda: https://lists.w3.org/Archives/Public/www-svg/2015Apr/0055.html Found Date: 30 Apr 2015 Guessing minutes URL: http://www.w3.org/2015/04/30-svg-minutes.html People with action items: heycam[End of scribe.perl diagnostic output]