Minutes, 15 December 2016 SVG WG telcon

https://www.w3.org/2016/12/15-svg-minutes.html


   [1]W3C

      [1] http://www.w3.org/

                               - DRAFT -

                    SVG Working Group Teleconference

15 Dec 2016

   [2]Agenda

      [2] https://lists.w3.org/Archives/Public/www-svg/2016Dec/0007.html

   See also: [3]IRC log

      [3] http://www.w3.org/2016/12/15-svg-irc

Attendees

   Present
          nikos, shepazu, Tav, stakagi, AmeliaBR

   Regrets
   Chair
          Nikos

   Scribe
          nikos

Contents

     * [4]Topics
         1. [5]Publish FPWD SVG Animations
         2. [6]Extending SVG - pain points
         3. [7]Testing
         4. [8]marker directionality
     * [9]Summary of Action Items
     * [10]Summary of Resolutions
     __________________________________________________________

   <scribe> scribe: nikos

Publish FPWD SVG Animations

   We talked about publishing FPWD of SVG Animations

   [11]http://andronikos.id.au/svgwg-spec/animations/Overview.html

     [11] http://andronikos.id.au/svgwg-spec/animations/Overview.html

   This is the animation chapter from SVG 1.1 which wasn't copied
   into SVG 2

   scribe: There's some additions, but I expect they will be
   dropped before CR
   ... so this will be purely what's implemented now

   AmeliaBR: Have you been in touch with Brian?
   ... is he ok publishing as is?

   nikos: Yes I have, he is supportive of eventually publishing
   without the extra additions
   ... though he doesn't have time to do any substantive editing
   ... Note this was listed as level 2 before, but I removed that
   version number because we'll be removing the new features like
   discard, etc
   ... There's a changes appendix that lists what has changed in
   this document since it was taken out of SVG 1.1

   RESOLUTION: Publish FPWD of SVG Animations

Extending SVG - pain points

   <Tav> [12]http://tavmjong.free.fr/SVG/POLYFILL/

     [12] http://tavmjong.free.fr/SVG/POLYFILL/

   Tav: My plan for polyfilling fills - particularly mesh
   gradients, is to create a canvas the size of the fill inside
   the object
   ... so insert a foreignObject that is the size of the mesh you
   want. Put a canvas inside that fO and clip to the shape you're
   filling
   ... then render the stroke on top of that
   ... I came across a few problems
   ... problem number one is that Canvas is not rendered at the
   same places in all browsers
   ... You can see this in my 'Test'
   ... In Chrome you're not seeing the purple, which is the
   background to the foreignObject
   ... On Firefox you see two Canvas objects - the green and the
   yellow
   ... Once you're in the foreignObject it's treated as HTML so
   objects get stacked
   ... But if you look at he Chrome version, you do not see the
   Canavs objects inside the foreignObject

   nikos: Yeah I can see them, but they're not inside the square

   AmeliaBR: foreignObject is horribly buggy

   Tav: In Chrome I won't be able to paint my fill with the way
   it's currently working

   AmeliaBR: My recommendation would be to avoid foreignObject and
   use an offscreen canvas, extract it as an image and use a data
   URI

   <AmeliaBR> Compare with conic-gradient:
   [13]http://tavmjong.free.fr/SVG/POLYFILL/canvas_in_svg_clipped.
   svg

     [13] http://tavmjong.free.fr/SVG/POLYFILL/canvas_in_svg_clipped.svg

   <AmeliaBR> [14]https://leaverou.github.io/conic-gradient/

     [14] https://leaverou.github.io/conic-gradient/

   AmeliaBR: leaverou didn't have an option of using an on screen
   Canvas because this is a CSS feature
   ... so she had to get an image that could be used by another
   CSS function
   ... you could look at the way she's extracting the image from
   the offscreen canvas
   ... think she gets an offscreen canvas, generates a data uri,
   and puts it in an SVG so it's scalable

   Tav: that sounds like a good solution

   AmeliaBR: It does remind us that we need better testing suites
   for foreignObject

   nikos: Don't know exactly where the right place to put your
   test is, but it would be worth turning it into a reftest and
   submitting to web-platform-tests

   Tav: second problem I think isn't such a problem
   ... it's to do with clipping to self, but I don't think I need
   to do that
   ... it would be nice because you could do stroke-inside that
   way
   ... in this case Chrome does it correctly but Firefox does not

   AmeliaBR: I've found this before when using the use element.
   Found you need a defs elsewhere so circular reference tests
   don't discard it

   Tav: It's nice to be able to clip to self, but not neccessary

   AmeliaBR: you can get around it by using a 'pattern' as the
   basis for the polyfill

   nikos: Cool, sounds promising for being able to complete this

   AmeliaBR: this is interesting and exciting!

   Tav: The next version of Inkscape will definitely have mesh
   gradients
   ... Have a nice way of colouring where you spray and it affects
   the vertices
   ... or sample the colours from some picture underneath
   ... Should have release candidate done by the end of the year

Testing

   nikos: I had a little play with running Firefox tests in Webkit
   ... ran into some silly flaky script issues
   ... so I don't have a full list of results
   ... but the tests transfer over easily - just need to rename
   the refs for Webkit
   ... but Webkit runs WPT, or at least a subset ( I need to
   check)
   ... so a better path is to get firefox tests into WPT
   ... the concern with importing tests into WPT is the manpower
   needed to check they're correct
   ... so not too much to report, but I created another PR for
   some new marker tests

   AmeliaBR: were you able to find solutions that didn't have the
   anti aliasing issue?

   nikos: So first off I removed the viewBox so everything maps to
   the parent document space
   ... I also restructured the tests so they differ minimally by
   what is being tested
   ... rather than making the reference out of only path elements
   for example
   ... but even just removing the viewBox helped a lot to make
   things more consistent
   ... I haven't updated the guidelines yet, but I'll do that

   AmeliaBR: going forward it will probably mean less work setting
   up the references if we are just trying minimise the difference
   between the ref and the test
   ... the key then is to make sure we have the proper sequence of
   tests

   nikos: In one of my tests I used a clip-path to simulate a
   viewBox - I made the marker sizes different so that at least if
   viewBox and clip-path weren't doing their job the test would
   still fail

   AmeliaBR: so the shape outside the overflow was different in
   each case?

   nikos: Yes

   AmeliaBR: The other thing with this topic is setting up so we
   can have maximum community sourced involvement
   ... would it make sense to set up a CG that is SVG testing?
   ... is there an underutilised group we can take over?
   ... when I tweeted that SVG 2 is dying I got a lot of questions
   about how to help
   ... one option is take an SVG 1.1 test and make a new reference

   nikos: That's a good way to get the community to help out -
   basically we want to minimise the barrier to jumping in
   ... probably need to make a list of candidate tests
   ... and some step by step instructions

   shepazu: We could make a community group or we could just try
   to do it on github

   AmeliaBR: certainly one option is to create a whole set of
   Github issues

   shepazu: I'd be perfectly happy doing an SVG testing community
   group
   ... think we should coordinate with the W3C on that
   ... I feel Github has the lowest barrier to entry
   ... community group does have that centrality and officialness

   AmeliaBR: think it's a matter of a combination - create a
   community group with a mailing list for central command
   ... use github to track test by test
   ... with Github for tracking what tests are needed - anyone can
   file that without getting involved in the CG

   shepazu: I'm happy to create the CG. THink this is something we
   should do in January
   ... think the CG might be a good place to talk about the
   polyfill

   nikos: Don't know if I'll be around, but that should be the
   topic for the first telcon in January

   AmeliaBR: the other thing that may be worth trying again is
   seeing if we can get more involvement from browsers - if it's
   clear that the focus is on testing and interop

   nikos: Yeah we might get a different set of involved people -
   like gsnedders

   shepazu: if it is a CG we might get more people too

   nikos: Yeah we could totally open up the telcons - if we need
   to have a 15 minute official one we can do that
   ... think that would be a good way to keep people who are
   submitting engaged

   shepazu: We want an easy way for people who find problems or
   gaps to bring those up and then we can push the changes to
   resolve that

marker directionality

   [15]https://github.com/w3c/svgwg/issues/300

     [15] https://github.com/w3c/svgwg/issues/300

   AmeliaBR: The issue is when you have a closed path with a sharp
   corner at the start/end
   ... should markers auto angles be calculated the same way they
   are at any other sharp corner?
   ... which is what we say in the spec
   ... when Nikos tested this, browsers are inconsistent in their
   result

   nikos: I haven't double checked 1.1 but I assume this is a
   clarification for something that was vague

   Tav: thought we had resolved that mid angle should only be used
   on marker-mid

   AmeliaBR: You can't put a mid marker on the start/end point of
   a closed path
   ... ideally you'd put marker-start and marker-mid and that
   would cover ever corner

   nikos: I think we definitely want to keep the SVG 2 specced
   behaviour

   Tav: Yeah you do want to use the in and out when it's closed
   ... I did some tests on this a couple of months ago - there's a
   difference in how you close
   ... if the closing segment is zero length there were issues
   with some browsers

   AmeliaBR: that's partly why we added clarifications about
   ignoring zero length paths when working out directionality

   nikos: The other thing I was questioning in the issue is
   whether auto-start-reverse should always be 180 degrees, even
   on a closed path

   AmeliaBR: I say that yes it should

   Tav: I agree

   AmeliaBR: then we just need to confirm what auto is to get
   consistency

   nikos: In terms of what auto is, I'm very happy with the way
   that SVG 2 is currently specced

   AmeliaBR: that closed corners are treated like any other
   corner?

   nikos: yes

   Tav: I agree
   ... and if you want different behaviour, don't close the path

   nikos: That's what the tests I submitted to WPT verify so no
   changes needed there

   <AmeliaBR> [16]https://jsfiddle.net/dodgeyhack/7h0csof5/
   [17]https://usercontent.irccloud-cdn.com/file/VzrLWTTg/MS%20Edg
   e%20results%20for%20marker%20test

     [16] https://jsfiddle.net/dodgeyhack/7h0csof5/
     [17] https://usercontent.irccloud-cdn.com/file/VzrLWTTg/MS Edge results for marker test

   nikos: So they do follow the SVG 2 spec, but don't support
   auto-start-reverse at all

   AmeliaBR: We need to note in the PR for the tests that it's
   expected that browsers are all different for one of those tests

Summary of Action Items

Summary of Resolutions

    1. [18]Publish FPWD of SVG Animations

   [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, 16 December 2016 00:04:00 UTC