Re: [whatwg] Supporting feature tests of untestable features

On 4/1/15 8:27 AM, James M. Greene wrote:
> We had it but browser cendors abandoned its proper behavior [for some
> historical reason unbeknownst to me]....

The support signal (the hasFeature() implementation) was not in any way 
coupled with the actual implementation.

So you would have cases in which hasFeature() claimed false even though 
the browser supported the feature, cases in which hasFeature() claimed 
true even though the browser didn't support the feature, and cases in 
which the browser had somewhat rudimentary support for the feature but 
hasFeature() claimed true because of various market pressures.  This was 
especially driven by the coarse nature of the "features" involved -- you 
could at best ask questions like "is this spec supported?", not "is this 
particular piece of functionality supported?".  That works OK for small 
targeted specs, but the W3C wasn't so much in the business of doing those.

The upshot was that in any sort of interesting case hasFeature was 
useless at best and misleading at worst.

> 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.

So let's consider this case.  How would a hasFeature deal with this 
situation?  At what point would you expect it to start returning "true" 
for the clipboard API?

-Boris

P.S.  Looking over the clipboard API, it seems like it really has the 
following bits: 1) The various before* events, which would be detectable 
if the spec added the corresponding onbefore* attributes to someplace, 
and 2) The copy/paste/etc events, which could likewise be detectable 
with on* attributes.  Am I missing something else that is not detectable 
for fundamental reasons?

Received on Wednesday, 1 April 2015 13:08:04 UTC