SVG Working Group Teleconference -- 15 Dec 2016

<scribe> scribe: nikos

Publish FPWD SVG Animations

We talked about publishing FPWD of SVG Animations

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> 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: http://tavmjong.free.fr/SVG/POLYFILL/canvas_in_svg_clipped.svg

<AmeliaBR> 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

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> https://jsfiddle.net/dodgeyhack/7h0csof5/ https://usercontent.irccloud-cdn.com/file/VzrLWTTg/MS%20Edge%20results%20for%20marker%20test

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

- DRAFT -

SVG Working Group Teleconference

15 Dec 2016

Attendees

Contents

Publish FPWD SVG Animations

Extending SVG - pain points

Testing

marker directionality

Summary of Action Items

Summary of Resolutions

Scribe.perl diagnostic output