[Public WebGL] proposal draft for EXT_texture_filter_anisotropic
Sun Apr 1 18:10:21 PDT 2012
Sorry Glenn, but I'm strongly in support of Benoit's position on this one.
I think every browser vendor out there deeply regrets the current scenario
with CSS prefixes, nobody wants to repeat it. It is not a strenuous thing
to write extension fallback checks, and for most developers their library
of choice will abstract it away from them. The few developers who's content
does break will usually be able to fix it with a couple line of
search/replace and a stern scolding.
We need to enable WebGL to move forward cleanly, without getting mired down
with legacy support. The spec is absolutely the right place to do that, and
NOW is absolutely the right time to do it.
On Sun, Apr 1, 2012 at 5:28 PM, Glenn Maynard <[email protected]> wrote:
> On Sun, Apr 1, 2012 at 7:21 PM, Benoit Jacob <[email protected]> wrote:
>> I understand that, and consider it acceptable because these prefixed
>> extensions are drafts. The rule I just added, precisely, guarantees that
>> only draft extensions ever have a prefix. The cost of relying on draft
>> extensions is that they can go away at any time, while on the contrary,
>> browsers should not remove support for official extensions.
> It doesn't matter if you consider it acceptable; it only matters if vendor
> browsers consider it acceptable. You can't mandate that browser APIs
> change their backwards-compatibility policies for your one API; WebGL isn't
> "special", it's just another API. If their policy is to keep prefixed APIs
> around to preserve backwards-compatibility, then they're going to do that.
> (If their policy is to remove prefixed versions, then they're doing it
> anyway; either way, saying it in specs will do nothing.)
> Web developers can start checking for the un-prefixed extension name
>> before the extension moves to official status, to avoid effective breakage.
> Remember that backwards-compatibility is about what web developers do, not
> what they could be doing.
>> If we did that, we would get a serious controversy, similar to what
>> recently happened in CSS land. The scenario is:
>> - browser engine X enjoys strong position on market M
>> - apps in market M target engine X's vendor-prefixed extensions
>> - extensions move to official status, but the vendor-prefixes are left
>> in place "for compatibility"
>> - apps keep using X's vendor-prefixed extension names, even though
>> they're official now
>> - browser engine Y tries to enter market M, but can't run existing apps:
>> apps require X's vendor prefix, which Y is not allowed to support.
> Specs are the wrong venue for pushing this argument.
> Glenn Maynard
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the public_webgl