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

Re: [Public WebGL] WEBKIT_ extensions



On Tue, Nov 15, 2011 at 11:15 AM, Chris Marrin <cmarrin@apple.com> wrote:


On Nov 15, 2011, at 7:44 AM, Benoit Jacob wrote:

>
> This new blog post by a Mozilla colleague may be worth skimming, in relation to vendor-specific prefixes.
>
> http://hsivonen.iki.fi/vendor-prefixes/

I don't think we should use this rant as justification for abandoning vendor specific prefixes. The "hellish" examples the author puts forth, CSS Animations, Transitions and Transforms, and requestAnimationFrame, are good examples of what vendor prefixes are for. There is no ratified standard for these features and using unprefixed properties or function calls would be premature. If authors don't like the idea of using prefixed property names, they shouldn't use unratified features. You could make the argument that, at least in the case of CSS Animations, Transitions and Transforms, they should have been ratified by now. But that's a different issue.

We should follow the same criteria. Until there is a ratified standard for an extension, it should have a vendor specific prefix. We have a nice situation. We never have to worry about vendor specific function names or constants since they're encapsulated in objects returned by getExtension().

So I think the rule should be basically what it says in the extension registry. Additionally I don't think we should ever use prefixes like EXT (as in WEBGL_EXT_lose_context) for unratified extensions. EXT, ARB, OES, etc. should only ever be used to mimic the names of the corresponding Khronos extension. So my additional rules would be:

1) Vendor prefixes should never appear in a spec, but should always be used in an implementation before an extension is ratified
2) An implementation should never use an unprefixed extension name before that extension is ratified
3) One vendor should never implement an extension with another vendor's prefix
4) The prefix should be prepended and never replace any part of the extension. So it should be WEBKIT_WEBGL_lose_context and not WEBKIT_lost_context.

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.

WEBGL_EXT_ seems as good a namespace as any in which to do prototyping. WEBGL_EXPERIMENTAL_ would be fine too. Other suggestions welcome.


And as I mentioned in a previous mail, we should split the entries in the registry into ratified and unratified extensions.

This is on my to-do list.

-Ken

 

-----
~Chris
cmarrin@apple.com





-----------------------------------------------------------
You are currently subscribed to public_webgl@khronos.org.
To unsubscribe, send an email to majordomo@khronos.org with
the following command in the body of your email:
unsubscribe public_webgl
-----------------------------------------------------------