20:24:41 RRSAgent has joined #svg 20:24:41 logging to http://www.w3.org/2016/11/17-svg-irc 20:24:43 RRSAgent, make logs public 20:24:43 Zakim has joined #svg 20:24:45 Zakim, this will be GA_SVGWG 20:24:45 ok, trackbot 20:24:46 Meeting: SVG Working Group Teleconference 20:24:46 Date: 17 November 2016 20:24:51 present+ shepazu 20:27:03 present+ nikos 20:27:05 Chair: Nikos 20:27:08 Agenda: https://lists.w3.org/Archives/Public/www-svg/2016Nov/0001.html 20:30:20 present+ stakagi 20:31:07 Scribe: Nikos 20:31:10 scribenick: nikos 20:31:11 present+ AmeliaBR 20:33:06 present+ Tav 20:35:13 Topic: Publish SVG Animation CR 20:35:13 shepazu has changed the topic to: SVG WG 20:35:54 nikos: The suggestion was to publish CR of SVG Animations, since we have multiple implementations 20:36:30 AmeliaBR: sounds reasonable. I've been advocating to publish a working draft at least. This is animation elements as defined in 1.1. There are multiple implementations. It's probably safe to go to CR. 20:36:55 ... But going to CR means doing some editorial tidy up 20:37:13 ... If we were going to WD, I would say go for it right away 20:37:33 nikos: We may need to publish a WD before going to CR anyway 20:38:21 shepazu: is it ready for publication? 20:38:24 nikos: As a WD it is 20:38:42 AmeliaBR: in the status page we could say we very quickly intend to move to CR because of exiting implementations? 20:39:11 https://svgwg.org/specs/animations/ 20:39:26 nikos: Wait that's level two 20:40:19 ... think that's a mistake and level two has been put in place of level 1 20:40:39 https://svgwg.org/specs/animation-elements/ 20:42:01 ^^ That is "Level 3". "Level 2" is what we're talking about. 20:43:09 shepazu: Have we talked to Brian Birtles? 20:43:19 nikos: I pinged him but waiting to hear back 20:43:51 shepazu: First I'd like to hear from Brian, and talk to PLH about what's happening with the SVG WG 20:44:03 nikos: I still think we should publish a WD 20:44:41 nikos: I've got all the WD updates ready to publish - strokes, markers, etc 20:44:52 AmeliaBR: only things we want to change with animation is: 20:45:00 ... maybe getting rid of clock values which have no real implementations 20:45:09 ... maybe deprecating stuff like animateMotion and animateTransform 20:45:18 ... only new thing we've got in here is the discard element 20:45:18 q+ 20:46:27 shepazu: Don't want to discourage conversation on this, but I do want to keep us focused on SVG 2 20:46:38 ... think when we hear back from Brian what level of effort he's willing to put in the spec 20:48:29 ... we are out of charter now, we're on an extended charter. New charter doesn't mention this spec. I'm afraid that showing a lack of focus is going to discourage browser makers from getting involved in the process. 20:48:46 AmeliaBR: that's all fair, think we should get this as a WD and get the updated versions of the WDs done by the end of the year 20:49:04 ... with the understanding that those projects will be shelved until SVG 2 is done 20:49:50 nikos: We resolved at TPAC to publish other specs. I'm concerened that if the WG shuts up, that things are organised and not confusing as to what the status of specs is 20:50:18 ... I want this to be very low effort 20:50:29 AmeliaBR: I'm concerned about the level of work to publish CR. But WD needs to happen 20:50:34 shepazu: I'll talk to PLH 20:50:45 Topic: Make SVGUnitTypes a regular interface with only constants 20:50:54 https://github.com/w3c/svgwg/issues/291 20:51:37 nikos: Robert Longson raised this issue that in SVG 2 SVGZoomAndPan is no interface so the constants that are available on it can't be accessed through SVGZoomandPan 20:51:54 ... this is something browsers are updaing at the moment, so important to discuss 20:52:14 nikos: foolip made some comments about interop and made a counter proposal 20:52:30 ... in FF SVGZoomAndPan has alwayd been expoed, but thats not the case in all browwsers 20:52:46 Also SVGUnitTypes is very similar 20:52:57 ... but implementation is the opposite 20:53:16 ... SVGUnitTypes has always been exposed, SVGZoomAndPan has never been exposed interoperably 20:53:29 ... We have a PR to update SVGUnitTypes 20:53:36 AmeliaBR: updating it to match Chrome 20:53:44 ... which exposes one but not the other 20:53:55 nikos: FF has agreed to the PR for SVGUnitTypes 20:54:35 ... so proposed resolution is to expose SVGUnitTypes, but not have any other interfaces implement it 20:55:56 AmeliaBR: The PR just focusing on SVGUnitTypes, by removing the implementations of the interface. It does cancel out some potential functionality. We're relying on the data provided by the contributors 20:56:31 ... Usage data shows the constants not being used via the interfaces that implement SVGUnitTypes 20:57:12 nikos: Conversely, data shows the constants are being used directly via the SVGUnitTypes interface 20:58:25 ... MS and Google have said they want to have constants only on SVGUnitTypes, and FF has agreed that would be OK if it's what the other implementors want 20:59:49 RESOLUTION: SVGUnitTypes will not be nointefaceobject. No other interfaces will implement SVGUnitTypes. Accept PR #295 21:00:42 nikos: For SVGZoomAndPan, Google want to keep it as is. FF want to expose the SVGZoomAndPan interface directly 21:00:58 ... at the moment SVGZoomAndPan is nointerfaceobject 21:01:06 AmeliaBR: According to foolip, WebKit is the same 21:01:39 nikos: My issue is that author expectation would be that the constants should be available via the SVGZoomAndPan interface 21:02:10 nikos: But it's something that's not used and not that big a deal 21:02:42 ... Robert has said he doesn't expect FF to change, Chrome implementation is different 21:04:10 nikos: Let's see how discussion in the issue goes wrt SVGZoomAndPan and come back to that one later 21:04:23 Topic: Interaction of `x` attribute and `startOffset` in a textPath element 21:04:30 https://github.com/w3c/svgwg/issues/265 21:04:57 Tav: My expectation is that x and startoffset would have an effect 21:05:10 AmeliaBR: when you reset text, is it relative to startoffset, or to the start of the path? 21:05:15 ... that's where we have differences 21:05:44 nikos: Does the algorithm clarify that? 21:05:58 AmeliaBR: Do we have a test case? 21:06:16 http://jsfiddle.net/u5z02hpx/9/ 21:06:53 AmeliaBR: FF does 5 past 50%, Edge is the outlier, it does 5 past the beginning. 21:08:09 http://jsfiddle.net/u5z02hpx/12/ 21:09:08 nikos: FF is ignoring the x attribute on the text element 21:09:38 http://jsfiddle.net/u5z02hpx/12/ 21:09:49 http://jsfiddle.net/u5z02hpx/13/ 21:09:51 AmeliaBR: This version is more clear 21:10:30 nikos: So first question is whether x element on text is equivalent to x on tspan, that's where the algorithm says yes 21:11:23 AmeliaBR: So the problem with FF is it's ignoring any positions set on the text element that should inherit down 21:12:34 Tav: Looking at the 13 test case, if you put a letter after the first text element but before the textPath - that should be positioned by the x and y of the text element? 21:12:44 ... how does that affect the starting x and y position along the textPath? 21:13:05 AmeliaBR: it wouldn't for absolute positions because they would get reset 21:13:19 ... the issue is the way the attributes work is they don't apply per element, they apply per character 21:13:24 ... so they get inherited down and applied per char 21:13:35 ... for chars inside textPath they are applied in the textPath coordinate system 21:13:43 ... where the x axis is the path 21:14:22 ... browsers seem to be consistent with that with dy 21:14:44 ... if there is a letter outside textPath dy applies, otherwise it applies to what's in textPath 21:14:53 Tav: If you have two dy values? 21:15:16 Tav: My guess is that SVG 1.1 didn't intend on having text outside the textPath 21:15:25 nikos: Yeah it's not very useful 21:15:33 ... for a lot of pain 21:17:05 nikos: Do people have a behaviour they would like? 21:17:18 Tav: I would like x + startoffset 21:18:21 AmeliaBR: The idea is that positioning attributes apply per char, whether or not they are on an ancestor or child of the textPath. The textPath coordinate system is measured relative to the startOffset point. x=0 is the defined startOffset. 21:18:30 Tav: Think that makes the most sense 21:19:03 nikos: And that seems to be roughly what the algorithm is saying - without having looked at it in fine detail 21:20:03 RESOLUTION: positioning attributes apply per char, whether or not they are on an ancestor or child of the textPath. The textPath coordinate system is measured relative to the startOffset point. x=0 is the defined startOffset. 21:20:29 ACTION: Tav to update text prose with text/textPath offset resolution 21:20:30 Created ACTION-3864 - Update text prose with text/textpath offset resolution [on Tavmjong Bah - due 2016-11-24]. 21:20:36 agenda+ mesh 21:25:17 chaals has joined #svg 21:36:28 RRSAgent, make minutes 21:36:28 I have made the request to generate http://www.w3.org/2016/11/17-svg-minutes.html nikos