On Thu, Nov 17, 2011 at 10:25 PM, Mark Callow <firstname.lastname@example.org>
That is why in the OpenGL scheme of things there is a progression
from vendor prefixes to EXT to ARB|OES to core specification.
Initially vendors do their own thing. When multiple vendors find
common ground they merge features and come up with a common EXT
specification whose further development is enhanced by the efforts
of all the vendors involved. After that it may be adopted as
That isn't how web APIs are typically developed.Â A vendor may come up with an initial pass on an API on their own, but it's rarely the case that each browser comes up with its own "competing" API on its own and then later try to merge features.Â I don't see any reason this would be different for WebGL extensions; it's just another web API.
And then everyone who is using it (a far larger number than the
number of implementers) needs to write a wrapper so their
application can call the function under a single name regardless of
browser. That is why I hate vendor prefixes unless the thing truly
is single vendor. (Yes, I realize this a weaker argument for WebGL
as only the single call to enable the extension is affected.)
The other issue I have with the way extensions are handled in web
APIs is that I can't tell the level of support for an extension. If
only a single browser vendor is supporting something, I almost
certainly don't want to use it. It multiple vendors support it then
it becomes more interesting. Other than by drowning in whatwg
e-mails how can I tell if some feature is going to be widely
supported and therefore worth my interest? "EXT" serves a useful
purpose for this too.
So I would urge the web API community to consider adopting
OpenGL-like extension naming rather than beating on WebGL to adopt
This isn't arguing that WebGL's needs are different than the rest of the web; it's arguing that you don't like how everyone else does things.
If you think the platform conventions should change, I think that should be taken up with the platform as a whole, eg. on w3c-webapps and similar lists, not by making WebGL an inconsistent outlier.Â (WebGL is already an outlier as an API in too many ways--most unavoidable, of course.)Â WebGL should follow platform conventions.