Sort out SVG's mixin-like interfaces

[foolip]

SVG 1.1 defined some interfaces which were a lot like mixins, with wording like this:

Interface SVGTests defines an interface which applies to all elements which have attributes ‘requiredFeatures’, ‘requiredExtensions’ and ‘systemLanguage’.

or:

Interface SVGTransformable contains properties and methods that apply to all elements which have attribute ‘transform’.

However, these predated Web IDL mixins, and some of them were implemented in a way which exposed the interface object for them.

A number of interfaces like this are in BCD/MDN:

• https://developer.mozilla.org/en-US/docs/Web/API/SVGAnimatedPoints
• https://developer.mozilla.org/en-US/docs/Web/API/SVGExternalResourcesRequired
• https://developer.mozilla.org/en-US/docs/Web/API/SVGFilterPrimitiveStandardAttributes
• https://developer.mozilla.org/en-US/docs/Web/API/SVGStylable
• https://developer.mozilla.org/en-US/docs/Web/API/SVGTests
• https://developer.mozilla.org/en-US/docs/Web/API/SVGTransformable
• https://developer.mozilla.org/en-US/docs/Web/API/SVGURIReference

This list might not be complete.

We should probably delete all of these pages and their BCD entries, but in the process we should also make sure that the members are instead of the other correct interfaces.

Note that https://developer.mozilla.org/en-US/docs/Web/API/SVGUnitTypes is not to be removed, because https://svgwg.org/svg2-draft/types.html#InterfaceSVGUnitTypes defines it as a plain interface, because there are constants on it that are accessed through the interface object.

[foolip]

I noticed this while reviewing @vinyldarkscratch's PRs, and only after a merged a few PRs making changes to these entries: #7716 + #7720 + #7733

There are additional open PRs with this issue, and I'll link those to this issue instead of merging them.

[foolip]

https://developer.mozilla.org/en-US/docs/Web/API/SVGZoomAndPan is also not in this category, since it also has constants on it.

[foolip]

Oops, #7718 is another case already merged.

[ddbeck]

some of them were implemented in a way which exposed the interface object for them

Can we get an example of a case like this (documented on MDN or not)? I want to get a sense of what this looks like in an actual browser. My inclination is this: if it's a concrete interface that's actually exposed to web developers, then we should track it (even if that interface, alone, isn't particularly useful). If it's a fiction for specification authors, then we shouldn't.

[ddbeck]

Also noting here that thanks to the demixing work in #8929 the following interfaces are hopefully going to get dealt with:

• SVGAnimatedPoints
• SVGFilterPrimitiveStandardAttributes
• SVGTests
• SVGURIReference

[foolip]

some of them were implemented in a way which exposed the interface object for them

Can we get an example of a case like this (documented on MDN or not)? I want to get a sense of what this looks like in an actual browser. My inclination is this: if it's a concrete interface that's actually exposed to web developers, then we should track it (even if that interface, alone, isn't particularly useful). If it's a fiction for specification authors, then we shouldn't.

I've taken another look at what interfaces are exposed in current Chrome, Firefox and Safari, and nothing which is a mixin in the SVG spec has an exposed interface in any browser. So I think things are actually fine here, if we just demix mixins this should be resolved.

[foolip]

Closing this in favor of #8929 which tracks what remains.