[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 <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.)
I probably don't have enough committee experience to understand what you're referring to here. What I know is that everyone I've asked at Mozilla, is supportive of the change I'm making here, and that Ken also gave me a green light on Feb. 27.



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.
It's not a black-or-white situation. I understand that some people will rely on vendor-prefixed extensions no matter what, but if we can at least avoid them to keep relying on the vendor-prefixed name after the unprefixed version is available, that will already be a great progress over the situations in CSS land.
 
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.
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?

My goal is to keep WebGL implementable. This means that if by 2015 a new browser vendor wants to start supporting WebGL, they should be able to. That should be not only theoretical, but practical: they should be able to effectively run all or most of the existing WebGL apps. But if existing WebGL apps massively require existing vendors' vendor-prefixed extension names, that won't be possible.

This is not a theoretical problem, it has happened with CSS, especially on mobile devices. This has been at the center of a big controversy recently.

Cheers,
Benoit

--
Glenn Maynard