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

Re: [Public WebGL] proposal draft for EXT_texture_filter_anisotropic

On Sun, Apr 1, 2012 at 10:15 PM, Benoit Jacob <bjacob@mozilla.com> wrote:
Again, this is not a spec thing, it's something that was agreed on on this mailing list and that we agreed to record, alongside existing rules, in the extension registry. Already before my change, this WebGL WG already had at least 2 hard rules around vendor prefixes:
 1. No vendor may start implementing an extension proposal before it's moved to draft status (that is mentioned in the extension registry. Was added as a result of discussion in this thread).
 2. That one vendor may not use another vendor's prefix (that is not explicitly said in the extension registry but was discussed on this list about the WEBGL_lose_context extension. Side note: should we add a mention of it in the registry?)

WebGL can't make rules about vendor prefixes.  You don't "own" the vendor's namespace; the vendor does--that's why it's a vendor prefix.  It's fine to say "please don't do this"; it's empty handwaving to say "you may not do this".  Sure they can.
I didn't add this to the spec, but to the extension registry. If you think this is the wrong venue for it, then what is the right place?

You said it was "mandated", so I assume that wherever it is, it's considered normative.  The right place is presumably on mailing lists, and other places where cross-vendor discussions take place.
We already agreed on that on this mailing list, on Feb 27, in this thread, and had agreed to add that rule in the extension registry. Why not record such decisions in a place where they're easy to find, such as the extension registry?

Backwards-compatibility decisions are browser-wide decisions.  (No sane browser vendor is going to apply different backwards-compat policies to different APIs based on them having separate, isolated discussions on their obscure mailing lists.)  This isn't a place decisions like that are made--much less threads titled "proposal draft for EXT_texture_filter_

There may be no ideal place for this, but public-webapps is almost certainly more appropriate than here.

I am not in favor of a transitional period because that is a slippery slope and it's easier to hammer the point that draft extensions can be renamed or modified or removed at any time, and apps that want to not be broken should consider: a) testing for the unprefixed extension; b) where possible, offering a graceful fallback if the extension is not available.

I think this is wrong, but it's pointless to debate it here.

I concur with James; encouraging people to use the non-prefixed version before it's even released is seriously questionable.  At the very least, code doing so must prefer to prefixed version to the unprefixed version if both are available; this works around the issues he describes.  (But users will get that wrong; it's much safer to tell people not to use it until it's released.)

Glenn Maynard