SVG Working Group Teleconference -- 06 Oct 2016

trackbot, start telcon

<krit> +krit

<jwatt> +jwatt

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

<scribe> scribe: Nikos

<scribe> scribenick: nikos

Proposed Charter

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

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

shepazu: This charter is a short term one year charter
... it assumes that the only work item is the completion of SVG 2
... which means finalising the spec and removing any at risk features, making sure everything in the spec is tested and has implementations
... there are some additional deliverables, that have to do with a11y TF
... there is some overlap between a11y TF and SVG WG but it's just a few people
... the final deliverable is the SVG authoring guide - which is a non normative guide to authoring SVG
... which includes SVG 2 features and is intended to be aspirational to let authors see what they would like implemented

nikos: a lot of deliverables have been moved to the CSSWG and the FXTF is not in the proposed charter

AmeliaBR: that was decided at TPAC?

nikos: yes

<krit> https://svgwg.org

shepazu: final thing to note is the few modules (paths, stroke, and markers), those were broken out of hte new spec and include new features
... those are not included in the new charter

nikos: but could be picked up by a future WG / CG

shepazu: So the scope of the charter was narrowed further at TPAC
... part of our goal today is to decide if this is a reasonable plan and if there's a path forward for this

W3C persepective on SVG 2 ongoing

plh: From the W3C perspective we have SVG 1.1 and the spec is 10-12 years old

shepazu: SVG 1.1 SE was published in 2012

plh: it fixes bugs from the previous version
... so what I'm looking for is the next step after that
... my minimum bar is that there are probably more bugs to fix in the spec
... and we should find a path to update that recommendation, to fix those bugs
... also implementations have been evolving so we should reflect that
... I understand SVG 2 has features that do contain 2 implementations but are not part of SVG 1.1 SE
... so they should be part of the next SVG
... then there are things that don't have two implementations - and we should figure out what to keep and what not to keep
... I'm not her eto tell you how to make that call, but from a process point of view, we need implementation experience
... then there are things that are not close to having two implementations and we don't know how we'll get implementations
... in my opinion we'll need to drop those
... or we'll never get to ship the REC
... I'm looking for an update path where we can fix bugs in the existing SVG 1.1 spec, add things that have two implementations that aren't in SVG 1.1

TabAtkins: that's what we want as well
... we would love to see the SVG WG continue it's work filling in corner cases and better defining them

<scribe> ... new features that haven't picked up interest yet should be pushed to WICG

UNKNOWN_SPEAKER: don't want them to hold up the draft itself
... that way we can get SVG 2 done in the next year

alex: There's going to be questions about how to integrate accessibility and other features into SVG and that could go beyond a year charter

TabAtkins: a few of the things we want to pull out are hatch and mesh gradients - they are valuable features, it's a brand new feature that hasn't been well implemented
... and can be independently developed just fine
... and developed in WICG until we get implementer interest
... separating out things that haven't picked up implementer interest would help with the one year plan

adrian: I'm in favour of progressing with removing the features taht clearly haven't captured the enthusiasm of implementers
... if we can easily identify the things that aren't going to gain implementation soon
... it's going to be difficult to say we have good experience with them and progress
... we should identify and remove them quickly
... for other things where there is interest and there is some implementation work being done, I want us to be pragmatic
... if there is enough experience in the group implementing a feature
... and the spec is in good shape and describes what we all agree can and should be implemented
... then I want to make sure we don't get stuck in a trap of not making progress because things aren't perfect
... spec will never be perfect
... move forward with things we do have experience with

tess: We largely agree with what Adrian said
... as far as short term work in SVG - we are mostly concerned with perf fixes and compatibility problems with our own engine
... probably some low hanging fruit SVG 2 stuff we could do
... charter seems reasonable, what Adrian said seems reasonable
... See Dean's email for more

krit: When I look at the current spec that went to CR
... we see a bunch of features that got added
... mesh gradients, hatches, etc
... many of those features are at risk which is fine for CR and shouldn't block REC
... if we know for other features we ahve two implementations
... keeping them in and see how other features proceed
... for Adobe, the most important thing is SVG should be accessible
... SVG 2 has improvemetns there and a11y TF specs are coming up
... for SVG again, many of the features that aren't named yet have one implementation
... so I don't see SVG 2 as being in bad shape
... another part is Adobe have a strong interest in getting more features - e.g. mesh gradients, stroke features, variable width stroke, etc
... which do not neccessarily need to live in the SVG WG ,but we do want to see them proceed

<jwatt> mic issue

<jwatt> one sec, I'll change my headset

birtles: Our position is the same - we are very interested in compat fixes and simplifications, and reconciling SVG with HTML
... picking up low hanging fruit
... but we don't have plans for mesh gradients or hash patterns
... we are interested in z-index, have done the refactoring

jwatt: I'd be interested in z-index
... it's not a big change for us to implement
... to reiterate what Brian said - we are mostly interested in perf in our own engine and compatibility rather than new features
... interesting to hear from Adobe that they're interested in new features
... vast majority of people are going to want to use a tool
... so less likely to hear from authors waht they want, they'll go to the tool vendors
... wonder if there's something we can do there to get feedback
... we haven't been hearing much feedback other than performance and compatibility
... e.g. how the use element works

Tav: InkScape is very interested in mesh gradients and hatches

<Zakim> shepazu, you wanted to ask whether authoring tools and polyfills count as implementations

Tav: it's important for artists to be able to use these tools
... very disapointing to hear these are not high priority for others

krit: think we do agree interoperability is one of the most important things

cabanier: from what I've heard at Adobe accessibility, interop and performance

TabAtkins: seems to be consitent that browser vendors are focusing on interop and finish existing features
... not so interested in new features at the moment
... tools are interest in new features
... this is why separting things to WICG to gather interest is a good idea
... not blocking the spec
... moving things to WICG still lets you spend the time building, but builds interest organically rather than slowing down the spec

cabanier: so every new feature except accessibility should be in WICG?

AmeliaBR: not that simple

TabAtkins: things that have n't picked up implementer interst should be carved out - easy to carve out mesh gradients and hatch
... lots of things are small changes (e.g. dom changes) are probably ok even though no one is working on them eyt

https://nikosandronikos.github.io/svg2-info/svg2-feature-support.html

nikos: I've been working on a matrix to gather feedback - would like to get concrete feedback from each group. Would be good to get PRs from each group to update the data

shepazu: I was wondering what the current thinking counting authoring tools and polyfills as implementations for the purpose of CR exit?

plh: Interesting question. Political correct answer is you need to show dev experience

<TabAtkins> Back!

plh: my best recommendation is about providing a good argument to the director about how you are going to move the spec forward
... we dont' say implementation should be in web browser or not
... no such thing as a definitive answer
... svg is part of the editing system - that's why we don't see requests to browsers

<dbaron> I think if the spec is claiming that it's to be implemented in browsers, then you probably shouldn't be counting polyfills. But if the spec is a spec for JS library features, then it makes sense.

plh: bit of a chicken and egg problem
... I don't want to say Inkscape isn't an implementation of SVG

<Zakim> AmeliaBR, you wanted to discuss practical modularization possibilities

AmeliaBR: I just wanted to go over what we can do practically - agree with what plh said
... for many new features we've got a big step to cross over
... editors won't make markup if it won't be used in browsers and browsers wont support feature if it's not being used
... polyfills are a good solution for that
... in a broader sense - paint servers are an easy target for modularisation
... they can easily be pulled out because of a module
... whether it makes sense at this point with a pretty much complete spec
... not sure what incubation is expected
... there's a lot of small features and some tricky new features to separate out
... e.g. text chapter has been hugely rewritten and the new prose is about fixing unspecified details of the old spec
... and a lot is about supporting new features - multi line text and harmonisation of css
... separating out the new features would be a lot of spec work
... before we start that we probably want a serious discussion from implementors
... about wrapping text, etc

<Rossen_> wrapping text is not a priority for us

AmeliaBR: for browser implementations, a lot of these changes are supposed to be about helping them reuse CSS code
... then there's z-index, paint-order, vector-effects
... in many cases we have some implementations - do we want to be strict and say all features should go into a new module?
... or say they're out on the web and so they're an interop concern?

TabAtkins: antyhing that already has some interest is fine to keep here
... it's just features that have no web implementor interest that are suspect - nothing wrong with what InkScape have done but they have different concerns than browsers
... design of a feature isn't complete if web implementors haven't looked at it yet
... we don't have to be strict about this, we can be go piece by piece for a few issues. Don't need to decide everything now
... we want to get SVG 2 to stability
... anything on that track is fine, anything not get rid of

adrian: It sounds like we have two choices - we can keep the current spec as it is, if we do that there's no prospect of the spec progressing anytime soon
... or we can remove some things from the spec in order to get what plh describes as being a good story
... maybe there isn't consensus on what to remove and we're not going to agree on this call

<TabAtkins> ack

adrian: proposal is to move forward and recharter to narrow focus, remove features that aren't going to meet exit criteria anytime soon
... if people object to that we can talk, but I'm not hearing that

krit: SVG 2 spec is currently CR - what kind of progress to we expect? If features are not defined correctly then spec should not be in CR
... I get the impression that everyone feels the spec can not proceed at the moment and features are not implementable

adrian: it's not about not being implementable, it's about not getting experience necessary to indicate that

krit: it would have been better to get that input before going to CR - but a lot of those features are at risk anyway
... think we should focus on things that are not at risk

Rossen_: our push has been to get the spec to something shippable
... almost two years later we have something that can pretty much be shipped

<TabAtkins> +1 to Rossen

Rossen_: some things we need to mark at risk
... some things we can move to WICG

<shane> 100% agree with Rossen

shepazu: Going to CR was a declaration that we weren't adding anything new and in terms of new work things were stable

<shane> krit: for the record Rossen, Tab and I have been providing exactly the input you claim was missing before CR for at least 12 months now

shepazu: you're right we may need to go back to CR again

nikos: think we need to get concrete feedback - we're not going to work out what the svg 2 spec will look like that this call

plh: my goal is not to stop work on SVG - but publishing SVG on a regular basis
... ideally every WG should publish a REC on a three year basis

nikos: sounds reasonable and SVG 2 helps taht a lot because it's a big tidy up of what we had before and will make it easier to continue work

<Zakim> plh, you wanted to talk about regular releases of SVG

<Zakim> shepazu, you wanted to note that there's also the idea of closing the SVG WG, and to talk about timeline

shepazu: I counted that we have 138 distinct features
... 3 tests per feature for minimum viable testing strategy
... that gives 448 tests - that's about 55 days of testing, giving one hour per test
... obviously it's not going to happen in three months - but I want to be realistic. If we went full bore it would take that long to prepare the test suite

<Rossen_> smfr: are you saying you have that much perf work to do?

shepazu: I don't see us doing the work within this charter, there would need to be an extension or recharter if we are going to do this task
... I'm hearing from browser vendors that they would like to see SVG 2 reach some completion
... whether it's the way it is now or stripped back
... even with stripped down we are looking at at least an additional 3-6 months work
... and that's agressive
... don't know how you feel about comiting to that?
... need committment to help

plh: I would be concerned if the result was this was going to fall to W3C staff to complete the tests
... my idea would be the community at large would work to make svg better

AmeliaBR: do we need to consider in the charter to use more general language if we are going to split sections out?
... in terms of what the deliverables are
... if we split things out of svg 2, do the new modules automatically become in scope?
... can we be flexible?

jwatt: what format will the new tests be?

shepazu: we're looking to use web-platform-tests
... probably we would not transfer old tests over - if old tests apply we keep them in the existing test framework

jwatt: web-platform-tests sounds good to me, rather than converting old tests, it would be better to take tests from Mozilla's reftest for example

adrian: concrete proposal is to recharter SVG WG with narrow scope and narrow time frame to remove featuers that will not be implemented in that time frame

<TabAtkins> +1

<Rossen_> +1

adrian: it's about getting the spec progressing

<plh> +1

<shane> +1

RESOLUTION: Re-charter SVG WG for one more year with a focus on moving SVG 2 to REC with only the features that have implementor experience

Rossen_: can we try something shorter than a year?

shepazu: we should try for less than one year

<Rossen_> OK, recharter for <= 365 days

nikos: think that would only be a good idea if we can get concrete commitments for time from each member

plh: Adrian used the word pragmatic earlier - and it's good to emphasise rthat
... we don't need to have a fully comprehensive test suite. We want a spec within a year and it's a matter of telling a good story to the director to move things forward

<shepazu> (minimum viable test suite)

plh: and then we keep iterating

krit: spec in a year doesn't mean REC?

plh: it does mean REC
... if you don't have implementation you remove the feature from the spec

AmeliaBR: our next step then is sorting out what are implementors priorties
... so Nikos can you send an email to gather feedback?
... which features are implemented, partially implemented, or have some priority or not

<krit> nikos: is there a way to specify a priority of features that members would like to see proceed?

nikos: Keep an eye out on www-svg and I'll send something out

shepazu: having a point person for each implementation would be handy right now
... so we know who to talk to about plans

- DRAFT -

SVG Working Group Teleconference

06 Oct 2016

Attendees

Contents

Proposed Charter

W3C persepective on SVG 2 ongoing

Summary of Action Items

Summary of Resolutions

Scribe.perl diagnostic output