- From: Brian Birtles <bbirtles@mozilla.com>
- Date: Fri, 1 May 2015 06:37:48 +0900
- To: www-svg <www-svg@w3.org>
Minutes in html format:
http://www.w3.org/2015/04/30-svg-minutes.html
and as plaintext below:
[1]W3C
[1] http://www.w3.org/
- DRAFT -
SVG Working Group Teleconference
30 Apr 2015
[2]Agenda
[2] https://lists.w3.org/Archives/Public/www-svg/2015Apr/0055.html
See also: [3]IRC log
[3] http://www.w3.org/2015/04/30-svg-irc
Attendees
Present
Doug_Schepers, [IPcaller], heycam, Thomas_Smailus,
stakagi, Rossen, birtles, Tav, Rich_Schwerdtfeger
Regrets
Amelia, Brian, Erik, Dirk
Chair
Cameron
Scribe
birtles
Contents
* [4]Topics
1. [5]telcon day
2. [6]blink's intent to deprecate SMIL
3. [7]SVG2 issues
* [8]Summary of Action Items
__________________________________________________________
<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> [9]http://doodle.com/8mfbynbh3rkr3myb
[9] 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>
[10]https://groups.google.com/a/chromium.org/forum/#!topic/blin
k-dev/5o0yiO440LM
[10] 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 [11]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
[12]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> [13]https://svgwg.org/svg2-draft/embedded.html#issue4
[13] 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
[14]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
Summary of Action Items
[NEW] ACTION: heycam to coordinate a gap analysis between
features in SVG animation and CSS animations/transitions
[recorded in
[15]http://www.w3.org/2015/04/30-svg-minutes.html#action02]
[NEW] ACTION: heycam to investigate if #xywh is being
implemented [recorded in
[16]http://www.w3.org/2015/04/30-svg-minutes.html#action03]
[NEW] ACTION: heycam to look into animVal/baseVal [recorded in
[17]http://www.w3.org/2015/04/30-svg-minutes.html#action01]
[End of minutes]
__________________________________________________________
Minutes formatted by David Booth's [18]scribe.perl version
1.140 ([19]CVS log)
$Date: 2015/04/30 21:31:11 $
__________________________________________________________
[18] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
[19] http://dev.w3.org/cvsweb/2002/scribe/
Scribe.perl diagnostic output
[Delete this section before finalizing the minutes.]
This is scribe.perl Revision: 1.140 of Date: 2014-11-06 18:16:30
Check for newer version at [20]http://dev.w3.org/cvsweb/~checkout~/2002/
scribe/
[20] 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, stak
agi, Rossen, birtles, Tav, Rich_Schwerdtfeger
Present: Doug_Schepers [IPcaller] heycam Thomas_Smailus stakagi Rossen b
irtles Tav Rich_Schwerdtfeger
Regrets: Amelia Brian Erik Dirk
Agenda: [21]https://lists.w3.org/Archives/Public/www-svg/2015Apr/0055.ht
ml
Found Date: 30 Apr 2015
Guessing minutes URL: [22]http://www.w3.org/2015/04/30-svg-minutes.html
People with action items: heycam
[21] https://lists.w3.org/Archives/Public/www-svg/2015Apr/0055.html
[22] http://www.w3.org/2015/04/30-svg-minutes.html
[End of [23]scribe.perl diagnostic output]
[23] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
Received on Thursday, 30 April 2015 21:38:16 UTC