20:25:22 RRSAgent has joined #svg 20:25:22 logging to http://www.w3.org/2016/07/07-svg-irc 20:25:24 RRSAgent, make logs public 20:25:26 Zakim, this will be GA_SVGWG 20:25:26 ok, trackbot 20:25:27 Meeting: SVG Working Group Teleconference 20:25:27 Date: 07 July 2016 20:26:58 Chair: Nikos 20:27:14 Agenda: https://lists.w3.org/Archives/Public/www-svg/2016Jul/0003.html 20:28:54 AmeliaBR has joined #svg 20:30:17 present+ nikos 20:31:48 hello 20:32:03 present+ stakagi 20:33:00 present+ AmeliaBR 20:33:10 present+ Tav 20:34:39 scribe: Nikos 20:34:41 scribenick: nikos 20:34:43 Topic: Restore SVGSVGElement.prototype.getElementById 20:34:52 https://github.com/w3c/svgwg/issues/182 20:36:21 nikos: First topic is a request we received about SVGSVGElementById 20:38:29 ... It was planned to be moved onto another interface but jQuery compat caused issues with that 20:38:37 ... signals from implementers are that they are happy to keep it 20:39:06 ... there's nosubtle differences between SVGSVGElement.getElementById and document.getElementById or Element.querySelector 20:39:18 ... so propose adding it back in and not deprecating 20:39:23 ... and speccing exactly as in the DOM spec 20:39:34 ... so returns first descendent element with that id 20:40:02 ... if there's more than element with an id it's technically an error, but we want to define the behaviour just like DOM 20:41:01 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 20:41:14 Topic: Use a single-case name for meshGradient 20:41:29 nikos: We received feedback from Anne as well regarding the name 20:41:44 ... and we said if we got feedback from anyone else and we'd change 20:42:01 Tav: I've looked at the code in WebKit and Blink, and I can't see what they're talking about 20:42:23 ... as far as I can tell it's all handled in one or two functions that take care of SVG casing 20:42:40 ... I do see some fast path stuff for colours in CSS, but there seems to be nothing special done 20:42:50 ... So as far as I can see it's just adding one more line to a file 20:43:00 ... so I don't know what to do next 20:43:24 nikos: did you see my proposal about changing it to meshpaint? 20:43:39 AmeliaBR: I like the argument that a generic name opens us up to future extensions 20:44:58 nikos: It would be fairly simple to add once we have the mesh structure 20:45:01 nikos: http://snapsvg.io/ 20:45:10 ... this style is popular 20:46:46 Tav: That wouldn't be so easy to do with our structure because you have to duplicate corner points 20:47:02 AmeliaBR: I'm not sure how extendable our format is because the path is on the stop element itself 20:47:29 ... so if anything that would be an argument for leaving it specific 20:49:27 nikos: My feeling is that we should change. We have had feedback from two people now. 20:50:20 AmeliaBR: as far as I'm concerned, this was decided when meshrow and meshpatch was made all lower case 20:50:27 ... would be weird to have meshGradient and meshrow 20:50:35 ... I'm happy with gradientmesh or meshgradient 20:51:22 nikos: I was leaning towards gradientmesh initially, but changing the order of words may be a second source of confusion 20:51:26 ... so now I prefer meshgradient 20:51:55 Tav: I would be ok with changing the spec and adding a note asking for comments from implementors on what they prefer 20:52:20 ... I think it will look strange having it all lower case 20:52:24 nikos: Sounds reasonable 20:53:43 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 20:54:00 Topic: Publishing SVG 2 CR 20:54:19 nikos: My intention was to branch and start the publication process on July 11 20:54:28 AmeliaBR: I should have edits ready for r/v by then 20:54:38 Tav: I'm probably half way done with the text algo and should have it by Monday 20:54:56 ... might be Tuesday Australian time 20:55:06 nikos: We'll need a resolution to publish, which I'll do offline on the mailing list 20:57:19 ... Let me know when you've made your final changes and I'll send out an email asking for a resolution to publish 20:57:47 ... I'll start the publication process (as much as I can) while waiting for the resolution 20:58:00 Topic: use element changes to be shadow dom compliant 20:58:19 AmeliaBR: I've been working on this. Making my best choices in terms of how to do it 20:58:37 ... Will submit as a pull request and try to get feedback from SVG group and shadow dom experts 20:58:55 ... Should be done very soon 20:59:08 ... and we can hopefully merge by this time next week 20:59:41 ... 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 21:00:25 nikos: That reminds me 21:00:28 ... https://github.com/w3c/svgwg/wiki/SVG-2-new-features 21:00:33 ... https://github.com/w3c/svgwg/wiki/SVG-2-breaking-changes 21:00:40 ... two wiki pages which are very bare bones 21:00:56 ... but it would be good to document the new features and the breaking changes in the spec 21:01:23 AmeliaBR: I'd like to see something like that in the actual spec 21:01:32 ... The changes appendix is more of a commit log now 21:01:53 ... It would be nice to have a section that points out where things have moved and what has actually changed 21:02:55 ... 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 21:07:25 AmeliaBR has left #svg 21:09:36 RRSAgent, make minutes 21:09:36 I have made the request to generate http://www.w3.org/2016/07/07-svg-minutes.html nikos 23:51:47 s/nosubtle/subtle 23:51:50 RRSAgent, make minutes 23:51:50 I have made the request to generate http://www.w3.org/2016/07/07-svg-minutes.html nikos