On Wed, 01 Apr 2015 06:57:43 +0200, Kyle Simpson <get...@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

Reply via email to