[whatwg] Challenging canvas.supportsContext

[Benoit Jacob]

Did any email in this thread having provided any valid application use
case? I can't see many application use cases being mentioned at all, and
the most of the ones that were have been rebuked as far as I can see.

The most serious remaining one, that I can see, is the Chrome Web Store.
However:
 - it is a case where reliability is particularly important, which goes in
favor of an actual getContext;
 - this kind of application inherently requires browser-specific APIs
anyway (at least for the time being --- we can revisit when it's no longer
the case), so having a standard API for this particular feature is less
valuable than elsewhere.

Any other application use cases?

Keep in mind that this is all in sharp contrast with every single other
canvas / 2d / webgl API feature that I can think of, for which application
use cases are abundant.

Benoit


2013/6/19 Benoit Jacob <jacob.benoit.1 at gmail.com>

> Dear list,
>
> I'd like to question the usefulness of canvas.supportsContext. I tried to
> think of an actual application use case for it, and couldn't find one. It
> also doesn't seem like any valid application use case was given on this
> list when this topic was discussed around September 2012.
>
> The closest thing that I could find being discussed, was use cases by JS
> frameworks or libraries that already expose similar feature-detection APIs.
> However, that only shifts the question to: what is the reason for them to
> expose such APIs? In the end, I claim that the only thing that we should
> recognize as a reason to add a feature to the HTML spec, is *application*use cases.
>
> So let's look at the naive application usage pattern for supportsContext:
>
>   if (canvas.supportsContext("webgl")) {
>     context = canvas.getContext("webgl");
>   }
>
> The problem is that the same can be achieved with just the getContext
> call, and checking whether it succeeded.
>
> In other words, I'm saying that no matter what JS libraries/frameworks may
> offer for feature detection, in the end, applications don't want to just *
> detect* features --- applications want to *use* features. So they'll just
> pair supportsContext calls with getContext calls, making the
> supportsContext calls useless.
>
> There is also the argument that supportsContext can be much cheaper than a
> getContext, given that it only has to guarantee that getContext must fail
> if supportsContext returned false. But this argument is overlooking that in
> the typical failure case, which is failure due to system/driver
> blacklisting, getContext returns just as fast as supportsContext --- as
> they both just check the blacklist and return. Outside of exceptional cases
> (out of memory...), the slow path in getContext is the *success* case,
> and again, in that case a real application would want to actually *use*that context.
>
> Keep in mind that supportsContext can't guarantee that if it returns true,
> then a subsequent getContext will succeed. The spec doesn't require it to,
> either. So if the existence of supportsContext misleads application
> developers into no longer checking for getContext failures, then we'll just
> have rendered canvas-using applications a little bit more fragile. Another
> problem with supportsContext is that it's untestable, at least when it
> returns true; it is spec-compliant to just implement it as returning
> whether the JS interface for the required canvas context exists, which is
> quite useless. Given such deep problems, I think that the usefulness bar
> for accepting supportsContext into the spec should be quite high.
>
> So, is there an application use case that actually benefits from
> supportsContext?
>
> Cheers,
> Benoit
>
>