I disagree with several points of this email.
On Tue, May 6, 2014 at 2:18 PM, Benoit Jacob <jacob.benoi...@gmail.com> wrote:
> So, thinking more about this, here's what I think is the deeper concern
> here.
>
> If we make a feature available, we have to expect that people will write
> code assuming support for it. We can't honestly believe that all Web
> developers write careful feature checks for all the features they depend on.
I agree that not everyone will properly check that a feature is
available before using it. But I don't think that's much different
from people that simply use a feature wrong. I.e. it's a bug. It's
going to result in some users having a broken experience.
There are exceptions, such as developers simply not caring about some
set of users. Like when developing for a corporate website (we
probably don't care much if ServiceNow breaks in IE7-9). But I'd still
call these bugs, just ones that are low priority enough that they
won't get fixed.
> What is keeping compatibility problems tractable with other Web APIs, in
> presence of code that doesn't do careful feature checks, is probably that
> support for most Web APIs depends only on the browser and browser version.
This is something we're working hard to get away from as it's
something that has caused a lot of trouble on the web. I.e. websites
checking what browser or browser version you have, and then making
assumptions about what that browser can or can't do.
There's been a strong movement lately towards "test for features, not
for browsers". This is a good change for the web.
> That's where WebGL is different: support for WebGL features also depends on
> hardware details.
WebGL is not unique in this. The vibration API and the
DeviceOrientation events are two other examples of this. In FirefoxOS
we have a whole host more.
For each of these APIs we always design the API such that a page can
check if the API is available, so that it can fall back to something
else if the API is not available.
> That's why if we just expose different features on the object returned by
> getContext("webgl") depending on client hardware details, we will create a
> compatibility mess, unlike other Web APIs.
The main probably that you have is that you haven't designed the API
as to allow authors to test if the API is available.
If you had, this discussion would be moot.
But since you haven't, you're now stuck having to find some other way
of detecting if these features are implemented or not.
What you are proposing is that people use
canvas.getContext("webgl2") != null
What Anne is requesting is that we use
canvas.getContext("webgl").someAPI != undefined
I don't really care super strongly. At least as long as we don't make
webgl2 behave any differently from webgl1 for any of the features that
are in webgl1. Doing that would be an author nightmare as we move into
the future with more versions. As long as the two behave the same it's
not really "modes" the same way that "CSS quirks mode" and "JS use
strict" is.
But the bigger problem that you'll have with both of the above two
tests is that you are forced to wait with shipping any part of webgl2
until the whole thing has been implemented.
This will mean delaying deployment of any "low hanging fruit" in
webgl2. Or even any "second highest hanging fruit".
Being that strict is going to be even harder for the last browser to
implement webgl2 as now all competitors are shipping cool stuff and
you can't ship anything since there's that one missing feature X still
not implemented. And IE's update cycle is *really* slow, so when
microsoft decides to go ahead and ship a partial implementation of
webgl2 now developers don't have any way to test for webgl2 features
at all.
/ Jonas
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
