See also: IRC log
<scribe> scribe: nikos
<scribe> scribenick: nikos
<scribe> Meeting: Amsterdam editors meeting 2016 Day 3
TabAtkins: You didn't camelCase meshGradient ... was that on purpose? ;)
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 https://github.com/w3c/svgwg/issues/26
<AmeliaBR> Test case for SVG links inside links: 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.)
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?
This is scribe.perl Revision: 1.144 of Date: 2015/11/17 08:39:34 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Found Scribe: nikos Inferring ScribeNick: nikos Found ScribeNick: nikos Present: nikos AmeliaBR Tav stakagi Found Date: 22 Jun 2016 Guessing minutes URL: http://www.w3.org/2016/06/22-svg-minutes.html People with action items:[End of scribe.perl diagnostic output]