[Public WebGL] proposal draft for EXT_texture_filter_anisotropic

Florian Bösch [email protected]
Fri Feb 24 02:01:28 PST 2012

On Fri, Feb 24, 2012 at 3:16 AM, Kenneth Russell <[email protected]> wrote:

> Are there any objections to moving this WebGL extension into draft
> state? I don't suspect there would be...
No objection.

> No objections to incorporating a conformance test for it as long as it
> passes without the extension being available

This behavior is implemented by the conformance test. For cross-vendor
support the queried extension would have to be either of
MOZ_EXT_texture_filter_anisotropic, WEBKIT_EXT_texture_filter_anisotropic
or EXT_texture_filter_anisotropic, do you want me to provide a patch to the
conformance test for that?

> and is prefixed with a
> minimum version of 1.0.2.
How do I prefix the test?

 All that's needed to change the state
> is change one keyword in the extension.xml, move it out of the
> "proposals" folder and re-run make.

Should I provide the patch to the specification?

As to the life/implementation of specifications, I'm not entirely clear on
how that works. So I propose the following (arguable) formalization:

Lifecycle of an extension: proposal -> draft -> ratified
Lifecycle of implementations:
- proposal: may implement but with vendor prefix, implementation is subject
to removal again if failing to move on to draft.
- draft: may implement without vendor prefix, implementation is subject to
removal again if failing to move on to ratified.
- ratified: should implement without vendor prefix, implementation may not
be removed again, web-developers can now trust this being supported by

Please help me get this formalized to everybodies satisfaction, so we can
create an extension guide from it.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://khronos.org/pipermail/public_webgl_khronos.org/attachments/20120224/4eb234d7/attachment.html>

More information about the public_webgl mailing list