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

Re: [whatwg] Challenging canvas.supportsContext

From: Boris Zbarsky <bzbarsky@MIT.EDU>
Date: Wed, 19 Jun 2013 15:52:10 -0400
Message-ID: <51C20BEA.2080904@mit.edu>
To: "Tab Atkins Jr." <jackalmage@gmail.com>
Cc: WHATWG <whatwg@lists.whatwg.org>
On 6/19/13 3:34 PM, Tab Atkins Jr. wrote:
> This is missing the point.  You don't want to wait until it's actually
> time to create the context.  Unless you torture your code flow, by the
> time you're creating a context you should already know that the
> context is supported.  The knowledge of which context to use is most
> useful well before that, when you're first entering the app.

But supportsContext doesn't give any guarantee that the getContext will 

> Plus, it doesn't matter how late you do the detection - if you do a
> straight *detection* at all rather than an initialization (that is, if
> you throw away the context you've just created for testing)

OK, but why are we making that assumption?  I guess if people insist on 
doing that, then we do in fact need something that will basically try to 
guess whether getContext might succeed.

> Like @supports, the supportsContext() method can be easy and reliable
> with a very simple definition for "supports" - it returns true if
> calling getContext() with the same arguments would return a context
> rather than erroring, and false otherwise.

Just so we're clear, this is _not_ what supportsContext is specified to 
do.  As specced, it will return false if you know for a fact that 
getContext would return null.  It will return true if you think that 
getContext might not return null.  This means that a true return doesn't 
really mean squat about what getContext will do.

And the reason for that is that you can't tell whether getContext will 
return null until you try to do it, given how getContext is specced.

Received on Wednesday, 19 June 2013 19:52:37 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 17:00:00 UTC