Minutes, 22 December 2016 SVG WG telcon

http://www.w3.org/2016/12/22-svg-minutes.html

   [1]W3C

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

                               - DRAFT -

                    SVG Working Group Teleconference

22 Dec 2016

   [2]Agenda

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

   See also: [3]IRC log

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

Attendees

   Present
          nikos, Tav, stakagi, AmeliaBR

   Regrets
   Chair
          Nikos

   Scribe
          nikos

Contents

     * [4]Topics
         1. [5]Testing
         2. [6]Add advice on how to handle className conflict in
            DOM?
         3. [7]What to do with z and w properties of DOMPoint?
         4. [8]Mesh gradient polyfill
         5. [9]New year telcon plans
     * [10]Summary of Action Items
     * [11]Summary of Resolutions
     __________________________________________________________

   <scribe> Scribe: nikos

Testing

   nikos: I have a little to report regards with testing

   [12]http://andronikos.id.au/gecko-test-webkit-results/results.h
   tml

     [12] http://andronikos.id.au/gecko-test-webkit-results/results.html

   scribe: This is the results of some of about 500 of the gecko
   svg reftests
   ... but run on webkit - to see the differences between the
   browsers
   ... the report lists only the failures
   ... about 150 from my set didn't have references - gecko must
   do something with green screen success that doesn't use an
   external file

   Tav: I can see some fail due to aliasing differencs

   nikos: So what I'm wondering is if there's any plan within
   Mozilla to move their reftests into wpt
   ... it would be good to coordinate with them and go in order of
   things that fail in other browsers first
   ... so I'll get in contact with Mozilla and see if that's
   something they're planning
   ... I'd also really like to get Paul Le Beau's tests into our
   repository - I think he 'd have a good set
   ... maybe first telcon of next year we can invite him onto the
   call

Add advice on how to handle className conflict in DOM?

   [13]https://github.com/w3c/svgwg/issues/298

     [13] https://github.com/w3c/svgwg/issues/298

   AmeliaBR: className is the way the class attribute is exposed
   in DOM
   ... this started with HTMLElement - it has a version that
   exposes a simple string
   ... because SVG DOM has all the animVal/baseVal stuff
   ... the SVG className is exposed as an object
   ... so if you try to use JS methods that assume className is a
   simple string you'll have all sorts of problems
   ... this is one of the reasons why there's now a classList
   interface that is recommended for use
   ... we added something in SVG saying don't use className, use
   classList
   ... the issue now is that a lot of features that were only
   defined on HTMLElement are now defined on the core Element
   interface
   ... including className

   <AmeliaBR>
   [14]https://dom.spec.whatwg.org/#dom-element-classname

     [14] https://dom.spec.whatwg.org/#dom-element-classname

   AmeliaBR: so now we have a conflict where Element.className
   exposes a simple string, whereas SVGElement.className exposes
   the animated string object

   nikos: so currently in JS the conflict would be resolved by the
   prototype chain

   AmeliaBR: in a different core language, it may be more
   problematic
   ... that the types don't match

   nikos: So I suppose we should say the JS behaviour is the
   canonical behaviour and anything else should emulate that

   AmeliaBR: currently we say it's deprecated, but don't address
   the conflict
   ... it might be worth adding an informative note that FYI this
   overrides the element one
   ... the longer term goal, as I said, would be to work to create
   a more compatible interface
   ... so you have an attribute that was a string - but keep the
   animVal

   nikos: Yeah so have an SVGAnimatedString mixin that can extend
   DOMString

   AmeliaBR: but that's a bigger change and we really need to get
   people on board in making the change
   ... pretty sure browsers currently expose the SVG 1.1 style
   className
   ... so adding a clarification is not a breaking change for
   anyone
   ... it's just a continued PITA for authors

   nikos: Yeah I think that's the minimum that we should do

   RESOLUTION: SVGElement.className will override
   Element.className

   AmeliaBR: I assume that's how it would work in WebIDL without
   any changes to how it's specced

   <scribe> ACTION: Nikos add clarification for
   SVGElement.className [recorded in
   [15]http://www.w3.org/2016/12/22-svg-minutes.html#action01]

     [15] http://www.w3.org/2016/12/22-svg-minutes.html#action01]

   <trackbot> Created ACTION-3865 - Add clarification for
   svgelement.classname [on Nikos Andronikos - due 2016-12-29].

   <AmeliaBR> [16]https://heycam.github.io/webidl/#idl-overloading

     [16] https://heycam.github.io/webidl/#idl-overloading

What to do with z and w properties of DOMPoint?

   [17]https://github.com/w3c/svgwg/issues/299

     [17] https://github.com/w3c/svgwg/issues/299

   nikos: Think this will be quite simple to resolve

   AmeliaBR: Summary is that SVG has all sorts of methods that
   were originally defined for SVGPoint, which was a 2d x,y point
   ... but we've standardised them to use DOMPoint
   ... DOMPoint can also represent a 3d point with z and w
   ... the question is - do you just ignore z and w?
   ... or do you error, or somehow flatten?
   ... I lean towards ignoring them

   nikos: +1
   ... I think ignoring was the original intention
   ... Should this be clarified in SVG or in DOMMatrix ?

   AmeliaBR: should probably be clarified where methods use
   DOMPoint
   ... which means going through the spec

   RESOLUTION: z and w are ignored on DOMPoint in SVG

   nikos: That action will be up for grabs for anyone who wants it
   - just submit a PR

   <Tav> [18]http://tavmjong.free.fr/SVG/POLYFILL/patch.html

     [18] http://tavmjong.free.fr/SVG/POLYFILL/patch.html

Mesh gradient polyfill

   Tav: See link above - making progress on the mesh gradient
   polyfill
   ... I'm grabbing the canvas as a PNG and using it as an image
   to fill an SVG
   ... I'm part way through parsing the mesh syntax
   ... currently it's just hard coded
   ... then I'll need to replace the mesh gradient with an image
   and clip it
   ... haven't done any attempt at optimisation and it renders
   fast
   ... I'm using ArrayBufferObjects

   nikos: Maybe using SIMD might help where it's supported

   [19]https://jsfiddle.net/dodgeyhack/q9y1at1p/

     [19] https://jsfiddle.net/dodgeyhack/q9y1at1p/

New year telcon plans

   nikos: I'm not sure what the situation will be in the new year
   ... I'm happy to have a telcon first week after New Year if I'm
   able
   ... keep an eye on the mailing list
   ... and Happy holidays!

Summary of Action Items

   [NEW] ACTION: Nikos add clarification for SVGElement.className
   [recorded in
   [20]http://www.w3.org/2016/12/22-svg-minutes.html#action01]

     [20] http://www.w3.org/2016/12/22-svg-minutes.html#action01

Summary of Resolutions

    1. [21]SVGElement.className will override Element.className
    2. [22]z and w are ignored on DOMPoint in SVG

   [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, 22 December 2016 22:54:03 UTC