[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 5:21 PM, Benoit Jacob <email@example.com>
On Sun, Apr 1, 2012 at 6:48 PM, Benoit Jacob <firstname.lastname@example.org>
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.
That removes any possible benefit of prefixing in the first place, since it means authors will create content that depends on the un-prefixed behavior while the extension is still in a draft. At that point the only way to remain compatible with that content is to leave the draft in place or to implement the un-prefixed version to exactly match the draft's behavior. This means that if the proposed behavior is implemented by all vendors, then moving an extension from draft to non-draft will break poorly-authored content and well-authored content will have the practical effect of locking everybody in to the exact draft extension behavior from the get-go.
It sounds like what you want is a way to signal an extension as being not fully supported so that vendors can remove it without breaking too much content. If an extension does become popular and a significant amount of content depends on it, then I doubt a vendor would choose to drop support for it and break that content for their users no matter what the registry says. On the flip side, if a draft extension does not become popular then I'm sure a vendor would have no trouble removing it. In neither case does the draft-or-not-draft status of the extension matter, so I do not see much value in attempting to make a distinction in the name.
I think the group's attention would be better spent in attempting to educate authors as to what level of support various extensions will receive and not ask them to jump through useless prefixing hoops. Pick an extension name and either commit to supporting it or avoid exposing it to the general user population until it is ready. Adding a prefix doesn't provide any additional flexibility, it just adds overhead.