Ping --- I thought that there was sufficient agreement in this thread, around the fact that supportsContext, as currently spec'd and currently implementable, is a feature without a valid use case, that removing it from the spec is the right thing to do at this point.
Benoit 2013/7/18 Benoit Jacob <jacob.benoi...@gmail.com> > The thread seems to have settled down. > > I still believe that supportsContext, in its current form, should be > removed from the HTML spec, because as currently spec'd it could be > implemented as just returning whether WebGLRenderingContext is defined. I > also still believe that it will be exceedingly hard to spec supportsContext > in a way that makes it useful as opposed to just calling getContext. > > Emails in this thread have conveyed the idea that it is already useful to > return whether WebGL is at least not blacklisted, regardless of whether > actual context creation would succeed. That, however, is impossible to > specify, and depends too much on details of how some current browsers and > platforms work: > - driver blacklists will hopefully be a thing of the past, eventually. > - on low-end mobile devices, the main cause of WebGL context creation > failure is not blacklists, but plain OpenGL context creation failures, or > non-conformant OpenGL behavior, or OOM'ing right after context creation. > For these reasons, justifying supportsContext by driver blacklisting seems > like encoding short-term contingencies into the HTML spec, which we > shouldn't do. Besides, even if we wanted to do that, there would remain the > problem that that's impossible to spec in a precise and testable way. > > For these reasons, I still think that supportsContext should be removed > from the spec. > > Benoit > > > > 2013/6/19 Benoit Jacob <jacob.benoi...@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 >> >> >