Re: [whatwg] Supporting feature tests of untestable features

P.S. If you want to get involved, here is a link to the archive of the most
recent email thread about feature detection for the Clipboard API:

https://lists.w3.org/Archives/Public/public-webapps/2015JanMar/0592.html


Sincerely,
    James Greene


On Wed, Apr 1, 2015 at 9:04 AM, James M. Greene <james.m.greene@gmail.com>
wrote:

> > 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:10:51 UTC