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

Re: [Public WebGL] proposal draft for EXT_texture_filter_anisotropic

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 <glenn@zewt.org> wrote:
On Sun, Apr 1, 2012 at 7:21 PM, Benoit Jacob <bjacob@mozilla.com> 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