Minutes, 4th August 2016 SVG WG telcon

Previous Topic Next Topic
classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view

Minutes, 4th August 2016 SVG WG telcon

Nikos Andronikos


      [1] http://www.w3.org/

                               - DRAFT -

                    SVG Working Group Teleconference

04 Aug 2016


      [2] https://lists.w3.org/Archives/Public/www-svg/2016Aug/0006.html

   See also: [3]IRC log

      [3] http://www.w3.org/2016/08/04-svg-irc


          nikos, stakagi, Tav, shepazu_, AmeliaBR




     * [4]Topics
         1. [5]SVG 2 CR publication update
         2. [6]Self review - security and privacy questionnaire
         3. [7]fill and stroke shorthand
         4. [8]SVG Animation and SVG Integration specs
     * [9]Summary of Action Items
     * [10]Summary of Resolutions

   Char: Nikos

   <scribe> Scribe: Nikos

   <scribe> scribenick: nikos

SVG 2 CR publication update

   shepazu: I've mostly done my bit. Need to do some work to merge
   onto the correct branch. Will try to do it tonight.

   nikos: I need to do disposition of comments and request review
   from i18n and a11y. I'm preparing a list of new features and
   breaking changes that is a bit more friendly than the changes
   appendix. I'll hopefully get that done today.

   Once we have that we can request transition approval from the


     [11] https://github.com/w3c/svgwg/wiki/SVG-2-new-features


     [12] https://github.com/w3c/svgwg/wiki/SVG-2-breaking-changes

   shepazu: Nikos and I were talking earlier in the week about
   making a list of changes between SVG 1.1 and SVG 2 - so people
   can decide and evaluate what sort of review they are going to
   try to do

Self review - security and privacy questionnaire


     [13] https://www.w3.org/TR/security-privacy-questionnaire/

fill and stroke shorthand


     [14] https://github.com/w3c/svgwg/issues/230

   <TabAtkins> Verifying as fantasai and I pull in SVG's fill and
   stroke stuff - fill-rule doesn't actually apply to text in any
   way, right? I'm not seeing it with any effect, and it seems
   silly for it to, as the segment directions are undefined.

   <TabAtkins> Oh, hmm, should fantasai and I call in for this?

   <TabAtkins> Because we are working on this *literally at this

   most of us have only just seen the issue

   if you want to jump in you're welcome

   <AmeliaBR> TabAtkins: Re fill-rule, yes we explicitly state it
   doesn't apply here

     [15] https://svgwg.org/svg2-draft/text.html#TextRenderingOrder

   <TabAtkins> Okay, the 'fill-rule' property still states that it
   applies to text elements, so I was verifying.

   <TabAtkins> We're in now

   <shepazu> [16]https://github.com/w3c/svgwg/issues/230

     [16] https://github.com/w3c/svgwg/issues/230


     [17] https://lists.w3.org/Archives/Public/www-style/2013Jun/0678.html


     [18] https://lists.w3.org/Archives/Public/www-style/2014Feb/0609.html


     [19] https://lists.w3.org/Archives/Public/www-style/2016Mar/0358.html

   TabAtkins: Elika and I are writing this spec right now and our
   intention is to pull in everything svg needs so it can function
   as svg fill and stroke spec as well

   fantasai: we talked about fill and stroke being short hands
   ... for svg attributes there's no issue because of the order in
   which they are processed.
   ... the unsuffixed properties are not a shorthand of these
   ... it breaks a little bit with how properties work in css.
   ... question is what resets? doe stroke-opacity and
   fill-opacity for example?

   AmeliaBR: think we talked about this in the past and it would
   break way too much content
   ... it's an unfortunate naming situation where people maybe
   expect things to reset and we have to be very explicit with
   notes in the spec explaining this what is not part of the fill
   and stroke shorthand
   ... but there's no way we could have a backwards compatible way
   of making a short hand of any of these

   fantasai: last time we had a meeting it was an open question

   shepazu: I understand the desire but agree with AmeliaBR
   ... I could see another path - we could add a new property that
   is not 'stroke', but 'stroke-something'
   ... not elegant but could serve the same purpose
   ... don't mind aliasing stroke color for stroke

   fantasai: not going to alias it, stroke is going to be a
   shorthand for stroke-color at the least
   ... if we can't make it work correctly we won't have a
   shorthand relationship here

   shepazu: think whatever the shorthand is it should make the
   existing behaviour of svg

   fantasai: we're doing that

   AmeliaBR: the consequences are that the shorthand version of
   stroke and fill can't reset any existing properties
   ... does make sense for stroke geometry properties to have a
   new shorthand

   TabAtkins: if we go with 'stroke-dash' that's very close to our
   naming scheme

   Tav: stroke-color doesn't seem an appropriate name

   fantasai: you can set a color or image as background.
   stroke-color actually only takes colours
   ... stroke-image would also exist
   ... we went over this in Sydney

   AmeliaBR: all those new properties would only add up to
   describe the painting of the stroke. They wouldn't change the
   existing properties. It would just be a way of describing the
   layers of paint

   fantasai: it would just be fill-opacity that would be a bit

   <TabAtkins> [20]https://drafts.fxtf.org/paint/ is what we're
   working on btw

     [20] https://drafts.fxtf.org/paint/

   AmeliaBR: my suggestion would be to have a note in the spec
   saying whether or not it is included in the shorthand

   fantasai: we might do it by section

   AmeliaBR: the other issue is that there is also a draft spec
   that svg put together for advanced stroke geometry

   fantasai: we merged that in
   ... that was one of the action items we took in Sydney

   AmeliaBR: we're glad you're working on this
   ... as I mentioned on Github is that layering has changed in
   SVG 2
   ... SVG 2 allows multiple paint server layers with fallback as
   the last parameter
   ... but we didn't add css images beacuse we didn't get into all
   the sizing and positioning issues


     [21] https://svgwg.org/svg2-draft/painting.html#SpecifyingPaint

   AmeliaBR: this is where it is

   fantasai: don't think it would be good to add anything on top
   of SVG 1 until we've worked through everything
   ... can we not do that in svg 2?
   ... we're introducing layering in css. Not sure how it will end
   ... I know you're trying to go to CR right now, which means if
   we run into problems we can't fix them

   shepazu: think our goal is to get this capability in asap
   ... seems if it's added to css rather than svg 2 it can be
   added in a timely way and it should meet the goal
   ... is that correct?

   fantasai: yes, we could take co-editor from svg but we'd like
   to address this all at once in a nice coherent way
   ... not saying there will be issues, but can't say right now
   ... I would say take it out of SVG 2 and we'll work on it over
   the next 6 months
   ... we would be happy with cutting back our draft to move
   ... but we need to lock down the interaction

   shepazu: if the goal is to have the feature and we're not so
   set on the syntax
   ... if svg goes its own way I'd be concerned about conflicts
   ... so I'm very reluctant to introduce a feature in svg that
   may be overriden by css
   ... so as long as functionality is available in a timely way

   AmeliaBR: There's two different much requested features here -
   layering is one, but css image types is a bigger one
   ... if there is a movement from Tab and Elika to work on the
   spec and a commitment from implementers to follow through
   ... I'm ok with reverting that section to SVG 1.1 syntax for
   ... maybe with a note

   shepazu: it's more likely to be implemented quickly if it's a
   css feautre
   ... and this reduces our testing load

   <AmeliaBR> FXTF issues

     [22] https://github.com/w3c/fxtf-drafts/issues/

   RESOLUTION: we will roll back multi layered fill in SVG 2 and
   it will be defined in an FXTF module

   shepazu: To clarify, context-fill and context-stroke will not
   be removed

   AmeliaBR: the idea of using a child instead of a url id is
   important as well

   <scribe> ACTION: Tav to review CSS fill and stroke to ensure it
   captures everything from SVG [recorded in

     [23] http://www.w3.org/2016/08/04-svg-minutes.html#action01]

   <trackbot> Created ACTION-3851 - Review css fill and stroke to
   ensure it captures everything from svg [on Tavmjong Bah - due

   <scribe> ACTION: Nikos to make edits to SVG 2 to remove things
   going to CSS fill and stroke [recorded in

     [24] http://www.w3.org/2016/08/04-svg-minutes.html#action02]

   <trackbot> Created ACTION-3852 - Make edits to svg 2 to remove
   things going to css fill and stroke [on Nikos Andronikos - due

   shepazu: Tab and Elika, have you reviewed z-index in SVG?


     [25] https://www.w3.org/TR/SVG2/render.html#RenderingOrder

   AmeliaBR: The big difference is that 2d transform doesn't make
   a stacking context

   TabAtkins: I'll review it

SVG Animation and SVG Integration specs

   AmeliaBR: for SVG Animation I'd like to publish a FPWD of what
   we have - won't be any extra work on Brian
   ... for SVG Integration I'd like to bring the bits we depedn on
   into SVG 2

   nikos: Agree on SVG integration, we and other specs reference
   the processing modes and they should just be in svg 2
   ... that would save us spending lots of time tidying up the svg
   integration spec
   ... svg in OT is looking for something solid to reference too
   as well so should hopefully make them happy

   <AmeliaBR> [26]https://svgwg.org/svg2-draft/conform.html

     [26] https://svgwg.org/svg2-draft/conform.html

   AmeliaBR: currently the conformance section is an appendix, so
   we need to make a normative chapter we can put processing modes

   <scribe> ACTION: Doug to edit SVG 2 to include processing modes
   from SVG integration spec [recorded in

     [27] http://www.w3.org/2016/08/04-svg-minutes.html#action03]

   <trackbot> Created ACTION-3853 - Edit svg 2 to include
   processing modes from svg integration spec [on Doug Schepers -
   due 2016-08-11].

   AmeliaBR: why don't we make conform a proper chapter?

   shepazu: Let's do that

   RESOLUTION: Publish FPWD of SVG Animation pending Brian Birtles

   birtles: ping

   <scribe> ACTION: Nikos to prepare a blurb for front page news
   [recorded in

     [28] http://www.w3.org/2016/08/04-svg-minutes.html#action04]

   <trackbot> Created ACTION-3854 - Prepare a blurb for front page
   news [on Nikos Andronikos - due 2016-08-11].

Summary of Action Items

   [NEW] ACTION: Doug to edit SVG 2 to include processing modes
   from SVG integration spec [recorded in
   [NEW] ACTION: Nikos to make edits to SVG 2 to remove things
   going to CSS fill and stroke [recorded in
   [NEW] ACTION: Nikos to prepare a blurb for front page news
   [recorded in
   [NEW] ACTION: Tav to review CSS fill and stroke to ensure it
   captures everything from SVG [recorded in

     [29] http://www.w3.org/2016/08/04-svg-minutes.html#action03
     [30] http://www.w3.org/2016/08/04-svg-minutes.html#action02
     [31] http://www.w3.org/2016/08/04-svg-minutes.html#action04
     [32] http://www.w3.org/2016/08/04-svg-minutes.html#action01

Summary of Resolutions

    1. [33]we will roll back multi layered fill in SVG 2 and it
       will be defined in an FXTF module
    2. [34]Publish FPWD of SVG Animation pending Brian Birtles

   [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.