See also: IRC log
<scribe> Scribe: nikos
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
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
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
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/
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[End of scribe.perl diagnostic output]