In Gecko code, they do not implement SVGTests either.  

"...remove requiredExtensions and systemLanguage..."

Stop (C++-)inheriting from SVGTests you mean?

I mean in the idl definition. 

I'm sorry, but then your statement makes little sense to (in the context of this bug.)

Please elaborate.

I am looking at the idl spec for the 3 interfaces, none described that SVGMaskElement or SVGPatternElement should implement SVGTests. But in Blink, that's what we are doing, 
https://cs.chromium.org/chromium/src/third_party/WebKit/Source/core/svg/SVGMaskElement.idl?rcl=b437e9336734feedcf529fac96cb21e7fa031a9a&l=40
https://cs.chromium.org/chromium/src/third_party/WebKit/Source/core/svg/SVGPatternElement.idl?rcl=b437e9336734feedcf529fac96cb21e7fa031a9a&l=44

Although in https://www.w3.org/TR/SVG11/pservers.html#InterfaceSVGPatternElement
it did say that SVGPatternElement inherits SVGTests.

What does "remove requiredExtensions and systemLanguage" have to do with removing "... implements SVGTests" for the two interfaces mentioned?
Removing the "implements" statement would automatically stop exposing those properties.
If you want to remove the SVGTests mix-in that should go in a different bug.

Well, requiredExtensions and systemLanguage are APIs in SVGTests according to the spec. So if the other two interfaces no longer implement SVGTests, they should not contain those two API's any more. 

Removing the "implements" takes care of that though, so spelling that removal out is more confusing than not. Regardless, removing that "implements" has effects on the internals. Presumably these elements should no longer allow conditionals, meaning the SVGTests mix-in could be removed. If that is not the case, we'd instead have unused data.

I guess the source of confusion is "I think we should remove those lines and remove requiredExtensions and systemLanguage too?"

Removing the implements statements from the IDL files should be enough to fix the spec misalignment, whether or not there is internal inheritance doesn't matter for that. But it would be suspicious if SVGMaskElement or SVGPatternElement uses requiredFeatures, requiredExtensions or systemLanguage internally, that could indicate that the IDL changes are part of a large change.

Sometimes the IDL file is really just the tip of the iceberg =)

Anyway, this is what the spec say:

https://svgwg.org/svg2-draft/struct.html#ConditionalProcessingOverview (third bullet: "conditional processing will have no effect on never-rendered elements")

and I managed to dig up this thread which is related:

https://lists.w3.org/Archives/Public/www-svg/2012Dec/0097.html 

Hmm, so per that it seems like there shouldn't be any internal usage of SVGTests bits in SVGMaskElement or SVGPatternElement, and if there is that's cause for alarm?

Right, "shouldn't be" would right level of uncertainty =). It is used though as it is today. Here's an example of how this is observable without the DOM interface: https://jsfiddle.net/b0x0mpff/ (shows blue in Blink, and blue with a yellow cross in Gecko; Edge renders blank [which is odd, they do seem to implement SVGTests though, so maybe they just don't use the fallback in this case...])

That is amusing. I suppose one would find all cases like this by internally removing the inheritance from SVGTests and seeing what happens.

Next concrete for this issue is probably just that, to attempt this removal completely in a CL and see what tests are broken by it. If it seems fine, then send an Intent to Remove.

If SVGMaskElement or SVGPatternElement really isn't using the SVGTests part internally. I can try to remove the "implements" lines and the inherited APIs to see what a difference it will make. If it is safe, we should just remove them to match the spec?

As things stand, they are using SVGTests internally (the test above aimed to show that, although what the expected outcomes were was left as an exercise to the reader [1]. If we could do a "complete removal" (align ith SVG2 and Gecko) that'd be preferable IMHO. (There are better ways in which this conditional could be implemented, so this is not a reduction in expressive power.)

[1] Plain blue (or transparent?) means the conditional ("test") was applied, unless your system language is 'sv' because then you'll get the yellow cross too. You'll also get the latter if the conditional wasn't applied (like in Gecko.)

This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue.

Sorry for the inconvenience if the bug really should have been left as Available.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Still planning to try removing SVGTests, I think.