[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:58 PM, Boris Zbarsky <bzbarsky@mit.edu> 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 <bjacob@mozilla.com> 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