[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.
We never, neither in theory nor in practice, offered any stability guarantee on draft extensions. For example, we changed WEBGL_lose_context semantics a couple times.
I don't agree with the statement that my change "removes any possible benefit of prefixing in the first place": the prefixing is still what makes new draft extensions usable before all vendors have agreed on their behavior.
The idea is that during the lifetime of a draft extension, there is an evolution: at the beginning there may be significant differences between various vendors, but they should gradually be removed and eventually all vendors should align on the same behavior. Then it's time to move to official status.
It seems that you're concerned about what would happen if a draft extension moved to official status before there is consensus among all vendors on what its behavior should be; but I don't see that happening, as consensus seems a prerequisite for moving an extension to official status.
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.
No, I'm not much interested in avoiding breaking too much content that relies on draft extensions.
What I am interested in, is carefully avoiding providing means for content to target a specific vendor, in a way that other vendors are never allowed to support. Other vendors are not allowed to use one vendor's prefix, that is why prefixes must be used so carefully.
To say it differently:
Prefixes are monopolies granted to a vendor on a part pf the API. That is why we must prevent them from becoming too permanent.
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.
Then we need to work on avoiding to let draft extensions from becoming too popular while they're still drafts.
That could mean: watch out carefully for any draft extension that's getting popular, and try to move it to official status as soon as possible before it is too popular.
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.