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?
