Intent to Remove: DOMImplementation.hasFeature() returning false

64 views
Skip to first unread message

Erik Dahlström

unread,
Apr 20, 2015, 10:41:39 AM4/20/15
to blin...@chromium.org
Primary eng (and PM) emails
e...@opera.com


Link to “Intent to Deprecate” thread
https://groups.google.com/a/chromium.org/d/msg/blink-dev/r2aARnIHG4k/mGAsu9RGKSMJ


Summary
Make DOMImplementation.hasFeature() return true always.


Motivation
hasFeature() is an antiquated form of feature detection. By philipj's
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")`.


Usage information from UseCounter
Total usage of hasFeature:
https://www.chromestatus.com/metrics/feature/timeline/popularity/230 (~5%)

hasFeature returning false:
https://www.chromestatus.com/metrics/feature/timeline/popularity/231
(~0.0045%)

hasFeature returning false internally (in svg code):
https://www.chromestatus.com/metrics/feature/timeline/popularity/594 (0%)

What these counters measure is first, all callers of
DOMImplementation.hasFeature(). Second, how often the hasFeature call
results in false being returned. And third, how often false was returned
in SVG content as part of switch/requiredFeatures tests.


Entry on chromestatus.com
https://developer.mozilla.org/en-US/docs/Web/API/DOMImplementation.hasFeature


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. However, same as for hasFeature in
general, the granularity and reliability of this in svg is not that good
anyway.


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

Kouhei Ueno

unread,
Apr 20, 2015, 10:48:24 AM4/20/15
to Erik Dahlström, blink-dev
non-OWNER lgtm, love to see this happen :)

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



--
Kouhei Ueno

Philip Jägenstedt

unread,
Apr 20, 2015, 10:56:13 AM4/20/15
to Erik Dahlström, blink-dev
LGTM

This code path has been deprecated since M41, and if removed today would be gone in M44. In this case there is also the opportunity to keep the deprecation warning while changing the return value to help developers understand why their Web app just broke. It's a bit of extra work, and no one will tell us if they found it useful, but I suggest doing that and removing the code entirely after the M45 branch point.

Philip

patrick...@gmail.com

unread,
Apr 20, 2015, 11:48:14 AM4/20/15
to blin...@chromium.org
This is currently how Modernizr detects svg as an image as being available. Once this is removed, is there another suggested way?

Erik Dahlström

unread,
Apr 20, 2015, 12:04:06 PM4/20/15
to blin...@chromium.org
That's not part of the core modernizr set, right?

I found this:
https://github.com/Modernizr/Modernizr/blob/master/feature-detects/svg/asimg.js

The above test has some disclaimers, and note that it would continue to
"work". As in, it would return true / "svg-in-img is supported" even after
this change.


On Mon, 20 Apr 2015 17:48:14 +0200, <patrick...@gmail.com> wrote:

> This is currently how Modernizr detects svg as an image as being
> available.
> Once this is removed, is there another suggested way?
>
> On Monday, April 20, 2015 at 10:41:39 AM UTC-4, Erik Dahlström wrote:
>>
>> Primary eng (and PM) emails
>> e...@opera.com <javascript:>
> To unsubscribe from this group and stop receiving emails from it, send
> an email to blink-dev+...@chromium.org.


TAMURA, Kent

unread,
Apr 21, 2015, 4:38:36 AM4/21/15
to Philip Jägenstedt, Erik Dahlström, blink-dev
LGTM2.

--
TAMURA Kent
Software Engineer, Google


Chris Harrelson

unread,
Apr 21, 2015, 12:47:49 PM4/21/15
to TAMURA, Kent, Philip Jägenstedt, Erik Dahlström, blink-dev
LGTM3
Reply all
Reply to author
Forward
0 new messages