Missing type SVGTransformable

[streamcode9]

TypeScript Version:
2.3.4 and later

Search Terms:
SVGTransformable missing type

Code

const someFun = (node: SVGTransformable) => { }

Expected behavior:
Success compilation.

Actual behavior:
Error TS2304: Cannot find name 'SVGTransformable'.

Playground Link:
Link

Comments:
Version 1.8.7 has SVGTransformable type.

[mhegazy]

PRs welcomed. You can find more information about contributing lib.d.ts fixes at https://github.com/Microsoft/TypeScript/blob/master/CONTRIBUTING.md#contributing-libdts-fixes.

[a-tarasyuk]

@mhegazy

Moved members from 'SVGLocatable' and 'SVGTransformable' to 'SVGGraphicsElement' and removed those interfaces

SVG-2-new-features

SVGTransformable and SVGLocatable are part of previous spec 1.1. Should we support these two outdated interfaces?

[mhegazy]

Should we support these two outdated interfaces?

no we should not. thanks for verifying. closing.

[nponeccop]

The SVGTransformable interface is present in both SVG 1.0 IDL and SVG1.1 IDL and it contains a single .transform() method.

The current Typescript's lib.d.ts puts .transform() to SVGGraphicsElement interface which is what SVG2 does.

SVG2 is not supported by anyone, so there is a little inconvenience: you have to work with the features of SVG 1.x but with types from the SVG 2 specification.

Here are a few considerations:

• The latest SVG recommendation is SVG 1.1. SVG 2 is not a recommendation yet but a candidate recommendation, which means pre-release status.
• The process of SVG2 standardization has stalled since 2016 which means SVG2 may never be released. The latest version on the W3C site is from 2016. There is also a more recent version from 2018 on a separate site of the SVG Working Group. But it's still an editor draft.
• Because of the reasons above, the Edge team chose not to implement SVG2 at all. Current support by other browsers, as viewed by the Edge team, is still fragmentary ("in development").

So basically SVG 2 is not the way to go because it's dead (or not born yet).

So the real question of this issue is whether TypeScript should choose SVG 1.0 or SVG 1.1 or both.

SVG 1.1. is merely a modularization of SVG 1.0. It means the same features but more logical interfaces/types. And it also means that SVG 1.0 types are incompatible with those of 1.1. However, it may be possible to support both with the Typescript type system and/or with different .d.ts files for different versions.

I think that a further modularization of dom.ts so a user can choose different versions of SVG DOM could be a feasible approach.