[Public WebGL] proposal draft for EXT_texture_filter_anisotropic

Glenn Maynard [email protected]
Mon Apr 2 15:26:52 PDT 2012

On Sun, Apr 1, 2012 at 10:15 PM, Benoit Jacob <[email protected]> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://khronos.org/pipermail/public_webgl_khronos.org/attachments/20120402/7c1a999c/attachment.html>

More information about the public_webgl mailing list