Mozilla Standards Blog

Last year, some prominent web developers weighed in on an increasingly spirited discussion about the App Store model versus The Web. Discussion about how to build really compelling mobile web applications that work on multiple mobile web browsers continues. But questions of market economics aside, some important technical questions crop up: is the web as an application platform capable of all the things we expect from a good platform? How do web pages integrate with the devices that they run on, and how can even more APIs be coined? And of course, the perennial: can the web platform (and web applications) replace the use of native code?

Let us define our terms. We already know that many of the really interesting native applications in the mobile space (written, for example, in Objective C) make use of web technologies, either using established web APIs from third-party providers (making use of HTTP and JSON or markup payloads) or using HTML and CSS for presentation. This is also true for applications on the desktop. For example, the iTunes Music Store uses a browser-based presentation layer. We are not talking about that kind of use of web technologies here. We are also not talking about widgets of any kind here. Those are web-like veneers, but not quite The Web as we have in browsers, with the same security considerations of an HTML page served up from a URL. What we are talking about here is web pages in a web browser. Are we safely evolving capabilities that these need, so that future applications can safely take advantage of these capabilities? Let’s take a look at a few of these capabilities, and how they fit in with the web page.

Read the rest of this entry »

(cross-posted from hacks.mozilla.org)

Even without a draft specification of WebGL in circulation, we’ve seen some promising 3D content using WebGL appear on the web, put together mainly through developer ingenuity and the fact that Firefox, Chromium, and WebKit are open source projects with early support for the technology. Today, the WebGL Working Group at Khronos released a provisional public draft of the WebGL specification, and we are very excited for what this means for the web.

For one thing, it means more developers can get involved in the evolution of WebGL. There’s a public mailing list set up, so that you can engage directly with members of the WebGL Working Group, as well as a web forum. It’s important to note that the specification is not yet finalized. Participation from the web community is essential towards finalizing the specification, which we hope to do in the first quarter of 2010.

It also means that there are implementations of the draft specification that you can begin to test. You can obtain a Firefox nightly that implements the WebGL draft specification, and can turn on WebGL support in that build by following these steps:

• Type “about:config” in your browser’s URL bar
• Do a search for “webgl” in the Filter field
• Double-click the “enabled_for_all_sites” preference to change it to “true”

Other browsers that support the draft WebGL specification are listed on the WebGL Wiki.

Now of course, this is hardware-accelerated 3D graphics in an early beta, and for now requires an OpenGL 2.0-capable GPU and drivers. In particular, most flavors of Intel’s integrated GPUs will not work straight out of the box (such as the GMA900/GMA950 often found in laptops). Developers who build nightly builds of the browser can induce software rendering using Mesa, and should check out Vlad’s blog post for doing this on Windows. Caveat emptor: building software rendering using Mesa into a Firefox nightly is likely to yield slower performance, and is only for the intrepid.

WebGL is a royalty-free, cross-platform API that brings OpenGL ES 2.0 to the web as a 3D drawing context within HTML5′s Canvas element, exposed as low-level interfaces within the Document Object Model.

Developers familiar with the Canvas 2D context will recognize that WebGL as another context for Canvas:

// get the canvas element in the DOM
var canvas = document.getElementById("canvas3D");
var gl = canvas.getContext("experimental-webgl");

Note that till the specification is finalized, the context is called experimental-webgl.

WebGL uses the OpenGL shading language, GLSL ES, and can be cleanly combined with other web content that is layered on top or underneath the 3D content. It is an emerging web standard, and is designed to be used with other parts of the web platform. The release of the draft specification is one step in bringing about a plugin free 3D API to the web, usable straight out of the box. People have already begun using it to create compelling libraries. Check out X3DOM, which is a JavaScript library using WebGL that allows users to author content in X3D. We expect developer ingenuity to surprise and awe us, as it always has.

References

• Review the WebGL draft specification
• Get involved! WebGL Homepage on Khronos
• Read articles and contribute on the WebGL Wiki
• A blog about learning WebGL
• Find 3D recipes in the learning WebGL Cookbook

Yesterday at the Game Developers Conference in San Francisco, Mozilla and the Khronos Group (the folks behind the OpenGL family of standards) announced a new initiative to bring accelerated 3D graphics to the web. This is a promising new direction for web applications, and adds to the rich mix of activities in forum such as the W3C and WHATWG to evolve the web platform.

JavaScript performance in all major browsers has shown marked improvements over time, paving the way for it to be used for more sophisticated classes of applications. Many graphics applications, including popular games, leverage hardware acceleration, and subsets of OpenGL (such as OpenGL ES1.1) are already available on smartphones. The initial activity proposal is to consider a simple binding of OpenGL ES2.0 to JavaScript, and exposing that to an HTML5 Canvas context. This is how a 2D drawing context is exposed to the web for use with a JavaScript API; the proposed mechanism is to do this for a 3D context as well. As exciting as this is for the web and for us at Mozilla, it’s worth explaining our choices, and raising some questions.

Read the rest of this entry »