- From: Benoit Jacob <jacob.benoit.1@gmail.com>
- Date: Wed, 19 Jun 2013 14:17:14 -0400
- To: whatwg@lists.whatwg.org
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
Received on Wednesday, 19 June 2013 18:17:40 UTC