- From: James M. Greene <james.m.greene@gmail.com>
- Date: Wed, 1 Apr 2015 09:04:53 -0500
- To: Boris Zbarsky <bzbarsky@mit.edu>
- Cc: WHATWG <whatwg@lists.whatwg.org>
> 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