[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 7:21 PM, Benoit Jacob <email@example.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.