Re: [whatwg] Supporting feature tests of untestable features

So let's take the Clipboard API as Example #2.

Given the current state of things, the abandoned/unreliable former
feature/command testing APIs I previously mentioned, and the fact that the
API is based around a long-standing concept (copy/cut/paste) that already
has overlapping attributes and events in existence... what would the
"right" approach be for making this new API properly feature detectable?

We had discussed checking for the existence of the new `ClipboardEvent`
constructor but unfortunately Firefox already half-baked that in without
actually/fully implementing the API (at all, I think, but perhaps they've
implemented the "paste" handlers by now). We can call that a browser bug
and ask Firefox to accommodate some change but what would that change be?
Perhaps constructing a new ClipboardEvent of the type we want to check
support for (copy/cut/paste) and any type name that is unsupported **OR NOT
IMPLEMENTED** should throw an error?

Thoughts?

Sincerely,
   James M. Greene
On Apr 2, 2015 3:50 AM, "Karl Dubost" <karl@la-grange.net> wrote:

>
> Le 2 avr. 2015 à 17:36, Simon Pieters <simonp@opera.com> a écrit :
> > On Wed, 01 Apr 2015 06:57:43 +0200, Kyle Simpson <getify@gmail.com>
> wrote:
> >> There are features being added to the DOM/web platform, or at least
> under consideration, that do not have reasonable feature tests
> obvious/practical in their design.
> >
> > I think we should not design a new API to test for features that should
> already be testable but aren't because of browser bugs.
>
> Agreed with what Simon is saying.
>
> All these are really bugs in detectability and implementations of the
> features.
> https://github.com/Modernizr/Modernizr/wiki/Undetectables
>
> What we could do is try to increase the granularity of the API/tests if
> the API is too shallow for detecting what is useful.
>
> Adding another meta layer of testing makes the Web Compatibility story
> even harder. As usual, we look at the good side of the story as in it will
> help us make better site, but what I'm seeing often is more on the side of
>
>         What is the hook that will help us to say 'Not Supported'
>         because our project manager told us browser not below
>        version blah.
>
>
> (Based on sad true story. Your perpetual blockbuster)
>
> --
> Karl Dubost 🐄
> http://www.la-grange.net/karl/
>
>

Received on Thursday, 2 April 2015 12:24:21 UTC