[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Public WebGL] WEBKIT_ extensions

On Thu, Nov 17, 2011 at 5:24 PM, Benoit Jacob <bjacob@mozilla.com> wrote:
On 17/11/11 07:14 PM, Glenn Maynard wrote:
On Thu, Nov 17, 2011 at 6:51 PM, Kenneth Russell <kbr@google.com
<mailto:kbr@google.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
   has sufficed.)

   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.

Thanks, Benoit. Agree with all of your points.

Glenn, to address your question further:

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 more quickly.

2. Requiring a vendor prefix implies that there will be two nearly identical copies of the extension in the registry during its prototyping phase. Keeping them in sync will likely be my responsibility, and from a selfish perspective, I am opposed to having to do this work, which I consider useless.



Glenn Maynard