[Public WebGL] proposal draft for EXT_texture_filter_anisotropic

James Robinson [email protected]
Sun Apr 1 20:55:02 PDT 2012


On Sun, Apr 1, 2012 at 5:21 PM, Benoit Jacob <[email protected]> wrote:

>
>
> ------------------------------
>
> On Sun, Apr 1, 2012 at 6:48 PM, Benoit Jacob <[email protected]> wrote:
>
>>  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.

- James
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://khronos.org/pipermail/public_webgl_khronos.org/attachments/20120401/cf2f734b/attachment.html>


More information about the public_webgl mailing list