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

Re: [Public WebGL] WEBKIT_ extensions

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.

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


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