[whatwg] Challenging canvas.supportsContext

[Benoit Jacob]

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