On 2014-05-06, 1:21 PM, Benoit Jacob wrote:
2014-05-06 13:07 GMT-04:00 Boris Zbarsky <bzbar...@mit.edu>:
On 5/6/14, 12:53 PM, Benoit Jacob wrote:
Ah, I see the confusion now. So the first reason why what you're
suggesting
wouldn't work for WebGL is that WebGL extension my add functionality
without changing any IDL at all.
Sure, but we're not talking about arbitrary WebGL extensions. We're
talking about specifically the set of things we want to expose in WebGL2,
which do include new methods.
In particular, the contract would be that if any of the new methods are
supported, then FLOAT texture upload is also supported.
The fact that these may be extensions under the hood doesn't seem really
relevant, as long as the contract is that the support is all-or-nothing.
Our last emails crossed, obviously :)
My point is it would be a clunky API if, in order to test for feature X
that does not affect the DOM interface, one had to test for another
unrelated feature Y.
I think if the spec/implementation guarantees that these features are
all either supported or unsupported, that won't be too much of an issue
(and it's actually the exact same situation with a different context
name, we'll assume that if that context is constructed successfully, all
of these methods and extensions are available.)
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
