Re: [whatwg] Supporting feature tests of untestable features

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

Not to side-track this generalized conversation too much but it may
actually be useful to detail the state of Clipboard API detection here
based on current practices and APIs (which is completely hopeless):

*Event-based detection:*
The "onbeforecopy", "onbeforecut", "onbeforepaste", "oncopy", "oncut", and
"onpaste" events have all existed in IE, Safari, and Chrome (and now modern
Opera, I'd imagine) for quite some time, related to standard user actions
for copy/cut/paste (and more importantly for ContentEditable purposes,
IIRC).  So this approach would return false positives for at least every
modern major browser other than Firefox (if not Firefox, too).

*Method-based detection:*
Firefox, for example, implements
`clipboardData.setData()`/`clipboardData.getData()` and also implements the
`ClipboardEvent` constructor, does not actually modify the user's clipboard
on `clipboard.setData()`. Additionally, to even get access to
`clipboardData`, you must be able to synthetically execute one of these
commands (e.g. "copy"). So this approach isn't great, and will return false
positives for Firefox anyway.

*Command-based detection:*
Since the actual actions like "copy", etc. will be triggered via ye olde
query commands (i.e. `document.execCommand`), another "proper" approach for
detection would be using the `document.queryCommandSupported` and
`document.queryCommandEnabled` methods to check for support.  However,
those methods work inconsistently cross-browser, some throw Errors instead
of returning `false`, etc.  Beside all that, the "copy", "cut", and "paste"
query commands have all previously existed for ContentEditable purposes.
So this approach is flawed, unreliable, and will return false positives.

*Implementation-based detection:*
As previously discussed in this thread,
`document.implementation.hasFeature` and/or `Node.isSupported` could have
been another idea for feature detection but has already been bastardized to
the point of no return.  So this approach, if implemented, would almost
always return false positives (e.g. Firefox, if not all other browsers,
returns `true` for everything).



As far as checking on full implementations, it would be nice if specs
followed some reliable versioning pattern like SemVer that we could use to
verify the "correct" level of support.  Even at that point, though: should
such an approach only check against W3C specs or also WHATWG specs?

Additionally, as you mentioned, it would be much better if we could create
some API which would offer the ability to check for partial implementations
(features/sub-features) vs. full spec implementations as well.  For
example, Chrome has implemented the "paste" feature of the Clipboard API
nearly completely but has NOT implemented the "copy" or "cut" features.

Sincerely,
    James Greene


On Wed, Apr 1, 2015 at 8:07 AM, Boris Zbarsky <bzbarsky@mit.edu> wrote:

> 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 14:05:40 UTC