[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 6:48 PM, Benoit Jacob <email@example.com>
Here is the sentence that I added:
"When a draft extension moves to official status, any existing implementation should immediately remove support for the vendor-prefixed extension name."
This is incorrect. Immediately removing the prefix would break all existing content that depends on it.
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.
Web developers can start checking for the un-prefixed extension name before the extension moves to official status, to avoid effective breakage.
Vendor prefixes should be left in place, as an alias for the non-prefixed one; if existing content using the prefix goes away (which may or may not ever happen), then the prefixed name can be removed. Nothing at all is gained by removing vendor prefixes for things like interface names and extensions, so there's no hurry to remove them.
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.