The WebGL extension registry contains specifications for extensions to the
core WebGL API. Most of these extensions are incorporated
directly from the OpenGL ES
or OpenGL extension registries, and refer to
those extensions for their behavioral definition. Because WebGL extensions are specified as
Web IDL interfaces, each specification also includes the IDL to which each implementation
will comply.
An extension template is available for the submission of
new proposed extensions. New extension proposals should be emailed to the
public WebGL mailing list.
When writing a new extension specification, it is recommended to check out
the public WebGL repository. See the
WebGL wiki page Using
Github to contribute. The extension registry files are located
under extensions/.
Each extension object is fetched from
the WebGLRenderingContextBase by passing
the name of the extension to the getExtension method,
i.e.: context.getExtension("OES_texture_float").
Extensions which are marked as promoted to core or removed in a certain version of the WebGL
API must not be supported in an implementation of that or newer version of the WebGL API.
Naming conventions
WebGL API extensions may derive from many sources, and the naming of each extension reflects
its origin and intent.
ARB, OES and KHR tags should be used for
mirroring functionality from OpenGL ES or OpenGL API extensions approved by the respective
architecture review boards. EXT_ and GPU vendor tags should be used for
mirroring other OpenGL ES or OpenGL API extensions. If only small differences in behavior
compared to OpenGL ES or OpenGL are specified for a given extension, the original tag should
be maintained.
The WEBGL tag should be used for WebGL-specific extensions which are
intended to be compatible with multiple web browsers. It should also be used for extensions
which originated with the OpenGL ES or OpenGL APIs, but whose behavior has been
significantly altered.
Browser vendor specific tags should be used for WebGL-specific extensions that are
intended to run only on a particular browser. It is recommended to avoid such extensions,
and instead specify them with the WEBGL tag.
Extension Development Process
Extensions move through four states during their
development: proposed, draft, community approved, and Khronos
ratified. Every extension should advance to Khronos ratified.
If an extension cannot advance through the extension process it can be rejected.
Proposed extensions are intended for discussion on the public WebGL mailing
list, in order to move to draft status; they should not be implemented, even under
a vendor prefix. If consensus is reached in the community, the extension can be moved
to draft status.
Draft extensions may be implemented under a vendor prefix or behind a run-time
option for experimentation purposes, in order to gain experience with the extension before
finalizing it. Draft extensions should not be exposed by default by WebGL implementations.
Once consensus is reached in the community, the extension can be moved to community
approved status.
Community approved extensions should be implemented without a vendor
prefix. When a draft extension moves to community approved status, any existing
implementation should immediately remove support for any vendor-prefixed extension
name. Once implemented by a vendor, support should not be removed unless there is a serious
issue with the extension, such as a security flaw.
Khronos ratified extensions are those community approved extensions which have
been voted upon by the Khronos Board of Promoters.
Rejected extensions should never be implemented. An extension
enters rejected status because consensus on it could not be reached at
the proposal stage or technical difficulties arise during implementation at
the draft stage.
A community approved extension can only be rejected in extraordinary circumstances.
A Khronos ratified extension cannot be rejected.
Recent Revisions