<scribe> Scribe: nikos

Testing

nikos: I have a little to report regards with testing

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?

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> 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 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> https://heycam.github.io/webidl/#idl-overloading

What to do with z and w properties of DOMPoint?

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

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!

This is scribe.perl Revision: 1.148  of Date: 2016/10/11 12:55:14  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Found Scribe: nikos
Inferring ScribeNick: nikos
Present: nikos Tav stakagi AmeliaBR
Agenda: https://lists.w3.org/Archives/Public/www-svg/2016Dec/0011.html
Found Date: 22 Dec 2016
Guessing minutes URL: http://www.w3.org/2016/12/22-svg-minutes.html
People with action items: nikos