On Nov 17, 2011, at 3:51 PM, Kenneth Russell wrote:
On Tue, Nov 15, 2011 at 11:15 AM, Chris Marrin <firstname.lastname@example.org> wrote:
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.
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.
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.
I want to make 2 points:
1) I think it's fine to have a common unratified prefix if you think it's really necessary (I don't). But if we do, we should keep it a prefix. If we intend a finalized extension to WEBGL_lose_context, then the unratified name should be EXPERIMENTAL_WEBGL_lose_context.
2) The problem with a common prefix is what happens when the proposal changes (which it will often, especially in the early days)? For a single browser an author can always say that he's supporting only the latest version. So when a new version of that browser comes out he changes his content to match. If 2 browsers are using the same prefix, the author now has no way of knowing which version of the extension he should write to. For instance:
1) The EXPERIMENTAL_WEBGL_fluffy_bunny extension is released.
2) Chrome and Firefox both come out with support for this extension.
3) And author does a getExtension("EXPERIMENTAL_WEBGL_fluffy_bunny"), sees it is supported and adds support for it to his content.
4) A new revision of the extension comes out which flips the orientation of the bunny.
5) Firefox comes out with support for this change. Chrome won't release a version with the change for 3 weeks.
6) If the author changes his content Firefox works and Chrome doesn't.
If instead Firefox used MOZ_WEBGL_fluffy_bunny and Chrome used WEBKIT_WEBGL_fluffy_bunny the author would have to do two getExtension calls. If either succeeds he can use the feature. When Firefox comes out with the change the author needs to add an a "flipBunny" flag. This gets set when the getExtension for Firefox call succeeds, and the bunny gets flipped when the flag is true.