W3C home > Mailing lists > Public > whatwg@whatwg.org > September 2012

Re: [whatwg] [canvas] Proposal for supportsContext

From: Paul Irish <paul.irish@gmail.com>
Date: Mon, 10 Sep 2012 16:08:28 -0700
Message-ID: <CAHSVx=-mZ=U+8ueyVYbXoyrPADLp31p2Hzj0fYyhX5=QL=4eFg@mail.gmail.com>
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

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:45 UTC