07:25:39 RRSAgent has joined #svg 07:25:39 logging to http://www.w3.org/2016/06/22-svg-irc 07:25:41 RRSAgent, make logs public 07:25:43 Zakim, this will be GA_SVGWG 07:25:43 ok, trackbot 07:25:44 Meeting: SVG Working Group Teleconference 07:25:44 Date: 22 June 2016 07:26:30 chair: Nikos 07:26:32 scribe: nikos 07:26:34 scribenick: nikos 07:28:27 present+ nikos 07:28:32 present+ AmeliaBR 07:28:35 present+ Tav 07:29:18 Meeting: Amsterdam editors meeting 2016 Day 3 07:29:51 TabAtkins: You didn't camelCase meshGradient ... was that on purpose? ;) 07:30:42 Tav has joined #svg 07:43:12 present+ stakagi 07:43:19 Topic: Mesh gradient rendering 07:45:11 AmeliaBR: I prefer treating this just like a path, so fill-rule has an effect and the rendering is clipped to the outer path (which means the back side will not show) 07:45:43 Tav: I quite like the idea of overflow as a control 07:45:48 ... whether the back faces are shown or not 07:47:10 ... If you want to be able to stroke the path, I would like to implement using the same code we use to draw and fill paths, which means it would be clipped 07:48:00 nikos: The important thing imo is to be able to render in the usual mesh gradient way - with back faces showing 07:49:26 ... I don't mind having a control. I would suggest overflow should be the default because that matches other implementations of mesh gradients 07:49:56 ... whether you have overflow enabled or not, you'll still be able to stroke and add markers to the 'outer' path (which might not be the actual outermost path) 07:51:56 nikos: We might want to call it something other than overflow, because we're kind of overloading the term here. It's not a viewport that's being clipped and there'll never be scrollbars 07:55:53 AmeliaBR: We're going to want fill rule to control what path is clipped to 08:00:37 nikos: I don't think fill-rule is very important. It's not going to affect what is stroked 08:00:52 AmeliaBR: But it will control whether backfaces are filled or not 08:02:41 ... we can define as always nonzero for now and add evenodd later if authors request 08:04:13 RESOLUTION: Mesh gradients will have some sort of overflow control that defines whether any path exists outside of the author defined 'outer' path (which will be the equivalent path). Painting will be performed with fill-rule equal to nonzero. 08:51:52 AmeliaBR has joined #svg 08:52:04 Regarding https://github.com/w3c/svgwg/issues/26 08:52:22 Test case for SVG links inside links: http://jsbin.com/nidixomute/1/edit?html,output 08:53:10 Currently, Chrome and Safari do not render the content inside the nested link (the orange ellipse is visible, no blue link to the GitHub issue) 08:56:27 Firefox and Edge do render & link the blue ellipse correctly 08:56:40 ("correctly" being how we'd like to spec SVG 2) 08:57:34 (Technically, Chrome & WebKit are correct by SVG 1.1: don't render SVG elements that are in places they don't belong.) 11:43:50 Topic: Gradient transforms 11:44:07 https://github.com/w3c/svgwg/issues/135 11:44:23 Tav: The gradient transform is supposed to be applied last 11:44:48 ... that is, it is supposed to be post multiplied but it says 'inserted to the right of' any previously defined transformations 11:44:53 ... which in matrix notation is actually the opposite 11:44:59 ... the transform matrix on the left gets applied last 11:45:31 AmeliaBR: Can we get rid of left and right and just say post or pre multiplied? 13:03:07 AmeliaBR has joined #svg 14:55:17 RRSAgent, make minutes 14:55:17 I have made the request to generate http://www.w3.org/2016/06/22-svg-minutes.html nikos 14:56:46 Thanks for your hard work!! 14:57:28 Thanks Takagi-san. It's such a shame you couldn't join us . 14:58:18 I almost feel better! 14:58:45 Thank you for your concern. 14:59:10 I'm very glad to hear that 15:26:06 nikos: ...yes? We agreed not to camelcase any new element names ever again. 15:26:30 My recollection was things could be camelcased for consistency with camelcased names 15:26:38 meshGradient fits with linearGradient, etc 15:28:08 That violates the entire reason for avoiding new camelcase in the first place... 15:28:56 yeah but it gives people a chance to guess what they should type 15:29:07 "But just one more, we promise!" isn't very convincing. ^_^ 15:29:24 maybe we should call it gradientmesh ;) 15:29:34 I'd rather swap the names around somehow, yeah. 15:30:01 Or like, and 15:30:08 so mesh is the geometry element 15:30:17 we separated the geometry element and the paint server element 15:30:27 cos having to switch interfaces, etc was messy 15:30:32 Yeah, I got that. 15:31:22 (Can specify its geometry on its own, or is it required to get that from a ? 15:31:23 I'd be happy enough calling it gradientmesh - A Gradient Mesh (as opposed to a mesh based gradient) is a specific implementation, but ours satisfies that now we have smoothing 15:31:25 ) 15:32:42 mesh has a meshGradient child, in the same way that rect can have a paintserver child now 15:33:43 Tav has joined #svg 15:33:43 Right. I'm asking if that's *required*, or if it can specify its shape on its own and, like, fill itself with just "red" or something. 15:35:01 no the meshgradient is required now. I would like to expand to flat fill later though 15:35:16 Okay, cool, I was just wondering. 15:37:23 You can still have a path, circle, polygon, etc that uses meshGradient as a paint server. But a mesh without a meshGradient is specced to act like a path without a d attribute. 15:45:21 Tav has joined #svg 15:47:23 Yup, that all makes sense. Cool. 17:23:59 Tav has joined #svg 18:08:54 Tav has joined #svg 20:19:41 shepazu has joined #svg 20:58:28 Tav has joined #svg 22:21:10 shepazu has joined #svg