[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 8:04 PM, Benoit Jacob <email@example.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.
Again, this is not a spec thing, it's something that was agreed on on this mailing list and that we agreed to record, alongside existing rules, in the extension registry. Already before my change, this WebGL WG already had at least 2 hard rules around vendor prefixes:
1. No vendor may start implementing an extension proposal before it's moved to draft status (that is mentioned in the extension registry. Was added as a result of discussion in this thread).
2. That one vendor may not use another vendor's prefix (that is not explicitly said in the extension registry but was discussed on this list about the WEBGL_lose_context extension. Side note: should we add a mention of it in the registry?)
How is my change different in nature from these existing rules?
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.
We already agreed on that on this mailing list, on Feb 27, in this thread, and had agreed to add that rule in the extension registry. Why not record such decisions in a place where they're easy to find, such as the extension registry?
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.)
I sure am open to discussing/modifying the specific phrasing. What I meant was removing it from the development version of browsers. Obviously we can't do more than that. By "immediately" I meant "at their earliest convenience, not delaying it for any reason (compatibility or other)".
I am not in favor of a transitional period because that is a slippery slope and it's easier to hammer the point that draft extensions can be renamed or modified or removed at any time, and apps that want to not be broken should consider: a) testing for the unprefixed extension; b) where possible, offering a graceful fallback if the extension is not available.