W3C home > Mailing lists > Public > whatwg@whatwg.org > June 2013

Re: [whatwg] Challenging canvas.supportsContext

From: Jonas Sicking <jonas@sicking.cc>
Date: Wed, 26 Jun 2013 01:44:04 +0200
Message-ID: <CA+c2ei88s+zYGk0-DZZce0UWVSUtVhd+us_pg3zbD-xSRThsiQ@mail.gmail.com>
To: Simon Pieters <simonp@opera.com>
Cc: Benoit Jacob <jacob.benoit.1@gmail.com>, WHATWG <whatwg@lists.whatwg.org>, Dean Jackson <dino@apple.com>
On Tue, Jun 25, 2013 at 10:28 PM, Simon Pieters <simonp@opera.com> wrote:
> On Tue, 25 Jun 2013 21:01:27 +0200, Dean Jackson <dino@apple.com> wrote:
>
>> Showing or hiding interface objects is not something I want to do.
>
> It's possible that I missed it, but, why not?

I have the same question.

The whole hasFeature and isSupported disasters of DOM2 (or was it 3?)
lead to us advocating, and a lot of websites switching to, patterns
like:

if (window.indexedDB) {
  x = indexedDB.open(...);
  ...
}

and

if (window.WebSocket) {
  x = new WebSocket(...);
}

I.e. testing for features by checking if the DOM calls are available,
not by creating separate functions that are supposed to tell you if a
given feature is there or not.

Granted, this is somewhat different since the interface object would
act like a proxy to see if a feature is there, even though you
generally don't use the feature through the interface object.

But it's an interface object that should naturally be there if you
implement the feature, and naturally not there if you don't.

/ Jonas
Received on Tuesday, 25 June 2013 23:44:57 UTC

This archive was generated by hypermail 2.3.1 : Monday, 13 April 2015 23:09:22 UTC