Intent to Deprecate: DOMImplementation.hasFeature() returning false

[Philip Jägenstedt]

Primary eng (and PM) emails

phi...@opera.com

Summary

Deprecate any call to DOMImplementation.hasFeature() that returns false.

Motivation

hasFeature() is an antiquated form of feature detection. By my own request, the spec was changed to make it always return true:

https://dom.spec.whatwg.org/#dom-domimplementation-hasfeature

http://lists.w3.org/Archives/Public/www-dom/2014JanMar/0157.html

https://www.w3.org/Bugs/Public/show_bug.cgi?id=25428

The alternative path to get the spec and implementations to agree is to figure out the exact inputs for which hasFeature() should return false, and that doesn't seem like fun. As an example, Gecko and Blink do not agree about `document.implementation.hasFeature("org.w3c.svg", "1.0")`.

Compatibility Risk

The only case where hasFeature() returns false is for SVG features. Thus there may be some SVG apps that use this for feature detection, which would stop working partially or fully.

Alternative implementation suggestion for web developers

Use modern feature detection for whichever feature you're interested in.

Usage information from UseCounter

https://www.chromestatus.com/metrics/feature/timeline/popularity/231

It's been stable around 0.004% for a long time now. Early on it was around 0.07%, but for unknown reasons it soon dropped to current levels. Discussed in https://groups.google.com/a/chromium.org/d/msg/blink-dev/yCUjWJAUd9g/89KL8HjApecJ

Entry on chromestatus.com, crbug.com, or MDN

https://developer.mozilla.org/en-US/docs/Web/API/DOMImplementation.hasFeature

Requesting approval to remove too?

No. Since the feature was once standard, deprecation for several release cycles seems reasonable.

[Philip Rogers]

LGTM. This was a misfeature.

[Chris Harrelson]

LGTM

I found a few obscure cases in some old Google code, but they don't appear to be checking for SVG anyway.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

[Erik Dahlstrom]

lgtm.

Note that this also affects the SVG <switch> element (or really, all svg elements that use the requiredFeatures attribute) since these hook into DOMImplementation.hasFeature.

Also see https://www.chromestatus.com/metrics/feature/popularity#SVGSwitchElement.

It may lead to rendering issues, but hopefully will not.

/ed

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

--

Erik Dahlstrom, Web Technology Developer, Opera Software
Co-Chair, W3C SVG Working Group

[PhistucK]

Does the use counter count such usage (SVG attributes)?

☆PhistucK

[Erik Dahlstrom]

No, the SVGSwitchElement counter only looks for the existence of <switch> elements.

[PhistucK]

I meant the other way around - does the hasFeature use counter count requiredFeature="..."?

☆PhistucK

[Philip Jägenstedt]

No, it measures only the DOM API. The intent is for that only, but I could add a new counter for <switch>.

[PhistucK]

But Erik seems to imply that both of them use the same underlying code, does it actually break both of them, while the intent only mentions the DOM API?

☆PhistucK

[Erik Dahlstrom]

What I meant was: please make sure that DOMImplementation.hasFeature and the internal usage of that method in the svg code (see SVGTests::isValid) gets the exact same results.

Returning true for all the featurestrings is fine with me, I see this as a step towards a deprecation/removal of the requiredFeatures attribute in svg.

[Philip Jägenstedt]

Since the existing use counter only measures the DOM API I'll add a
second use counter for the SVG case, so that both can be changed at
the same time without guessing about the usage.

Philip