Minutes, 7 July 2016 SVG WG telcon

https://www.w3.org/2016/07/07-svg-minutes.html



   [1]W3C

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

                               - DRAFT -

                    SVG Working Group Teleconference

07 Jul 2016

   [2]Agenda

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

   See also: [3]IRC log

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

Attendees

   Present
          nikos, stakagi, AmeliaBR, Tav

   Regrets
   Chair
          Nikos

   Scribe
          Nikos

Contents

     * [4]Topics
         1. [5]Restore SVGSVGElement.prototype.getElementById
         2. [6]Use a single-case name for meshGradient
         3. [7]Publishing SVG 2 CR
         4. [8]use element changes to be shadow dom compliant
     * [9]Summary of Action Items
     * [10]Summary of Resolutions
     __________________________________________________________


Restore SVGSVGElement.prototype.getElementById

   [11]https://github.com/w3c/svgwg/issues/182

     [11] https://github.com/w3c/svgwg/issues/182

   nikos: First topic is a request we received about
   SVGSVGElementById
   ... It was planned to be moved onto another interface but
   jQuery compat caused issues with that
   ... signals from implementers are that they are happy to keep
   it
   ... there's nosubtle differences between
   SVGSVGElement.getElementById and document.getElementById or
   Element.querySelector
   ... so propose adding it back in and not deprecating
   ... and speccing exactly as in the DOM spec
   ... so returns first descendent element with that id
   ... if there's more than element with an id it's technically an
   error, but we want to define the behaviour just like DOM

   RESOLUTION: Restore SVGSVGElement.getElementById. Rescind
   previous resolution to deprecate. Spec just as it's specced in
   DOM - returns first descendant element in document order with
   the Id

Use a single-case name for meshGradient

   nikos: We received feedback from Anne as well regarding the
   name
   ... and we said if we got feedback from anyone else and we'd
   change

   Tav: I've looked at the code in WebKit and Blink, and I can't
   see what they're talking about
   ... as far as I can tell it's all handled in one or two
   functions that take care of SVG casing
   ... I do see some fast path stuff for colours in CSS, but there
   seems to be nothing special done
   ... So as far as I can see it's just adding one more line to a
   file
   ... so I don't know what to do next

   nikos: did you see my proposal about changing it to meshpaint?

   AmeliaBR: I like the argument that a generic name opens us up
   to future extensions

   nikos: It would be fairly simple to add once we have the mesh
   structure
   ... [12]http://snapsvg.io/
   ... this style is popular

     [12] http://snapsvg.io/

   Tav: That wouldn't be so easy to do with our structure because
   you have to duplicate corner points

   AmeliaBR: I'm not sure how extendable our format is because the
   path is on the stop element itself
   ... so if anything that would be an argument for leaving it
   specific

   nikos: My feeling is that we should change. We have had
   feedback from two people now.

   AmeliaBR: as far as I'm concerned, this was decided when
   meshrow and meshpatch was made all lower case
   ... would be weird to have meshGradient and meshrow
   ... I'm happy with gradientmesh or meshgradient

   nikos: I was leaning towards gradientmesh initially, but
   changing the order of words may be a second source of confusion
   ... so now I prefer meshgradient

   Tav: I would be ok with changing the spec and adding a note
   asking for comments from implementors on what they prefer
   ... I think it will look strange having it all lower case

   nikos: Sounds reasonable

   RESOLUTION: Rename meshGradient to meshgradient, add a note in
   the spec asking for feedback from authors and implementors as
   to their preference for use and separately their feedback on
   the difficulty of implementing camelcased element names

Publishing SVG 2 CR

   nikos: My intention was to branch and start the publication
   process on July 11

   AmeliaBR: I should have edits ready for r/v by then

   Tav: I'm probably half way done with the text algo and should
   have it by Monday
   ... might be Tuesday Australian time

   nikos: We'll need a resolution to publish, which I'll do
   offline on the mailing list
   ... Let me know when you've made your final changes and I'll
   send out an email asking for a resolution to publish
   ... I'll start the publication process (as much as I can) while
   waiting for the resolution

use element changes to be shadow dom compliant

   AmeliaBR: I've been working on this. Making my best choices in
   terms of how to do it
   ... Will submit as a pull request and try to get feedback from
   SVG group and shadow dom experts
   ... Should be done very soon
   ... and we can hopefully merge by this time next week
   ... I'll write up a big description on the pull request of what
   are breaking changes and what is now defined that wasn't before

   nikos: That reminds me
   ... [13]https://github.com/w3c/svgwg/wiki/SVG-2-new-features
   ...
   [14]https://github.com/w3c/svgwg/wiki/SVG-2-breaking-changes
   ... two wiki pages which are very bare bones
   ... but it would be good to document the new features and the
   breaking changes in the spec

     [13] https://github.com/w3c/svgwg/wiki/SVG-2-new-features
     [14] https://github.com/w3c/svgwg/wiki/SVG-2-breaking-changes

   AmeliaBR: I'd like to see something like that in the actual
   spec
   ... The changes appendix is more of a commit log now
   ... It would be nice to have a section that points out where
   things have moved and what has actually changed
   ... As far as the changes appendix goes, it might not be in as
   bad a state as we thought in terms of completeness because
   Cameron updated it everytime he published

Summary of Action Items

Summary of Resolutions

    1. [15]Restore SVGSVGElement.getElementById. Rescind previous
       resolution to deprecate. Spec just as it's specced in DOM -
       returns first descendant element in document order with the
       Id
    2. [16]Rename meshGradient to meshgradient, add a note in the
       spec asking for feedback from authors and implementors as
       to their preference for use and separately their feedback
       on the difficulty of implementing camelcased element names

   [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, 7 July 2016 23:49:45 UTC