[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Public WebGL] WEBKIT_ extensions
On Thu, Nov 17, 2011 at 8:24 PM, Benoit Jacob <email@example.com>
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.
> 1. I feel that having multiple browsers implement the same
prototype extension independently will expose ill-defined areas more
quickly, and allow the extension and its conformance tests to converge
> 2. Requiring a vendor prefix implies that there will be two nearly
identical copies of the extension in the registry during its prototyping
Everyone's implementing the same extension. The only difference is that it's temporarily exposed under a different name.
You don't need to do that at all, no more than other web APIs spec prefixed implementations separately.