<stakagi> hello

<scribe> scribe: Nikos

<scribe> scribenick: nikos

Restore SVGSVGElement.prototype.getElementById

https://github.com/w3c/svgwg/issues/182

nikos: First topic is a request we received about SVGSVGElementById
... It was planned to be moved onto another interface but jQuery compat caused issues with that
... signals from implementers are that they are happy to keep it
... there's subtle differences between SVGSVGElement.getElementById and document.getElementById or Element.querySelector
... so propose adding it back in and not deprecating
... and speccing exactly as in the DOM spec
... so returns first descendent element with that id
... if there's more than element with an id it's technically an error, but we want to define the behaviour just like DOM

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

Use a single-case name for meshGradient

nikos: We received feedback from Anne as well regarding the name
... and we said if we got feedback from anyone else and we'd change

Tav: I've looked at the code in WebKit and Blink, and I can't see what they're talking about
... as far as I can tell it's all handled in one or two functions that take care of SVG casing
... I do see some fast path stuff for colours in CSS, but there seems to be nothing special done
... So as far as I can see it's just adding one more line to a file
... so I don't know what to do next

nikos: did you see my proposal about changing it to meshpaint?

AmeliaBR: I like the argument that a generic name opens us up to future extensions

nikos: It would be fairly simple to add once we have the mesh structure
... http://snapsvg.io/
... this style is popular

Tav: That wouldn't be so easy to do with our structure because you have to duplicate corner points

AmeliaBR: I'm not sure how extendable our format is because the path is on the stop element itself
... so if anything that would be an argument for leaving it specific

nikos: My feeling is that we should change. We have had feedback from two people now.

AmeliaBR: as far as I'm concerned, this was decided when meshrow and meshpatch was made all lower case
... would be weird to have meshGradient and meshrow
... I'm happy with gradientmesh or meshgradient

nikos: I was leaning towards gradientmesh initially, but changing the order of words may be a second source of confusion
... so now I prefer meshgradient

Tav: I would be ok with changing the spec and adding a note asking for comments from implementors on what they prefer
... I think it will look strange having it all lower case

nikos: Sounds reasonable

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

Publishing SVG 2 CR

nikos: My intention was to branch and start the publication process on July 11

AmeliaBR: I should have edits ready for r/v by then

Tav: I'm probably half way done with the text algo and should have it by Monday
... might be Tuesday Australian time

nikos: We'll need a resolution to publish, which I'll do offline on the mailing list
... Let me know when you've made your final changes and I'll send out an email asking for a resolution to publish
... I'll start the publication process (as much as I can) while waiting for the resolution

use element changes to be shadow dom compliant

AmeliaBR: I've been working on this. Making my best choices in terms of how to do it
... Will submit as a pull request and try to get feedback from SVG group and shadow dom experts
... Should be done very soon
... and we can hopefully merge by this time next week
... 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

nikos: That reminds me
... https://github.com/w3c/svgwg/wiki/SVG-2-new-features
... https://github.com/w3c/svgwg/wiki/SVG-2-breaking-changes
... two wiki pages which are very bare bones
... but it would be good to document the new features and the breaking changes in the spec

AmeliaBR: I'd like to see something like that in the actual spec
... The changes appendix is more of a commit log now
... It would be nice to have a section that points out where things have moved and what has actually changed
... 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

This is scribe.perl Revision: 1.144  of Date: 2015/11/17 08:39:34  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Succeeded: s/nosubtle/subtle/
Found Scribe: Nikos
Inferring ScribeNick: nikos
Found ScribeNick: nikos
Present: nikos stakagi AmeliaBR Tav
Agenda: https://lists.w3.org/Archives/Public/www-svg/2016Jul/0003.html
Found Date: 07 Jul 2016
Guessing minutes URL: http://www.w3.org/2016/07/07-svg-minutes.html
People with action items: