On 17/11/11 07:14 PM, Glenn Maynard wrote:
On Thu, Nov 17, 2011 at 6:51 PM, Kenneth Russell <firstname.lastname@example.org<mailto:email@example.com>> wrote:
I strongly feel that it is necessary to allow multiple vendors to
prototype a WebGL extension under the same name -- and not with
different vendor prefixes -- before it is ratified. (In the WebGL
working group, we haven't yet decided upon a formal process for
ratifying WebGL extensions -- so far, consensus in the working group
For this reason I don't support requiring a browser vendor prefix
before a WebGL extension is made official. If necessary we can put
this to a formal vote in the working group.
You didn't give a reason, though. Why do you feel this is necessary?
Browsers prototype web APIs by each putting them under their own
prefix. WebGL is a web API, too. What's special about WebGL for it to
not follow the same conventions as everything else?
I agree strongly with Ken here.
To answer your question, a special thing about WebGL is the quality of its conformance tests. When I talk to colleagues about the WebGL conformance test suite, their reaction is: wow, we should do the same for every Web API.
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. 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.
I'm not saying that we should stop using prefixes altogether; I'm just saying that we have solid examples of extensions for which using a vendor prefix hasn't been really needed.