[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Public WebGL] WEBKIT_ extensions



On Thu, Nov 17, 2011 at 10:25 PM, Mark Callow <callow_mark@hicorp.co.jp> wrote:
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 ARB|OES.

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 theirs.

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.

(Agreed with Chris's points.)

--
Glenn Maynard