W3C

- DRAFT -

SVG Working Group Teleconference

22 Jun 2016

See also: IRC log

Attendees

Present
nikos, AmeliaBR, Tav, stakagi
Regrets
Chair
Nikos
Scribe
nikos

Contents


<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 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.)

Gradient transforms

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. 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]

Minutes formatted by David Booth's scribe.perl version 1.144 (CVS log)
$Date: 2016/06/22 14:55:22 $

Scribe.perl diagnostic output

[Delete this section before finalizing the minutes.]
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]