[Public WebGL] proposal draft for EXT_texture_filter_anisotropic

Glenn Maynard [email protected]
Sun Apr 1 17:28:20 PDT 2012


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...
URL: <http://khronos.org/pipermail/public_webgl_khronos.org/attachments/20120401/d90e537d/attachment.html>


More information about the public_webgl mailing list