Duplicate definitions of SVGPathElement and SVGMarkerElement

[foolip]

SVGPathElement is defined in both the main spec and in SVG Paths:

• https://svgwg.org/svg2-draft/paths.html#InterfaceSVGPathElement
• https://svgwg.org/specs/paths/#InterfaceSVGPathElement

SVGMarkerElement is defined in both the main spec and in SVG Markers:

• https://svgwg.org/svg2-draft/painting.html#InterfaceSVGMarkerElement
• https://svgwg.org/specs/markers/#InterfaceSVGMarkerElement

I'm not sure which is newer, but duplicated IDL definitions makes for trouble for tooling interpreting all of the web platform's IDL, which is how I encountered this issue.

[foolip]

Per #818 it seems like the SVGPathElement in https://svgwg.org/specs/paths/#InterfaceSVGPathElement should be ignored.

@tabatkins do you know about SVGMarkerElement, which definition is the maintained one, and should the other be removed?

[tabatkins]

I'm not sure why these sub-specs exist in the first place, actually. I assume SVG2 is meant to be the canonical source of these things.

As the listed editor, hopefully @heycam can answer whether the Markers spec should be looked to at all, or tombstoned as a dead spec?

[heycam]

The Paths and Markers specs were created to hold features that were added in SVG 2, which didn't currently have enough interest to warrant holding SVG 2 back. The markers features were ones I added, so I kind of like them. :-) But there's no implementation interest in them. If these specs are getting in the way because of their duplicate definitions, we could mark them as dead. (Is that a Bikeshed thing?)

cc @AmeliaBR

[AmeliaBR]

As Cameron said, the specs in https://svgwg.org/specs/ were designed to eventually extend & replace sections of SVG 2 (e.g., they would collectively be SVG Level 3). But they are incomplete drafts, and are not being maintained, so they should be classified only as rough proposals. Some of them are now in conflict with more advanced CSS specs, for example.
The only exception is the SVG animations Level 2 spec, which exists in parallel to SVG 2 as way of maintaining a specification of the SMIL elements, slightly updated from SVG 1.1.

If there's some metadata that can be added that would help with the scraper issues, let us know (ideally via PR, as the SVGWG is currently more of a theoretical entity.) I'm not sure if it's possible to un-publish the ones that were released as working drafts. I suppose we could temporarily overwrite the TR with empty Notes? @svgeesus would know more about options from a publishing/process perspective.

[foolip]

@dontcallmedom @tidoust perhaps the simplest approach here is to move the specs in question to the monitoring list in browser-specs?