[Public WebGL] proposal draft for EXT_texture_filter_anisotropic
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
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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the public_webgl