Minutes, June 2016 Amsterdam editors meeting, Day 3

Previous Topic Next Topic
classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view

Minutes, June 2016 Amsterdam editors meeting, Day 3

Nikos Andronikos


      [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


          nikos, AmeliaBR, Tav, stakagi




     * [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
   ... 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

   <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

   <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

   <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

Gradient transforms


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