SVG Working Group Teleconference -- 20 Oct 2016

<scribe> scribe: nikos

<scribe> scribenick: nikos

New charter

nikos: Is there anything we need to do, or any update?

shepazu: Internally, W3M decided Wednesday to extend the group to the end of January to give us time to sort out the charter
... I've made some small updates to the charter and I'd like to go over those

<AmeliaBR> https://w3c.github.io/charter-drafts/svg-2016.html

shepazu: main changes were scoping the charter to be very explicit about finalising SVG 2and offering a concrete mechanism to preserve things that do not make it into SVG 2, for some future version of SVG
... e.g. if barename xref doesn't make it in, the suggestion is to put it into a note
... a note is a non normative document published on W3C's site
... from there it might be picked up and turned into a spec in a later charter period - or go to incubation
... incubation might mean that not only is it spec'd well, everyone is signed up for the way you've defined it
... further incubation would be getting implementation commitments
... charter covers that mechanism
... as a side note, we should try to push for as many tests as we can, even if features aren't planned for implementation soon.
... next change to the charter (and this may change back) - on the charter for web platform group, there was a problem with the charter
... MS objected to joint deliverables between Aria and web platform group
... to forestall that object, plh suggested I remove joint deliverable status and make them owned by either aria or svg
... there was push back from team contact of aria
... I said svg wg was fine keeping joint deliverables so right now the charter says there are no shared deliverables but I'm going to revert that change and send it to the AC
... I think we're on track to send the charter to the AC for review some time in the next month
... unless we hear from anyone that they don't think it's ready
... currently being reviewed by W3M

AmeliaBR: think it's ok from our end

Tav: It sounds good, I'm wondering about the future of the group. Even before the one year extension ends
... unless we get new contributors I'm not sure how we're going to get the work done

nikos: I'm taking a wait and see approach at the moment, trying to get the test suite off the ground. Then we can see how much work we expect it to be, and whether we are able to bring people on board to assist.
... I plan to volunteer some time over the year even if I'm not a member - maybe one night a week

Testing

https://github.com/w3c/svgwg/wiki/Testing

<AmeliaBR> scribenick: AmeliaBR

Nikos: I created this wiki (link above) to describe the main process for how to create tests.
... We've mostly agreed to use web-platform-test, but it is very web-browser specific, we may need to make adjustments for other user agents like Inkscape.

Tav: I think it's straightforward so long as the reference is either SVG or PNG.

Nikos: PNG has issues, because then we'd probably need separate reference images for each platform.

AmeliaBR: Is that really true? If you're using default system fonts, then yes, but for most SVG you should get the same rendering on all platforms.

Tav: And for fonts, we can use web fonts to get consistency.

AmeliaBR: I'd be more worried about using SVG as a reference. User agents may match the reference rendering on their own system, but still not be cross-compatible because of lower-level rendering issues.

Tav: Either way, the may concern is that the references aren't HTML files, since we can't run them to compare.

Nikos: You could use some other rendering agent to convert those to PNG references.

Tav: That adds a new level of complexity.

Nikos: The issue is that web platform tests doesn't give us strict control over what gets added. Anyone who's had a good reputation with the project gets write access to approve tests.

Tav: There are many things about it I like. I like being able to click and see the reference image. I like having versioning control.
... One problem is that it is quite a huge repository, and it will get even larger as CSS joins.

Nikos: So you don't want to download the whole repo?

Tav: The repo itself is not a big problem, but watching for all the issues could be very overwhelming. Having it all in one repo seems not very manageable.
... I expect it's something that's been discussed internally, but for now we'll have to deal with it as best we can.

Nikos: We could make a fork of the repo, and use it to do all the subject-matter discussions, then when we decide on those, push them to the main repo for a final approval of the format.

AmeliaBR: I like that idea if we can make it work. Funnel things through a 2-stage pull request.

Tav: There's already SVG tests there. Mozilla uploaded a lot in the past few weeks.

Nikos: Yes, one of the goals of web-platform-tests is to make it easy for browsers to dump their internal testing suites, to quickly add new tests.

Tav: I like the idea of making it easy to add tests. But that doesn't always make it easy to use them.

<nikos> ACTION: Nikos to think about how we can mitigate the issues that arise of being part of a large repository [recorded in http://www.w3.org/2016/10/20-svg-minutes.html#action01]

<trackbot> Created ACTION-3857 - Think about how we can mitigate the issues that arise of being part of a large repository [on Nikos Andronikos - due 2016-10-27].

Nikos: For example, these href tests are all HTML reference documents. So you'd need to filter those out.

Tav: Another issue is how we are going to organize things. E.g., the sub-folders for the chapters, and then there are elements and attributes. But what about things that aren't either elements or attributes?

Nikos: I think we should have guidelines for naming, but not too strict. Because there will always be something that doesn't fit the naming scheme.

Tav: As we import the SVG 1.1 tests, I notice you removed some of the metadata. Would it be possible to leave that? It doesn't hurt to keep it.

Nikos: I kept some of it if I thought it was useful. But, e.g., the prose description of the result isn't needed when we have reference images.

Tav: And then, as I already mentioned, issue with HTML references.

Nikos: Would we be able to create an automated script to convert HTML references to SVG?

AmeliaBR: If the HTML page is just a wrapper for a single inline SVG, that might be feasible. Would need some review, but might cover most cases.

Nikos: What about reviewing the tests we're importing from SVG 1.1?

<nikos> https://github.com/w3c/web-platform-tests/pull/4015

AmeliaBR: They all need some sort of review.

Nikos: That's my feeling, although it will slow things down. This is the pull request. One way to get yourself established on the repo is to start by reviewing the pull requests.

Tav: A lot of activity there.

Nikos: Yes, some of their tools are a little flakey, had to do a lot of adjustments. If anyone has difficulties trying to set up the tools on your own computer, let me know. I may have already figured it out myself.
... Any last questions or comments on this topic?

Doug: I think you've made a good start.

<nikos> scribenick: nikos

Moving some SVG 2 features to WICG

nikos: Mesh gradients is the first thing we want to look at here

AmeliaBR: hatches and maybe solidcolor can tag along

nikos: It's a bit odd moving this to WICG because it's so mature
... We're not going to remove it from the spec as soon as we raise the issue at WICG
... we want to get some discussion happening and see if we can keep mesh gradients in

AmeliaBR: So the purpose of the CG is to discuss implementation possibilities for the new paint servers for the SVG 2 spec? Which may include a recommendation at the end of the incubation period to leave it in the spec, or move it to a module

shepazu: I like your focus there, but I agree with Tav that mixing it all in may be a bad idea
... no one knows what a paint server is
... gradient mesh, hatching, and solid fill is three things, when the one thing we really want is mesh gradients, and it's easier to make a case for that

nikos: also if we are getting people on board to support, we want them to be able to point to one feature and say they support that

Tav: that reflects what I'm thinking - keeping it simple and focused

AmeliaBR: part of the problem with SVG 2 was at the time the original requirements list was set up for a very different audience and use case than where the browser attention is now
... svg in a web page use cases are very different to svg as an artwork format
... using a visual editor, it's hard to see where the benefit of z-index comes from

nikos: So I'd like to prepare a draft of what we'll propose to WICG

Tav: I'm away for two weeks so won't have much time

AmeliaBR: we can circulate and have a discussion and then Tav can get involved when back

- DRAFT -

SVG Working Group Teleconference

20 Oct 2016

Attendees

Contents

New charter

Testing

Moving some SVG 2 features to WICG

Summary of Action Items

Summary of Resolutions

Scribe.perl diagnostic output