On Thu, Nov 17, 2011 at 8:24 PM, Benoit Jacob <firstname.lastname@example.org>
In the case of WEBKIT_lose_context, for example, Google added right away a conformance test for it in the trunk version of the test suite, long before any other vendor started looking at it. So there never was a serious risk of getting divergent implementations(bugs) of it, which is first of the two usual reasons for vendor prefixes.
Of course there's a risk of divergent implementations, because once they write their initial implementation, people get to use it in practice and figure out what's wrong with it.Â There's always a "risk of divergent implementations" if there's any chance that your first try at designing an API isn't the one you finish with.Â With nontrivial APIs, that's more of a guarantee than a chance.
The other reason for vendor prefixes is of course when vendors just can't agree on the spec, but so far WebGL extensions in general have been quite consensual, and WEBKIT_lose_context in particular is so simple that arguing about its details would be a waste of time.
Most WebGL extensions so far have been very simple, and piggybacked heavily off of underlying OpenGL extensions.
I disagree that the details of WEBKIT_lose_context are a waste of time.Â For example, it sounds like webglcontextlost is dispatched synchronously when loseContext is called.Â It should probably queue a task to dispatch it asynchronously, to match what happens under ordinary context loss.Â The WebGL spec is also not quite clear about exactly when webglcontextlost is dispatched, when the context is lost in the middle of running code; in the "WebGL Context Lost specification" thread we've discussed tightening this up.Â Depending on how that hashes out, this API might indeed want adjustment, which could very well land us with divergent implementations due to the (abrupt, and in my opinion premature) unprefixing of that extension.