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

Re: [whatwg] Challenging canvas.supportsContext

From: Dean Jackson <dino@apple.com>
Date: Tue, 25 Jun 2013 07:31:59 +1000
Message-id: <162F008D-3EFC-4EF4-A9BD-1680E584EAE5@apple.com>
To: Benoit Jacob <jacob.benoit.1@gmail.com>
Cc: WHATWG <whatwg@lists.whatwg.org>

On 25/06/2013, at 5:56 AM, Benoit Jacob <jacob.benoit.1@gmail.com> wrote:

> 2013/6/21 Benoit Jacob <jacob.benoit.1@gmail.com>
>> Any other application use cases?
> Anyone?
> I believe that if no unquestionable application use case can be given, then
> this function should be removed from the spec.

I think I was the person who proposed the method, and we just implemented it
in WebKit.

I'm not going to oppose removal, but I do think it is still fairly useful. Tab
mentioned many of the things I had in mind (analogous to @supports, possibly
better described as "maybe" and "no", etc). Maybe convenient is a better word?

I don't really buy the argument that it is useless for feature detection because
even if supportsContext('webgl') returned true, you don't know if you can actually
use WebGL until you create a context. Obviously pages will have to be written
to support failing calls to getContext. They have to do this with or without
this API.

Also, the presence of window.WebGLRenderingContext doesn't necessarily indicate
that WebGL is supported. On iOS for example, that object is available in Safari
but calling getContext('webgl') fails. The supportsContext method would allow
authors to easily detect this case.

One could also imagine a vendor extension context type that is impossible to
detect via DOM properties, and is unable to avoid lazy instantiation.

Anyway, it seems most people want to remove it, so I'm not going to fight.

Received on Monday, 24 June 2013 21:32:43 UTC

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