Re: [svgwg] Revert change from SVGRect/SVGPoint/SVGMatrix to DOM equivalents (#706)

The SVG Working Group just discussed `Revert change from SVGRect/SVGPoint/SVGMatrix to DOM equivalents`.

<details><summary>The full IRC log of that discussion</summary>
&lt;AmeliaBR> Topic: Revert change from SVGRect/SVGPoint/SVGMatrix to DOM equivalents<br>
&lt;myles> GitHub: https://github.com/w3c/svgwg/issues/706<br>
&lt;myles> krit: there are multiple problems. For context, SVG 1.1 had their own geometry information. SVGRect, SVGPoint, SVGMatrix, etc. Then we combined them with CSS objects. There was a CSS Matrix, CSS Rect, etc. This would be DOMPoint, DOMMatrix, etc.<br>
&lt;myles> krit: And replace all the types with the new types.<br>
&lt;myles> krit: Robert from Firefox sees issues with this approach and requests that we change it back to SVG*** from DOM***<br>
&lt;myles> AmeliaBR: The issue is the implementations in Firefox and maybe other implementations, the DOM classes were done in a lightweight way that the individual values within the object are implemented as literal values in the underlying C code, so they can't be used for getters and setters that have side effects, which are necessary if you're going to do attribute reflection<br>
&lt;sairus_> on phone :)<br>
&lt;myles> AmeliaBR: as I understand it, the concern is that if they change that implementation so that attribute reflection would be supported, it would reduce the overall performance of the geometry interfaces in other contexts.<br>
&lt;myles> AmeliaBR: I didn't add this to the agenda expecting a decision. We need to get more feedback from more implementors about looking at what is in your code, what are the blockers for combining the two sets of interfaces, and if there is a decision that nobody has an intention to combine these interfaces, then what's the best way to go forward?<br>
&lt;myles> krit: Or, rephrasing: We have those properties in the SVG DOM, which means that any change that comes from anywhere are reflected everywhere.<br>
&lt;myles> krit: Usually a property that returns an object, it has no bindings to the original value that created the API<br>
&lt;myles> krit: But, instead of a new object, it gives you an object that references the internal value<br>
&lt;myles> krit: that's waht we call "live-ness"<br>
&lt;AmeliaBR> `el.viewBox.baseVal` returns an SVGRect/DOMRect which remains live-linked to the `viewBox` attribute.<br>
&lt;myles> AmeliaBR: The viewbox attribute is reflected as an object. If you change that object, the attribute updates. But, if you change the attribute somewhere else, the object that you're holding a reference to needs to update to. So, internal to the implementation of that object, it needs a poitner back to the element. Instead of storing the values in a permanent way, it needs to have getters and setters that check the current values on the DOM element.<br>
&lt;myles> AmeliaBR: The other use case for these geometry properties as something you can do math with in a way that, you call a method and it returns an object htat has X, Y, width, and heigh tproperties, and you can do transforms on it<br>
&lt;myles> AmeliaBR: And if you do math on it, it doesn't have a conection to the original element.<br>
&lt;myles> AmeliaBR: So, if you make it live, it gets slower<br>
&lt;myles> krit: myles, can you ask shallawa for advice?<br>
&lt;myles> myles: yes<br>
&lt;myles> AmeliaBR: We need feedback from implementors before we can proceed.<br>
&lt;myles> krit: Let's wait for the WebKit investigation<br>
&lt;myles> AmeliaBR: the SVG*** interfaces are the live, previously impelmented interfaces, though they also work in a detached way if you want. The DOM ones where defined to replace the SVG ones but the implementations that went ahead only focused on the detached use cases, and don't support the live use cases.<br>
&lt;myles> krit: All the SVG ones are live.<br>
&lt;myles> SVGAElement implements two conflicting interfaces<br>
</details>


-- 
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/svgwg/issues/706#issuecomment-511553780 using your GitHub account

Received on Monday, 15 July 2019 20:18:33 UTC