Re: [whatwg] Supporting feature tests of untestable features

On Wed, 01 Apr 2015 06:57:43 +0200, Kyle Simpson <getify@gmail.com> wrote:

> There are features being added to the DOM/web platform, or at least  
> under consideration, that do not have reasonable feature tests  
> obvious/practical in their design. I consider this a problem, because  
> all features which authors (especially those of libraries, like me) rely  
> on should be able to be tested if present, and fallback if not present.
>
> Paul Irish did a round-up awhile back of so called "undetectables" here:  
> https://github.com/Modernizr/Modernizr/wiki/Undetectables
>
> I don't want to get off topic in the weeds and/or invite bikeshedding  
> about individual "hard to test" features.

I think we should not design a new API to test for features that should  
already be testable but aren't because of browser bugs. Many in that list  
are due to browser bugs. All points under "HTML5" are browser bugs AFAICT.  
Audio/video lists some inconsistencies (bugs) where it makes more sense to  
fix the inconsistency than to spend the time implementing an API that  
allows you to test for the inconsistency.

> So I just want to keep this discussion to a narrow request:
>
> Can we add something like a "feature test API" (whatever it's called)  
> where certain "hard" cases can be exposed as tests in some way?

Apart from <link rel=preload>, which features in particular?

> The main motivation for starting this thread is the new `link  
> rel=preload` feature as described here: https://github.com/w3c/preload
>
> Specifically, in this issue thread:  
> https://github.com/w3c/preload/issues/7 I bring up the need for that  
> feature to be testable, and observe that as currently designed, no such  
> test is feasable. I believe that must be addressed, and it was suggested  
> that perhaps a more general solution could be devised if we bring this  
> to a wider discussion audience.

I'm not convinced that a general API solves more problems than it causes.  
The feature test API is bound to have bugs, too.

A good way to avoid bugs is with test suites. We have web-platform-tests  
for cross-browser tests.

For <link rel>, we could solve the feature-testing problem by normalizing  
the case for supported keywords but not unsupported keywords, so you can  
check with .rel or .relList:

function preloadSupported() {
   var link = document.createElement('link');
   link.rel = 'PRELOAD';
   return link.rel == 'preload';
}

-- 
Simon Pieters
Opera Software

Received on Thursday, 2 April 2015 08:37:07 UTC