Re: [whatwg] Supporting feature tests of untestable features

We had it but browser cendors abandoned its proper behavior [for some
historical reason unbeknownst to me]....

DOMImplementation.hasFeature (document.hasFeature):
http://www.w3.org/TR/DOM-Level-3-Core/core.html#ID-5CED94D7

and

Node.isSupported:
http://www.w3.org/TR/DOM-Level-3-Core/core.html#Level-2-Core-Node-supports

We are running into the exact same issues with the HTML Clipboard API being
unreliably detectable. Even more troubling, this is especially true because
it is already partially supported (paste events) in some browsers (e.g.
Chrome), not at all supported in others, and fully supported in none.

Sincerely,
   James M. Greene
On Apr 1, 2015 3:36 AM, "Roger Hågensen" <rh_whatwg@skuldwyrm.no> wrote:

> 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 12:28:03 UTC