RE: Minutes, 30 April / 1 May 2015 SVG WG telcon

Hi Brian,

I know I usually lurk, but I put my regrets on the webpage - doesn't seem to have made it to the minutes below.

Cheers, Chris

PS Personally do not like the idea of declarative SMIL being deprecated. I admit it never made inroads in to Flash and frame based technologies, but with GPU based implementations, its time should come
! I support separate module/spec as a compromise. Shame really.

-----Original Message-----
From: Brian Birtles [mailto:bbirtles@mozilla.com] 
Sent: Thursday, April 30, 2015 10:38 PM
To: www-svg
Subject: Minutes, 30 April / 1 May 2015 SVG WG telcon

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 Friday, 1 May 2015 13:39:36 UTC