2014-05-06 18:41 GMT-04:00 Jonas Sicking <jo...@sicking.cc>:
> 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.
>
Sure! I'm not disputing that.
All I'm saying is people will forget to feature-check things that just work
for them.
> > 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.
Indeed! But if we make WebGL2 features automatically available on
getContext("webgl"), then we're not getting away from it. People will rely
on it as it works for them locally.
> 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.
>
Agree! And we're not discussing changing that here.
>
> > 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.
>
That's why I didn't say it's unique in this. Just different from the
majority of Web APIs that have seen an increase of their feature set over
time.
>
> 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.
>
Likewise with WebGL. WebGL has a core feature set, and the rest are
extensions, that can be queried like you describe.
It just happens that we have a bulk of new features coming from OpenGL ES
3.0, that
1) have complex inter-dependencies
2) are available all at once on current/new hardware
So we're thinking that it makes sense to just offer them all at once as
"WebGL2". The alternative that was discussed above would be to offer them
as separate WebGL 1 extensions. That would require a lot of spec and
conformance-testing work, because of the interactions between these
features. That work wouldn't benefit many people in the long term, because:
1) The WebGL 2 features that are the most anticipated and that can run on
the most non-OpenGL-ES-3.0 devices, are already available as WebGL 1
extensions (EXT_draw_buffers, OES_texture_float...).
2) The other WebGL 2 features tend to be available on devices that support
OpenGL ES 3.0 fully.
So the target audience for using many more of WebGL2's features as
individual extensions to WebGL 1, is small. If a particular extension comes
up that has a compelling case for being exposed to WebGL 1, we can
definitely consider it.
It just seems that consistently slicing all of WebGL2's feature set into
WebGL 1 extensions would not be worth the effort.
>
> > 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
>
That's exactly
canvas.getContext("webgl").getExtension("someAPI") != null
That's what we've discussed earlier in this thread, that I explained was
considered not worth the nontrivial spec work and conformance testing work,
due to nontrivial interaction between these features.
>
> 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.
There is no question of doing that.
> 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.
>
Indeed.
>
> 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.
>
That's not considered a problem. It's not a huge project. Last summer we
had an (excellent) intern implement a decent portion of it.
>
> 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.
I don't see how the task is going to be any harder for the last browser
implementing WebGL 2, given that the WebGL 2 feature set will not evolve
significantly, just like the WebGL 1 feature set hasn't since 1.0 in 2011.
Added functionality goes into extensions, not in the core spec.
Benoit
> 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
