- From: Amelia Bellamy-Royds via GitHub <sysbot+gh@w3.org>
- Date: Sat, 22 Jun 2019 01:18:41 +0000
- To: public-svg-issues@w3.org
Ok, so let's get back to your proposal: How would SVGPoint/DOMPoint and SVGRect/DOMRect be related? The SVG* classes would be wrappers for an internal DOM* geometry type, exposing the internal object's components using getters/setters that also have the side effects necessary for attribute reflection? That seems do-able, if not ideal. How much are these objects used currently in built-in APIs other than SVG? We'd need to go through all the relevant methods to see which should be accepting or returning which type. I think their use as parameters, at least, are already covered by the *Init type definitions. We might also want to make a note that the SVGSVGElement's `.createSVGPoint()`, etc., methods are deprecated (because the extra overhead of the getter/setter etc. would not have any value for a detached geometry object that isn't associated with a reflected attribute). Instead, we could recommend that the DOM* methods and their constructors be used for calculations in author scripts. -------------------- I'd love to get some feedback from other implementers about how the different options compare in your codebases! -- GitHub Notification of comment by AmeliaBR Please view or discuss this issue at https://github.com/w3c/svgwg/issues/706#issuecomment-504614791 using your GitHub account
Received on Saturday, 22 June 2019 01:18:42 UTC