See also: IRC log
trackbot, start telcon
<krit> +krit
<jwatt> +jwatt
<shepazu> https://w3c.github.io/charter-drafts/svg-2016.html
<scribe> scribe: Nikos
<scribe> scribenick: nikos
https://w3c.github.io/charter-drafts/svg-2016.html
<shepazu> 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
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
This is scribe.perl Revision: 1.144 of Date: 2015/11/17 08:39:34 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/thos/those/ Succeeded: s/55 hours/55 days/ Found Scribe: Nikos Inferring ScribeNick: nikos Found ScribeNick: nikos 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 Agenda: https://lists.w3.org/Archives/Public/www-svg/2016Oct/0001.html Found Date: 06 Oct 2016 Guessing minutes URL: http://www.w3.org/2016/10/06-svg-minutes.html People with action items:[End of scribe.perl diagnostic output]