Re: [whatwg] Supporting feature tests of untestable features

On 2015-04-01 06:57, Kyle Simpson 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. 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?
>
> 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.
>

A featurecheck API? THat sort of makes sense.

I see two ways to do this.

One would be to call a function like (the fictional) "featureversion()" 
and get back a version indicating that the browser support the ECMA 
something standard as a bare minimum. But version checking is something 
I try to avoid even when doing programming on Windows (and MicroSoft 
advise against doing it).

So a better way might be:
featexist('function','eval')
featexist('document','link','rel','preload')
featexist('api','websocket')

Yeah the preload example does not look that pretty but hopefully you 
know what I'm getting at here. Maybe featexist('html','link','preload') 
instead?

On Windows programs I try to always dynamically load a library and then 
I get a function pointer to a named function, if it fails then I know 
the function does not exist in that dll and I can either fail gracefully 
or provide alternative code to emulate the missing function.
It's thanks to this that on streaming audio player I made axctually 
works on anything from Windows 2000 up to WIndows 8.1 and dynamically 
makes use of new features in more recent Windows versions thanks to 
being able to check if functions actually exists.

I use the same philosophy when doing Javascript and HTML5 coding.

With the featexist() above true is returned if present and false if not 
present.
Now what to do if eval() does not exist as a pre-defined function but a 
user defined eval() function exists instead for some reason.
My suggestion is that featexist() should return false in that case as it 
is not a function provided by the browser/client.

Now obviously a|"if (typeof featexist == 'function')|" would have to be 
done before calling featexist() and there is no way to get around that.

Another suggestion is that if a feature is disabled (by the user, the 
admin or the browser/client for some reason) ten featexist() should 
behave as if that feature does not exist&is not supported.
In other words featexist() could be a simple way to "ask" the browser if 
"is this available? can I use this right now?"


-- 
Roger Hågensen, Freelancer, http://skuldwyrm.no/

Received on Wednesday, 1 April 2015 08:36:20 UTC