I think the WebGL extension registry should document all extensions,
even those which might not be intended for a standards track. It's not
a burden to write a little documentation for new extensions, and gives
other implementers the opportunity to provide some compatibility. It's
also not a big burden to leave an extension in draft status for some
time while its utility is being proven.
There was a long discussion about vendor prefixes for WebGL extensions
some time ago, with the conclusion that draft extensions should
preferably be exposed behind some sort of run-time flag, not enabled
by default, and also not use vendor prefixes. I've updated the
extension registry in https://github.com/KhronosGroup/WebGL/pull/861
to indicate this.
On Wed, Feb 11, 2015 at 7:50 AM, Florian Bösch <firstname.lastname@example.org> wrote:
> On Wed, Feb 11, 2015 at 3:08 AM, Frank Olivier <Frank.Olivier@microsoft.com>
>> I agree with you that it would be useful to allow for a vendor to
>> implement an extension not intended for any kind of standards process at
>> that time as long as they properly prefix it. I believe such a mechanism
>> would be useful especially in HTML runtime environments that is *not* the
>> open web. (Silly example: A browser might expose some prefixed WebGL
>> extension (exposed to the browser add-on runtime environment only) that
>> allows the add-on developer to render 3D graphics into the browser frame.)
> In traditional GL the vendor prefix usually serves this function. However in
> WebGL we've already used the vendor prefix slightly differently (for draft
> extensions on track to be standardized).
> I'd suggest tacking on an additional prefix for extensions a vendor does not
> wish to standardize at that time, something like:
> Would this be a satisfactory convention for everybody?