W3C home > Mailing lists > Public > www-svg@w3.org > October 2016

Minutes, 6 October 2016 SVG WG telcon

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>
Message-ID: <345A499A-8328-4272-A2BC-9402BE4F0E58@cisra.canon.com.au>
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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:55:06 UTC