[Public WebGL] proposal draft for EXT_texture_filter_anisotropic

Glenn Maynard [email protected]
Sun Apr 1 18:26:13 PDT 2012


On Sun, Apr 1, 2012 at 7:58 PM, Boris Zbarsky <[email protected]> wrote:

> On 4/1/12 8:04 PM, Glenn Maynard wrote:
>
>> Nothing at all is gained by removing
>> vendor prefixes for things like interface names and extensions
>>
>
> Except the minor gain of encouraging pages to write cross-browser content
> instead of browser-specific content, yes?
>

Arguably.  Debates like that should take place in the right place, though.

On Sun, Apr 1, 2012 at 8:04 PM, Benoit Jacob <[email protected]> wrote:

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

It's not about committee experience (most modern Web spec development isn't
done by committee).  It's simply that specs can't force browsers to do
anything, and that they long ago stopped pretending that they can.
Browsers will have their policies regarding prefixing, and if you disagree
with them, telling them to change it in strange venues like this is an
empty gesture at best.

> 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?
>

You said it was "mandated", so I assume that wherever it is, it's
considered normative.  The right place is presumably on mailing lists, and
other places where cross-vendor discussions take 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.
>

That's fine, but per-API mandates aren't going to help that goal.

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

If it's controversial, then it belongs there even less.  If vendors
disagree, they're just going to ignore it; if they agree, they'll do it
anyway.  Each individual spec demanding specific un-prefixing policies is
just going to be a bunch of noisy handwaving that everyone will ignore.

That text is also poor practice: it doesn't give a transitional period.  A
more reasonable, real-world policy is to remove the prefix after it's been
present un-prefixed for at least one production cycle, so people have a
chance to test their API selection code with the un-prefixed name, before
their code actually depends on it.  (It also doesn't acknowledge the
existance of production cycles; *immediately* removing an API would imply
remotely removing it from deployed browsers, which surely nobody will ever
do.)

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


More information about the public_webgl mailing list