or , each animating a different property) 20:55:15 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 20:55:16 (b) chaining animations (can be done with CSS preprocessors, but it's messy) 20:55:38 ... 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 20:55:57 (c) event-driven beyond the CSS pseudoclasses (need to use JavaScript / Web animations) 20:55:57 Rossen: on what basis do we deprecate it? simply because of Chrome? 20:56:40 shepazu: the main reason I think we should remove SMIL is that IE does not implement it and we want interop 20:57:19 ... if there is a further signal from Chrome that they want to remove it then that brings it to the fore 20:57:26 Rossen: so who supports it? 20:57:42 shepazu: Chrome, Firefox, Safari, Presto, Batik? 20:57:50 Rossen: so we'd still have 2 implementations 20:58:21 shepazu: 2 implementations is not enough, we want something that has interoperability 20:58:42 heycam: I thought there was a hope at one point that Microsoft might implement once Web Animations was bedded down 20:59:24 shepazu: SVG2 was our first opportunity to deprecate things 20:59:50 ... when Microsoft said they were not going to implement SVG fonts and SMIL we started the conversation 21:00:06 Rossen: are we considering removing SMIL? If so, I'm in full support 21:00:27 -Thomas_Smailus 21:00:35 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 21:00:46 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. 21:01:04 Tav: Until we have a substitute I don't think we should remove it 21:01:19 ... specifically for the three items (a-c above) AmeliaBR raised 21:01:27 -Rich_Schwerdtfeger 21:02:24 q+ 21:02:34 heycam: I think (c) you can listen to mouse events and begin the animations explicitly 21:02:55 and for (b) you can listen to events on the animation and start off other animations 21:03:38 To confirm: these are limitations of CSS animations. You can do all the above with JavaScript / web animations. 21:03:57 (but not in SVG-as-image) 21:04:27 birtles: for (b) I think you shouldn't do that, you'll get gaps between the animation 21:05:54 (discussion about (a)--again, you can do with Web Animations, but not in a declarative way) 21:06:40 shepazu: I would suggest that having these features in another module is functionally equivalent to having it in SVG2 21:07:06 ... but if half the browsers are intent on removing this feature it doesn't help us to keep it in SVG2 21:08:27 ... 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 but this in SVG2 21:08:40 ... developers need strong interoperability 21:08:49 s/but this/put this/ 21:09:12 nikos_: the pain of supporting the SVG in WebKIt is significant [animVal/baseVal I think] 21:09:54 heycam: deciding about this could be the impetus for us to investigate the remaining gaps between SVG animation and CSS animation 21:10:09 ... I don't think leaving it in the spec is really leaving anyone any favours 21:10:22 s/leaving anyone/doing anyone/ 21:10:48 ... it's probably not going to change any implementor's view of whether or not to support the feature 21:11:24 ... 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 21:11:34 shepazu: we've done something similar with markers 21:11:42 Tav: the reason for that was timing 21:12:22 shepazu: well the timing for SMIL is similar, when will IE implement it? 21:12:24 Rossen: never 21:12:47 q+ 21:13:19 heycam: if we're going to look into this gap (e.g. animating paths etc.) soon, should we remove this feature now? 21:13:30 ... rather than removing it at the LC-stage 21:13:34 ... better sooner than later 21:13:52 shepazu: I'd like to point out that this was decided a while ago 21:14:10 ... we were going to split out the animation features into a separate spec 21:14:41 ... I'm very unhappy about this 21:14:59 ... I would like to continue to lobby for element-based animations based on Web Animations [Animation Elements] 21:15:09 ... I think this is a feature that people have good reason for wanting 21:15:17 ... and I don't think the battleground should be the SVG2 spec 21:15:36 ... the battleground, the point of discussion, should be that dedicated spec 21:15:50 Rossen: I agree with shepazu 21:16:03 ... we'll be considering all these things for Edge 21:16:26 ... but not for "IE", that's why I said IE will never support it 21:17:00 heycam: I really just wanted to raise the topic but it sounds like we are close to a decision 21:17:13 ... does anyone object to moving the SMIL chapter to a separate spec? 21:17:34 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 21:17:43 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? 21:17:52 RESOLUTION: Move the SVG Animation features to a separate spec 21:18:20 heycam: it's a good question (as raised by AmeliaBR) 21:18:32 ... because people do rely on those things existing, but I'm not sure to what level 21:18:37 ... we do need to resolve that 21:18:45 ... but it's not a gating factor 21:18:59 shepazu: I suggest we remove them as well, but I don't want to have that discussion now 21:19:43 ... I wonder if someone could write a polyfill were someone could detect what is meant by those 21:20:21 heycam: so there are 2 things to investigate: (1) animVal/baseVal, (2) looking into the gaps between CSS Animations / SVG Animation 21:20:32 ... does anyone want to look into those things? 21:20:48 shepazu: heycam you've looked into (1) before right? 21:21:16 ACTION: heycam to look into animVal/baseVal 21:21:16 Created ACTION-3785 - Look into animval/baseval [on Cameron McCormack - due 2015-05-07]. 21:22:31 shepazu: birtles it seems like you've already started the work, do you have anything for (2)? 21:22:48 birtles: yeah, I wrote up a gap analysis many years ago 21:22:59 ... but I think the bigger issue is actually proposing new specs to fill the gaps 21:23:26 ACTION: heycam to coordinate a gap analysis between features in SVG animation and CSS animations/transitions 21:23:27 Created ACTION-3786 - Coordinate a gap analysis between features in svg animation and css animations/transitions [on Cameron McCormack - due 2015-05-07]. 21:23:56 topic: SVG2 issues 21:24:02 https://svgwg.org/svg2-draft/embedded.html#issue4 21:24:05 heycam: last time we were looking at the embedded content chapter 21:24:28 ... defining the interactions between x/y, width/height media fragments on image elements 21:24:50 ... because you can use preserveAspectRatio attributes on image element to choose which part of the image to show 21:25:01 ... but the #xywh syntax also lets you choose an image 21:25:09 ... so we need to decide which order these apply in 21:25:21 ... I think #xywh should probably happen afterwards 21:25:29 ... but we need some text for that 21:25:38 Tav: if they're doing the same thing, shouldn't one replace the other? 21:25:52 heycam: they do similar things and my mental model of what #xywh does it a bit different 21:26:23 #xywh is equivalent to viewBox, not preserveAspectRatio 21:26:28 ... #xywh can apply to any kind of image, I think it would make sense to apply after doing any SVG-specific processing 21:26:41 ... I'm not sure if anyone actually implements this, by the way 21:27:08 ... yes, that's right, #xywh is more like viewBox 21:27:21 ... I don't think it should replace the viewBox 21:27:34 nikos_: if you did that you'd throw the expected coordinate system out of whack 21:27:46 ... you more likely want a window into the existing image 21:27:55 heycam: you just want to choose which subregion to render 21:28:17 ... so I think we can resolve that #xywh happens later 21:28:25 ... but I wonder if people are actually implementing this? 21:28:55 ACTION: heycam to investigate if #xywh is being implemented 21:28:56 Created ACTION-3787 - Investigate if #xywh is being implemented [on Cameron McCormack - due 2015-05-07]. 21:29:49 heycam: I think scripting is one of the few chapters that we still haven't discussed 21:30:17 ... I wonder how close are we to finishing this 21:30:33 -Tav 21:30:34 -??P7 21:30:36 -heycam 21:30:38 -stakagi 21:30:41 -Doug_Schepers 21:30:44 -Rossen 21:30:50 -birtles 21:30:51 GA_SVGWG()4:30PM has ended 21:30:51 Attendees were Doug_Schepers, [IPcaller], heycam, Thomas_Smailus, stakagi, Rossen, birtles, Tav, Rich_Schwerdtfeger 21:31:06 RRSAgent, make minutes 21:31:06 I have made the request to generate http://www.w3.org/2015/04/30-svg-minutes.html heycam 21:31:07 RRSAgent; make minutes public 21:31:18 heycam: thanks! 21:33:18 birtles, heycam, I wasn't on the call but I read the log about the smil discussion. Would you like me to start a thread somewhere about better coordinating this? The deprecation is just a first step signaling our intent 21:36:18 pdr: I think that'd be good if you posted to the list about your intentions 21:37:04 pdr: though it's likely to turn into a permathread, it would be good to get everyone aware of your plans / reasons 21:37:40 heycam, will do. 21:39:40 Sorry about missing the call, when I did an agenda+; I forgot about my dentist appointment this afternoon. 22:08:37 richardschwerdtfeger has joined #svg 23:23:01 Tav has joined #svg 23:39:21 Zakim has left #svg