[Public WebGL] proposal draft for EXT_texture_filter_anisotropic

Benoit Jacob [email protected]
Sun Apr 1 18:04:49 PDT 2012

----- Original Message -----

> 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.)
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. 


> --
> Glenn Maynard
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://khronos.org/pipermail/public_webgl_khronos.org/attachments/20120401/6e188882/attachment.html>

More information about the public_webgl mailing list