- From: Paul Irish <paul.irish@gmail.com>
- Date: Mon, 10 Sep 2012 16:08:28 -0700
- To: Glenn Maynard <glenn@zewt.org>
- Cc: "whatwg@lists.whatwg.org" <whatwg@lists.whatwg.org>, Dean Jackson <dino@apple.com>, Ashley Gullen <ashley@scirra.com>
On Mon, Sep 10, 2012 at 3:14 PM, Glenn Maynard <glenn@zewt.org> wrote: > > (By the way, I'm not sure about it being "bad practice" to create a context > in advance. It's just standard feature testing, which is exactly how > JavaScript developers have been taught to detect features. > Indeed, js developers are guided towards feature detection, and rightly so. But which detect to use is a bit of cat 'n mouse and implementors don't play by the same rules here. As Mike Taylor pointed out, Modernizr used to create a context because checking !!window.WebGLRenderingContext is completely unreliable. But the Mozilla and Chrome GPU teams persuaded us to avoid the up-front context creation. On Mon, Sep 10, 2012 at 2:44 PM, Tobie Langel <tobie.langel@gmail.com> wrote: > Only expose the API when you can create the context. This is the ideal and most expected feature detect typically, though in WebGL's case we share a getContext method with 2d and opera-2dgame, so hiding the constructor global comes in second place. So far, Chrome and Firefox weren't excited about this approach. It's extremely important that we have feature detection techniques that we can trust the result of, across implementations. I'm a big +1 for supportsContext and as an API, it seems to introduce the ability with the least amount of collateral damage. _ Paul Irish, Lead Modernizr Dev
Received on Monday, 10 September 2012 23:09:25 UTC