- From: Nikos Andronikos <Nikos.Andronikos@cisra.canon.com.au>
- Date: Thu, 6 Oct 2016 22:29:32 +0000
- To: www-svg <www-svg@w3.org>
https://www.w3.org/2016/10/06-svg-minutes.html
[1]W3C
[1] http://www.w3.org/
- DRAFT -
SVG Working Group Teleconference
06 Oct 2016
[2]Agenda
[2] https://lists.w3.org/Archives/Public/www-svg/2016Oct/0001.html
See also: [3]IRC log
[3] http://www.w3.org/2016/10/06-svg-irc
Attendees
Present
nikos, Tav, stakagi, Shane, birtles, shepazu, krit,
AmeliaBR, smfr, Rich_Schwerdtfeger, jwatt, tabatkins,
Alex, Russell, Philip, Rogers, (pdr), Rossen, Bogdan,
Stephens, ChrisL, dbaron, fguimont, Adrian, Bateman
Regrets
Chair
Nikos
Scribe
Nikos
Contents
* [4]Topics
1. [5]Proposed Charter
2. [6]W3C persepective on SVG 2 ongoing
* [7]Summary of Action Items
* [8]Summary of Resolutions
__________________________________________________________
trackbot, start telcon
<krit> +krit
<jwatt> +jwatt
<shepazu> [9]https://w3c.github.io/charter-drafts/svg-2016.html
[9] https://w3c.github.io/charter-drafts/svg-2016.html
<scribe> scribe: Nikos
<scribe> scribenick: nikos
Proposed Charter
[10]https://w3c.github.io/charter-drafts/svg-2016.html
[10] https://w3c.github.io/charter-drafts/svg-2016.html
<shepazu>
[11]https://w3c.github.io/charter-drafts/svg-2016.html
[11] https://w3c.github.io/charter-drafts/svg-2016.html
<shepazu>
[12]https://w3c.github.io/charter-drafts/svg-2016.html
[12] 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> [13]https://svgwg.org
[13] 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
[14]https://nikosandronikos.github.io/svg2-info/svg2-feature-su
pport.html
[14] 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
Summary of Action Items
Summary of Resolutions
1. [15]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
[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 Thursday, 6 October 2016 22:30:05 UTC