IRC log of svg on 2016-12-22
Timestamps are in UTC.
- 20:25:26 [RRSAgent]
- RRSAgent has joined #svg
- 20:25:26 [RRSAgent]
- logging to http://www.w3.org/2016/12/22-svg-irc
- 20:25:28 [trackbot]
- RRSAgent, make logs public
- 20:25:28 [Zakim]
- Zakim has joined #svg
- 20:25:30 [trackbot]
- Zakim, this will be GA_SVGWG
- 20:25:30 [Zakim]
- ok, trackbot
- 20:25:31 [trackbot]
- Meeting: SVG Working Group Teleconference
- 20:25:31 [trackbot]
- Date: 22 December 2016
- 20:26:21 [stakagi]
- stakagi has joined #svg
- 20:27:36 [nikos]
- chair: Nikos
- 20:28:09 [nikos]
- Agenda: https://lists.w3.org/Archives/Public/www-svg/2016Dec/0011.html
- 20:28:17 [nikos]
- Scribe: nikos
- 20:28:20 [nikos]
- present+ nikos
- 20:32:01 [Tav]
- present+ Tav
- 20:33:47 [stakagi]
- present+ stakagi
- 20:33:51 [nikos]
- present+ AmeliaBR
- 20:38:04 [nikos]
- Topic: Testing
- 20:38:15 [nikos]
- nikos: I have a little to report regards with testing
- 20:38:16 [nikos]
- http://andronikos.id.au/gecko-test-webkit-results/results.html
- 20:38:37 [nikos]
- ... This is the results of some of about 500 of the gecko svg reftests
- 20:39:13 [nikos]
- ... but run on webkit - to see the differences between the browsers
- 20:39:21 [nikos]
- ... the report lists only the failures
- 20:40:13 [nikos]
- ... about 150 from my set didn't have references - gecko must do something with green screen success that doesn't use an external file
- 20:40:48 [nikos]
- Tav: I can see some fail due to aliasing differencs
- 20:41:40 [nikos]
- nikos: So what I'm wondering is if there's any plan within Mozilla to move their reftests into wpt
- 20:42:13 [nikos]
- ... it would be good to coordinate with them and go in order of things that fail in other browsers first
- 20:45:03 [nikos]
- ... so I'll get in contact with Mozilla and see if that's something they're planning
- 20:45:27 [nikos]
- ... I'd also really like to get Paul Le Beau's tests into our repository - I think he 'd have a good set
- 20:45:35 [nikos]
- ... maybe first telcon of next year we can invite him onto the call
- 20:46:09 [nikos]
- Topic: Add advice on how to handle className conflict in DOM?
- 20:46:21 [nikos]
- https://github.com/w3c/svgwg/issues/298
- 20:46:51 [nikos]
- AmeliaBR: className is the way the class attribute is exposed in DOM
- 20:47:04 [nikos]
- ... this started with HTMLElement - it has a version that exposes a simple string
- 20:47:13 [nikos]
- ... because SVG DOM has all the animVal/baseVal stuff
- 20:47:20 [nikos]
- ... the SVG className is exposed as an object
- 20:47:37 [nikos]
- ... so if you try to use JS methods that assume className is a simple string you'll have all sorts of problems
- 20:47:51 [nikos]
- ... this is one of the reasons why there's now a classList interface that is recommended for use
- 20:48:01 [nikos]
- ... we added something in SVG saying don't use className, use classList
- 20:48:20 [nikos]
- ... the issue now is that a lot of features that were only defined on HTMLElement are now defined on the core Element interface
- 20:48:23 [nikos]
- ... including className
- 20:48:45 [AmeliaBR]
- https://dom.spec.whatwg.org/#dom-element-classname
- 20:48:56 [nikos]
- ... so now we have a conflict where Element.className exposes a simple string, whereas SVGElement.className exposes the animated string object
- 20:49:16 [nikos]
- nikos: so currently in JS the conflict would be resolved by the prototype chain
- 20:49:29 [nikos]
- AmeliaBR: in a different core language, it may be more problematic
- 20:49:34 [nikos]
- ... that the types don't match
- 20:50:06 [nikos]
- nikos: So I suppose we should say the JS behaviour is the canonical behaviour and anything else should emulate that
- 20:50:17 [nikos]
- AmeliaBR: currently we say it's deprecated, but don't address the conflict
- 20:50:57 [nikos]
- ... it might be worth adding an informative note that FYI this overrides the element one
- 20:51:14 [nikos]
- ... the longer term goal, as I said, would be to work to create a more compatible interface
- 20:51:32 [nikos]
- ... so you have an attribute that was a string - but keep the animVal
- 20:51:50 [nikos]
- nikos: Yeah so have an SVGAnimatedString mixin that can extend DOMString
- 20:52:04 [nikos]
- AmeliaBR: but that's a bigger change and we really need to get people on board in making the change
- 20:52:13 [nikos]
- ... pretty sure browsers currently expose the SVG 1.1 style className
- 20:52:24 [nikos]
- ... so adding a clarification is not a breaking change for anyone
- 20:52:31 [nikos]
- ... it's just a continued PITA for authors
- 20:52:38 [nikos]
- nikos: Yeah I think that's the minimum that we should do
- 20:53:21 [nikos]
- RESOLUTION: SVGElement.className will override Element.className
- 20:53:32 [nikos]
- AmeliaBR: I assume that's how it would work in WebIDL without any changes to how it's specced
- 20:53:51 [nikos]
- ACTION: Nikos add clarification for SVGElement.className
- 20:53:52 [trackbot]
- Created ACTION-3865 - Add clarification for svgelement.classname [on Nikos Andronikos - due 2016-12-29].
- 20:54:00 [AmeliaBR]
- https://heycam.github.io/webidl/#idl-overloading
- 20:54:40 [nikos]
- Topic: What to do with z and w properties of DOMPoint?
- 20:54:47 [nikos]
- https://github.com/w3c/svgwg/issues/299
- 20:55:00 [nikos]
- nikos: Think this will be quite simple to resolve
- 20:55:16 [nikos]
- AmeliaBR: Summary is that SVG has all sorts of methods that were originally defined for SVGPoint, which was a 2d x,y point
- 20:55:22 [nikos]
- ... but we've standardised them to use DOMPoint
- 20:55:29 [nikos]
- ... DOMPoint can also represent a 3d point with z and w
- 20:55:40 [nikos]
- ... the question is - do you just ignore z and w?
- 20:55:52 [nikos]
- ... or do you error, or somehow flatten?
- 20:55:57 [nikos]
- ... I lean towards ignoring them
- 20:56:01 [nikos]
- nikos: +1
- 20:56:11 [nikos]
- ... I think ignoring was the original intention
- 20:56:34 [nikos]
- nikos: Should this be clarified in SVG or in DOMMatrix ?
- 20:56:46 [nikos]
- AmeliaBR: should probably be clarified where methods use DOMPoint
- 20:56:59 [nikos]
- ... which means going through the spec
- 20:58:44 [nikos]
- RESOLUTION: z and w are ignored on DOMPoint in SVG
- 20:59:03 [nikos]
- nikos: That action will be up for grabs for anyone who wants it - just submit a PR
- 20:59:30 [Tav]
- http://tavmjong.free.fr/SVG/POLYFILL/patch.html
- 20:59:38 [nikos]
- Topic: Mesh gradient polyfill
- 20:59:46 [nikos]
- Tav: See link above - making progress on the mesh gradient polyfill
- 21:00:12 [nikos]
- ... I'm grabbing the canvas as a PNG and using it as an image to fill an SVG
- 21:00:18 [nikos]
- ... I'm part way through parsing the mesh syntax
- 21:00:29 [nikos]
- ... currently it's just hard coded
- 21:00:47 [nikos]
- ... then I'll need to replace the mesh gradient with an image and clip it
- 21:01:05 [nikos]
- ... haven't done any attempt at optimisation and it renders fast
- 21:02:18 [nikos]
- Tav: I'm using ArrayBufferObjects
- 21:03:01 [nikos]
- nikos: Maybe using SIMD might help where it's supported
- 21:04:12 [nikos]
- https://jsfiddle.net/dodgeyhack/q9y1at1p/
- 21:05:51 [nikos]
- Topic: New year telcon plans
- 21:06:02 [nikos]
- nikos: I'm not sure what the situation will be in the new year
- 21:06:15 [nikos]
- ... I'm happy to have a telcon first week after New Year if I'm able
- 21:06:49 [nikos]
- ... keep an eye on the mailing list
- 21:06:55 [nikos]
- ... and Happy holidays!
- 21:07:02 [nikos]
- RRSAgent, make minutes
- 21:07:02 [RRSAgent]
- I have made the request to generate http://www.w3.org/2016/12/22-svg-minutes.html nikos