- From: Dean Jackson <dino@apple.com>
- Date: Tue, 25 Jun 2013 07:31:59 +1000
- 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. Dean
Received on Monday, 24 June 2013 21:32:43 UTC