Bug 15555 - Figure out which feature strings should be supported
Figure out which feature strings should be supported
Product: WebAppsWG
Classification: Unclassified
Component: DOM
All All
: P2 normal
: ---
Assigned To: Anne
Depends on:
  Show dependency treegraph
Reported: 2012-01-14 08:13 UTC by Ms2ger
Modified: 2012-10-16 15:33 UTC (History)
3 users (show)

See Also:


Note You need to log in before you can comment on or make changes to this bug.
Description Ms2ger 2012-01-14 08:13:48 UTC
See discussion in <https://bugs.webkit.org/show_bug.cgi?id=76214> and a list I assembled a while ago at <http://wiki.whatwg.org/wiki/DOM_features>.
Comment 2 Anne 2012-02-03 13:37:27 UTC
Excellent idea!
Comment 3 Aryeh Gregor 2012-10-14 16:56:08 UTC
I looked at Google Code Search (which seems to still work?), and here are some of the uses I found before I got bored <http://code.google.com/codesearch#search/&q=hasFeature%20lang:%5Ejavascript$&type=cs>.  I didn't check that all of these actually call the native document.implementation.hasFeature and not some other thing called that, but in some cases it's obvious they do unless prototype hackery is happening.

 	hasSupport.support = ( typeof document.implementation != "undefined" &&
 			document.implementation.hasFeature( "html", "1.0" ) || ie55 )
http://xinc.googlecode.com/svn, trunk/web/js/tabpane.js

  1339: 	      if ( typeof document.implementation != "undefined" &&
  1340: 	         document.implementation.hasFeature("HTML",   "1.0") &&
  1341: 	         document.implementation.hasFeature("Events", "2.0") &&
  1342: 	         document.implementation.hasFeature("CSS",    "2.0") ) {
  1343: 	         document.addEventListener("mouseup",   this._mouseUpHandler.bindAsEventListener(this),  false);
http://arctos.googlecode.com/svn, historical/v2.4/includes/rico.js

http://browserscope.googlecode.com/svn, trunk/static/raphael-min.js

   579: var supportAtRule = impl.hasFeature('CSS2', '') ?
   580:         function(rule) {
http://sintoniadoamor.googlecode.com/svn, trunk/MusicoEMusicas/src/packages/Modernizr.1.7/Content/Scripts/modernizr-1.7.js

    58: ... _HAS_DOM_FEATURE&&window.Document&&!Document.prototype.load&&document.implementation.hasFeature('LS','3.0')){Sarissa.getDomDocument=function(s ...
http://vosao.googlecode.com/svn, trunk/web/src/main/webapp/static/js/sarissa.js

  1921: ... w.w3.org/TR/SVG11/feature#";return(document.implementation&&(document.implementation.hasFeature("org.w3c.svg","1.0")||document.implementation. ...
  2068: ... w.w3.org/TR/SVG11/feature#";return(document.implementation&&(document.implementation.hasFeature("org.w3c.svg","1.0")||document.implementation. ...
http://geocontexter.googlecode.com/svn, trunk/public/library/OpenLayers/OpenLayers.js

  2375: hasNativeSVG: function() {
  2376:   if (document.implementation && document.implementation.hasFeature) {
  2377:     return document.implementation.hasFeature(
  2378:           'http://www.w3.org/TR/SVG11/feature#BasicStructure', '1.1');
http://pentaho-cdf.googlecode.com/svn, trunk/bi-platform-v2-plugin/cdf/js/lib/CCC/svg.js

  3781:     var imp = Y.config.doc && Y.config.doc.implementation;
  3782:     return (imp && (!imp.hasFeature('Events', '2.0')));
http://bhl-bits.googlecode.com/svn, trunk/bhl-e/pre-ingest/PreIngest/src/main/webapp/resources/yui/build/yui/yui.js

    16: if(document.implementation && document.implementation.hasFeature &&
    17: !document.implementation.hasFeature('WebForms', '2.0')){

http://webforms2.googlecode.com/svn, trunk/webforms2.js

    55: config.hasNative = !!(document.implementation
    56:                         && document.implementation.hasFeature
    57:                         && document.implementation.hasFeature("XPath", null));
http://gmaps-api-issues.googlecode.com/svn, trunk/puppet/xpath.js

   653: var tdi=_ac["implementation"];
   654: if((tdi)&&(tdi["hasFeature"])&&(tdi.hasFeature("org.w3c.dom.svg","1.0"))){
http://selenium.googlecode.com/svn, trunk/selenium/src/web/tests/html/dojo-0.4.0-mini/dojo.js

    73: uu.ua.domrange = uud.implementation && uud.implementation.hasFeature("Range", "2.0"); // is DOM Level2 Range Module
http://uupaa-js.googlecode.com/svn, trunk/0.6/uupaa.js

Notably, I think at least one browser returns true for each of these, right?  If so, are there any objections to just always returning true?  That means we should fall into the "has feature" codepath.  The only danger would be if people gated on hasFeature() for a nonexistent feature by mistake and then unwittingly left the dead code in, but that seems like a reasonably small risk.

Anyone object to me making hasFeature always return true?  I'm writing a patch for Gecko, although I don't know if it will get accepted:

Comment 4 Aryeh Gregor 2012-10-14 17:18:06 UTC
Also, we should add isSupported() back to the spec and make it always return true too, unless there's reason to believe it can actually be dropped?  Dropping useless things is not worth the pain if any pages use them -- it's practically guaranteed to break the pages, and it's no big deal to just leave them as no-ops forever.
Comment 5 Anne 2012-10-14 20:13:26 UTC
Actually, we want to remove everything we can get away with, including features that might be in use (e.g. the attribute stuff). That's the way the DOM standard has been written.

The cost of keeping something forever is greater than some short term hassle.

Always returning true for hasFeature() works for me.
Comment 6 Aryeh Gregor 2012-10-15 07:12:44 UTC
(In reply to comment #5)
> Actually, we want to remove everything we can get away with, including
> features that might be in use (e.g. the attribute stuff). That's the way the
> DOM standard has been written.
> The cost of keeping something forever is greater than some short term hassle.

Not if the definition and implementation take about five lines each.  Then the cost of keeping it forever is approximately zero, in the scope of the web platform's complexity.  Saying we should break pages for the sake of hypothetical gains in long-term platform simplicity sounds like a smaller-scale version of the XHTML 2.0 argument.  Browsers cannot afford to make more than very few short-term sacrifices, because they'll lose market share, and we need to save those sacrifices for where they're really worth it.  I think the approach to useless functions/attributes that are implemented by all browsers should be to make them no-ops, not remove them.

I asked on the Gecko bug what people think.
Comment 7 Aryeh Gregor 2012-10-16 15:33:37 UTC


Feel free to clean up the style or whatnot.