- From: Tab Atkins Jr. <jackalmage@gmail.com>
- Date: Wed, 19 Jun 2013 15:36:03 -0700
- To: Kenneth Russell <kbr@google.com>
- Cc: whatwg <whatwg@lists.whatwg.org>, Brandon Benvie <bbenvie@mozilla.com>, James Robinson <jamesr@google.com>
On Wed, Jun 19, 2013 at 3:24 PM, Kenneth Russell <kbr@google.com> wrote:
>> That's true, but the answer still doesn't promise anything about what
>> getContext() will do. It may still return null and code will have to check
>> for that. What's the use case for calling supportsContext() without calling
>> getContext()?
>
> Any application which has a complex set of fallback paths. For example,
>
> - Preference 1: supportsContext('webgl', { softwareRendered: true })
> - Preference 2: supportsContext('2d', { gpuAccelerated: true })
> - Preference 3: supportsContext('webgl', { softwareRendered: false })
> - Fallback: 2D canvas
>
> I agree that ideally, if supportsContext returns true then -- without
> any other state changes that might affect supportsContext's result --
> getContext should return a valid rendering context. It's simply
> impossible to guarantee this correspondence 100% of the time, but if
> supportsContext's spec were tightened somehow, and conformance tests
> were added which asserted consistent results between supportsContext
> and getContext, would that address your concern?
It seems like this falls into the canPlayType() bucket, where you can
definitely give negatives, but your positives are at best hopeful.
Maybe we should just have it do the same thing, and return "maybe" or
"probably" rather than a boolean true?
~TJ
Received on Wednesday, 19 June 2013 22:36:48 UTC