Revert change from SVGRect/SVGPoint/SVGMatrix to DOM equivalents

https://www.w3.org/TR/SVG2/types.html#SVGDOMOverview

SVG 1.1. had types SVGRect, SVGPoint and SVGMatrix.
In SVG2 these have been replaced by DOMRect, DOMPoint and DOMMatrix (or in some cases DOMRectReadOnly or DOMRectInit etc)

Unfortunately I don't think this is going to work. viewBox.animVal and viewBox.baseVal are live, if you change them the viewBox attribute changes. That means you need to have something derived from DOMRect/DOMRectReadOnly to model that and have DOMRect and DOMRectReadOnly methods be virtual.

The same is true of various DOMPoint, DOMMatrix things in the SVG2 spec too.

No browser has dropped SVGPoint etc and I suspect the above is the reason why. I don't think I can make the change in Firefox for instance because of performance concerns over having virtual functions.

So I'd like to propose that the specification reverts to SVGPoint, SVGMatrix and SVGRect except for inputs to methods (e.g. IsPointInFill), which can stay as DOMPointInit, DOMMatrixInit and DOMPointInit because those dictionaries merely want something with the appropriate properties so they will take an SVGPoint, SVGMatrix or SVGRect.

Note that some methods still don't take Init input argument e.g. getEnclosureList but perhaps I should raise that as a separate issue.

To clarify:

You're saying that SVGPoint, etc, should be reintroduced, but as subclasses of DOMPoint, etc. The subclass wouldn't have any extra author-exposed functionality, but would have an internal slot that represented the association to an element/attribute, so they can be live reflections of the attribute?

No SVGPoint should be reintroduced exactly as it was in SVG 1.1 i.e not a subclass of DOMPoint.

I guess I don't understand, then: What is the obstacle to extending DOMPoint, etc, to make it reflect an attribute value? Is it just a performance issue, that you currently have the components (x, y, etc.) implemented as simple attributes of the object, so you don't want to turn them into getters/setters?

The whole purpose of the DOM* geometry classes was to replace the matching SVG* classes, but make them usable more broadly. It's disappointing if they were implemented in a way that doesn't make that possible. I really don't like the idea of maintaining parallel but independent sets of geometry classes.

https://dxr.mozilla.org/mozilla-central/source/dom/base/DOMPoint.h

In Firefox's implementation DOMPoint is final and none of the methods in either DOMPoint or DOMPointReadOnly are virtual. Making them virtual would adversely affect html perf and is therefore a problem. Same for DOMRect/DOMRectReadOnly

DOMPoint/DOMRect are clearly not things that are designed to be live. They are fine for the result of GetBBox but not for viewBox.baseVal or viewBox.animVal.

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!

SVGPoint and DOMPoint would not be related. Neither would SVGRect and DOMRect. Their attributes would share common naming so that they could both be passed to things that take DOMPointInit or DOMRectInit. Same with SVGMatrix/DOMMatrix.

If we have everything taking DOMPointInit, DOMRectInit etc then we don't need createSVGPoint or createSVGRect.

I can acknowledge that this transition has not gone as smooth as some may have hoped. I wouldn't want to acknowledge the specific problem statement however - I'd fully expect this transition to involve additions of state to DOMPoint and similar ("read only" and "associated" for example).
Comparing options here leaves us in the old (potentially unfair) comparison of "no work" (status quo) and "non-trivial (albeit not difficult) work".

@fsoder

@fsoder agreed.

@longsonr SVGPoint and SVGRect are aliases fro DOMPoint and DOMRect according to the Geometry Interfaces spec. So replacing the former with the latter (or DOM*Init in some cases) were more or less a formality. Changing them back wouldn't make a difference.

While baseVal and animVal certainly are in use, the use counter is very likely very low. Is there anything we could do in SVG2 or Geometry Interfaces to reduce the burden that you see? I thin I remember that Firefox already did backwards-incompatible changes to animVal because low usage numbers allowed it. Could you clarify that?

I mean change them back to SVG 1.1 where they are unrelated to DOMPoint and DOMRect.

We've not made any backwards-incompatible changes to animVal.

We have other liveness problems with DOM types

currentTranslate as a DOMPoint
SVGAnimatedPoints (e.g. SVGPolylineElement) having SVGPoints
DOMMatrix in transforms

@longsonr

@longsonr I understood the request but

It requires the actual change to be done in Geometry Interfaces first since that spec defines SVG* interfaces as aliases to the corresponding DOM* interfaces.
I actually think it is a step backwards. We wanted to unify the web world with Geometry Interfaces and pull out SVG of its silo isolated from the rest of the web world. We got strong support from web developers for that change.

So before we discuss undoing the changes I'd rather like to hear proposals what we can do to make the transition less painful.

I'd also like to hear more feedback & proposals from other implementation teams.

If no one has plans to update their implementations to replace usage of SVGMatrix, etc. with DOMMatrix, then we really should be changing the spec to match reality.

For reference, here are the tracking bugs for making the SVG* interfaces aliases to the DOM* equivalents:

Chromium 709001
Mozilla 1563444 (tracking bug), and 1439685 about SVGRect in particular but with lots of discussion of implementation issues
WebKit: SVGMatrix, SVGRect, SVGPoint

If the final conclusion is that browsers do not want to update the DOM geometry interfaces to support attribute reflection, then we need to go through the full SVG IDL and identify which uses of the geometry interfaces need a version with attribute reflection and which can still be replaced by the DOM equivalent. E.g., the value returned by getCTM() will never be associated with an attribute, so it could return a DOMMatrix without any changes to the DOMMatrix definitions.

I'd also like any suggestions about how we could make the difference between a DOM* geometry interface and its SVG equivalent as transparent as possible to authors.

I think SVGPolylineElement and SVGPolygonElement have weird and inconsistent interfaces compared to the rest of the SVG elements. These two elements have the baseVal and animVal of the points flattened to two members points and animatedPoints. But SVGTextPositioningElement, for example, has a different interface. It has its members represented as SVGAnimatedLengthList

interface SVGTextPositioningElement : SVGTextContentElement {
    readonly attribute SVGAnimatedLengthList x;
    ... 
};

It does not have x and animatedX of type SVGLengthList. It just has x of type SVGAnimatedLengthList.

So to access the baseVal or animVal SVGLengthList of a text element, you would say text.x.baseVal or text.x.animVal.

It would have made things much simpler and clearer if SVGPolylineElement was defined like this:

interface SVGPolylineElement : SVGGeometryElement {
    readonly attribute SVGAnimatedPointList points;
};

And instead of accessing the current points and animatedPoints we would have accessed points.baseVal and points.animVal

So removing animatedPoints or making it an alias to points will prevent any access to the animVal of the underlying SVGAnimatedPointList. I would suggest removing https://wpt.live/svg/shapes/animatedPoints-non-animated.html

Also this change https://svgwg.org/svg2-draft/shapes.html#InterfaceSVGAnimatedPoints in SVG2 does not make sense to me. If the points attribute of the <ployline> is animatable https://svgwg.org/svg2-draft/shapes.html#PolylineElement, why do not we provide access to its animated value like what we do with other elements?

I am referring to this change:

Note: In SVG 1.1 SE, the animatedPoints attribute represented the current animated value. In this version of SVG, it is simply an alias for points.

@shallawa

Please create your own issue @shallawa rather than trying to join it to this one as it's unrelated. Note that your proposal is not backwards compatible though.

Fix w3c#706 - Revert SVGRect/SVGPoint/SVGMatrix

@sideshowbarker

@sideshowbarker ok created a PR.
If I did anything wrong, just ping me and I will fix it. If there are things I have missed I'm happy to fix them.

Please create your own issue @shallawa rather than trying to join it to this one as it's unrelated.

#990

Note that your proposal is not backwards compatible though.

Please add this comment to the new issue.

Remove WPT svg/shapes/animatedPoints-non-animated.html

Fix w3c#706 - Revert SVGRect/SVGPoint/SVGMatrix

Bug 1697573 [wpt PR 27999] - Update tests to reflect resolution in sv…

I applied to the current spec, the decisions from the SVG WG
in #706 (comment)

This is currently a PR. It needs a review.
#1143

but there was something which was left in the air, maybe we need a separate issue.
Or if someone remembers a previous discussions could you share the link.

RESOLVED: Ask CSS WG to approve separating out most of the geometry interfaces into mixins we can reference in SVG interface definitions.

I'm not sure anyone ever ask the question to the CSS WG.

Revert SVG*→DOM* geometry-interface aliasing (#706)

Navigation Menu

Repository navigation

Revert change from SVGRect/SVGPoint/SVGMatrix to DOM equivalents #706

31 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Revert change from SVGRect/SVGPoint/SVGMatrix to DOM equivalents #706

Description

Activity

AmeliaBR commented on Jun 21, 2019

longsonr commented on Jun 22, 2019

AmeliaBR commented on Jun 22, 2019

longsonr commented on Jun 22, 2019

AmeliaBR commented on Jun 22, 2019

longsonr commented on Jun 22, 2019

fsoder commented on Jun 23, 2019

dirkschulze commented on Jun 28, 2019

longsonr commented on Jun 28, 2019

dirkschulze commented on Jun 28, 2019

AmeliaBR commented on Jul 6, 2019

31 remaining items

shallawa commented on Jun 18, 2025

shallawa commented on Jun 18, 2025

shallawa commented on Jun 18, 2025

shallawa commented on Jun 18, 2025

longsonr commented on Jun 19, 2025

karlcow commented on Jul 2, 2025

shallawa commented on Jul 28, 2025

karlcow commented on Jun 29, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions