On Wed, May 7, 2014 at 3:46 AM, Vladimir Vukicevic <vladim...@gmail.com> wrote: > FWIW, the reason you have to explicitly enable extensions is that we didn't > want content that "accidentally works". In contrast with regular OpenGL, > where every extension is always enabled and the query just tells you what is > available, WebGL requires explicit author action to enable an extension. > This has been a big boon to WebGL compatibility.
How do we know that if we have not seen the alternative? Every other API on the web works the other way. We expose what we support and what we support changes over time. E.g. what XMLHttpRequest's send() method supports evolves over time. > Defining every feature of WebGL 2 as an extension would result in a huge > amount of busy work It could just be a single "extension" as bz suggested earlier in the thread. > WebGL is already following the OpenGL path. Trying to make it more "webby" > by trying to mush the APIs together isn't doing the web a favor since the API > is already more OpenGL-like, isn't doing developers a favor since they now > have to have this pile of getExtension() code around, and is definitely not > doing us a favor, because we have to support the explosion of all combo of > extensions. Again, this seems like a false comparison. No need for an explosion of extensions. Furthermore, what you're advocating will give us an enormous API surface area long term, which we'll have to maintain and test, even though most new content will not use it (they'll get the newer classes). -- http://annevankesteren.nl/ _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
