- From: Nikos Andronikos <Nikos.Andronikos@cisra.canon.com.au>
- Date: Fri, 1 Jul 2016 03:32:31 +0000
- To: www-svg <www-svg@w3.org>
https://www.w3.org/2016/06/22-svg-minutes.html [1]W3C [1] http://www.w3.org/ - DRAFT - SVG Working Group Teleconference 22 Jun 2016 See also: [2]IRC log [2] http://www.w3.org/2016/06/22-svg-irc Attendees Present nikos, AmeliaBR, Tav, stakagi Regrets Chair Nikos Scribe nikos Contents * [3]Topics 1. [4]Mesh gradient rendering 2. [5]Gradient transforms * [6]Summary of Action Items * [7]Summary of Resolutions __________________________________________________________ <scribe> scribe: nikos <scribe> scribenick: nikos <scribe> Meeting: Amsterdam editors meeting 2016 Day 3 TabAtkins: You didn't camelCase meshGradient ... was that on purpose? ;) Mesh gradient rendering 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) Tav: I quite like the idea of overflow as a control ... whether the back faces are shown or not ... 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 nikos: The important thing imo is to be able to render in the usual mesh gradient way - with back faces showing ... I don't mind having a control. I would suggest overflow should be the default because that matches other implementations of mesh gradients ... 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) ... 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 AmeliaBR: We're going to want fill rule to control what path is clipped to nikos: I don't think fill-rule is very important. It's not going to affect what is stroked AmeliaBR: But it will control whether backfaces are filled or not ... we can define as always nonzero for now and add evenodd later if authors request 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. <AmeliaBR> Regarding [8]https://github.com/w3c/svgwg/issues/26 [8] https://github.com/w3c/svgwg/issues/26 <AmeliaBR> Test case for SVG links inside links: [9]http://jsbin.com/nidixomute/1/edit?html,output [9] http://jsbin.com/nidixomute/1/edit?html,output <AmeliaBR> 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) <AmeliaBR> Firefox and Edge do render & link the blue ellipse correctly <AmeliaBR> ("correctly" being how we'd like to spec SVG 2) <AmeliaBR> (Technically, Chrome & WebKit are correct by SVG 1.1: don't render SVG elements that are in places they don't belong.) Gradient transforms [10]https://github.com/w3c/svgwg/issues/135 [10] https://github.com/w3c/svgwg/issues/135 Tav: The gradient transform is supposed to be applied last ... that is, it is supposed to be post multiplied but it says 'inserted to the right of' any previously defined transformations ... which in matrix notation is actually the opposite ... the transform matrix on the left gets applied last AmeliaBR: Can we get rid of left and right and just say post or pre multiplied? Summary of Action Items Summary of Resolutions 1. [11]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. [End of minutes] The information contained in this email message and any attachments may be confidential and may also be the subject to legal professional privilege. If you are not the intended recipient, any use, interference with, disclosure or copying of this material is unauthorised and prohibited. If you have received this email in error, please immediately advise the sender by return email and delete the information from your system.
Received on Friday, 1 July 2016 03:33:08 UTC