On Thu, May 8, 2014 at 1:40 PM, Ehsan Akhgari <ehsan.akhg...@gmail.com> wrote: > On 2014-05-08, 8:55 AM, Anne van Kesteren wrote: >> >> On Thu, May 8, 2014 at 12:56 PM, Benoit Jacob <jacob.benoi...@gmail.com> >> wrote: >>> >>> WebGL is low-level and generalistic enough that it is not specifically a >>> "3d" graphics API. I prefer to call it a low-level or generalistic >>> graphics >>> API. >> >> >> Fair, forgot about that argument. "webgles" or some such might be >> better then. Or enshrine "webgl2" forever, but that seems rather >> weird. > > > One issue which we discussed at the meeting yesterday is how we should > handle the fact that a version dictionary member would be optional anyway, > and what the default should be. I think it would be very hard to pick a > sane default when that is not passed in because of the goal of preventing > content accidentally working, so I think we might need to end up with > "webgl" + N forever... :/ Which is not great, but if this ends up being > the only bad part of the solution, I think I would be happy with it.
Based on what has been discussed in this thread so far, specifically that: * We expect that UAs and hardware will make these features available in "chunks" rather than "a feature here and a feature there". * We want devs to opt in to getting access to new features so that they don't accidentally depend on a particular "chunk". (FWIW, this sounds like an awesome thing to me given the hardware dependency here). * We expect each new version of WebGL to be fully backwards compatible. I don't see any particular problems with the createContext("webgl"/"webgl2"/"webgl3") approach. A well written page will detect what level is supported and fall back to older versions as needed. A poorly written page will just do createContext("webgl2") and not fall back to webgl1. Whatever we do we can't get such a page to run properly on a device which doesn't support webgl2, no matter what syntax we use. A really poorly written page might do createContext("webgl2") and then only use the webgl1 feature set. Given the constraint that we want people to opt-in to additional functionality over the base webgl1 profile, there's always a risk that people will attempt to opt in to more than they need and then refuse to work when those opt-ins fail. What bad code patterns is it that people are worried that this proposal will lead to? The only thing that I could see which in some sense leads to a materially simpler API is to simply do createContext("webgl") and ask developers to do feature detection on the returned context. However that abandons the opt-in design which I think would be worse. No matter what, I think the situation here is dramatically different from CSS quirks mode and JS "use strict". In both those situations there are backwards incompatible modes. That does not appear to be the case here. / Jonas _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform