[svgwg] Issue: setMatrix takes DOMMatrix2DInit, which makes its is2D() branch unreachable (#1155) marked as Agenda+

karlcow has just labeled an issue for https://github.com/w3c/svgwg as "Agenda+":

== setMatrix takes DOMMatrix2DInit, which makes its is2D() branch unreachable ==
Splitting this out of #326, where @zcorpan asked it on 2020-11-06 and never got an answer:

> Why was this specced to use `DOMMatrix2DInit` and not `DOMMatrixInit` (as suggested in OP)?
>
> The steps that check "is2D()" is a no-op as specced, I believe, since there won't be any members in the dictionary that can cause it to return false.

He is right, and the dead prose is still in the spec today.

### The unreachable branch

`SVGTransform.setMatrix` is declared as

    undefined setMatrix(optional DOMMatrix2DInit matrix = {});

and its algorithm in coords.html reads:

> 2. Let *newMatrix* be the result of `DOMMatrixReadOnly.fromMatrix(matrix)`, including the validate and fix-up steps for missing values. …
> 3. If *newMatrix*.is2D() would return true, then set the SVGTransform object's value to a `matrix(…)` value that represents the same matrix as *newMatrix*.
> 4. **Otherwise, set the SVGTransform object's value to a `matrix3d(…)` value that represents the same matrix as *newMatrix*.**

`DOMMatrix2DInit` has no `is2D` member and no m13/m14/m23/m24/m31/m32/m33/m34/m43/m44 members, so nothing a caller can pass makes `is2D()` false. Step 4 is unreachable. `SVGTransformList.createSVGTransformFromMatrix` and `SVGSVGElement.createSVGTransformFromMatrix` both delegate to these steps, so they inherit it.

Either the dictionary should be `DOMMatrixInit` (the OP's original request, and what makes step 4 meaningful), or it should stay `DOMMatrix2DInit` and step 4 should be deleted. The 2018-11-12 resolution recorded the choice:

> RESOLVED: Replace DOMPoint with DOMPoint2DInit with SetMatrix() and createSVGTransformFromMatrix()

but not the reasoning, and the minutes show the discussion was about copy-vs-reference semantics rather than 2D-vs-3D.

### It is also causing an interop split, on a different method

`SVGPoint.matrixTransform` is specified with the **3D** dictionary (`optional DOMMatrixInit matrix = {}` in the Geometry IDL, since `SVGPoint` is a `LegacyWindowAlias` of `DOMPoint`). Implementations disagree about all of it:

| engine | signature |
|---|---|
| spec / wpt `interfaces/geometry.idl` | `optional DOMMatrixInit matrix = {}` |
| Gecko | `optional DOMMatrix2DInit matrix = {}` (dom/webidl/SVGPoint.webidl:23) |
| Blink | `SVGMatrix matrix` (core/svg/svg_point.idl:32) |
| WebKit | `SVGMatrix matrix` (Source/WebCore/svg/SVGPoint.idl:32) |

So one engine picked the 2D dictionary where the spec says 3D, and two have not widened at all. Before WebKit widens it, which I would like to do, it would help to know whether SVG intends 2D or 3D for matrix dictionary input generally, rather than having each method resolved separately years apart.

### What I think needs deciding

1. Is `DOMMatrix2DInit` the intended input type for `setMatrix` and both `createSVGTransformFromMatrix` methods, or was `DOMMatrixInit` meant?
2. If 2D is intended, delete the unreachable `matrix3d(…)` step.
3. Does the same answer apply to `SVGPoint.matrixTransform`, which the Geometry IDL currently specifies as 3D?

I have no strong preference between 2D and 3D. Consistency across the four methods, and prose without a dead branch in it, are what I am after.

See https://github.com/w3c/svgwg/issues/1155


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Wednesday, 29 July 2026 10:06:59 UTC