Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
143023864X_HT5.pdf
Скачиваний:
8
Добавлен:
21.02.2016
Размер:
7.98 Mб
Скачать

C H A P T E R 13

The Future of HTML5

As you have already seen in this book, HTML5 provides powerful programming features. We also discussed the history behind HTML5’s development and HTML5’s new plugin-free paradigm. In this chapter, we will look at where things are going. We will discuss some of the features that are not fully baked yet but hold tremendous promise.

Browser Support for HTML5

Adoption of HTML5 features is accelerating with each new browser update. Several of the features we covered have actually shipped in browsers while we wrote this book. HTML5 development in browsers is undeniably gaining tremendous momentum.

Today, many developers still struggle to develop consistent web applications that work with older browsers. Internet Explorer 6 represents the harshest of the legacy browsers in common use on the Internet today But even IE6 has a limited lifetime, as it becomes harder and harder to procure any operating system that supports it. In time, there will be close to zero users browsing the Web with IE6. More and more users of Internet Explorer are being upgraded to the latest versions. There will always be an oldest browser to contend with, but that bar rises as time passes; at the time of this writing, the market share of Internet Explorer 6 is under 10% and falling. Most users who upgrade go straight to a modern replacement. In time, the lowest common denominator will include HTML5 Video, Canvas, WebSocket, and whatever other features you may have to emulate today to reach a wider audience.

In this book, we covered features that are largely stable and shipping in multiple browsers. There are additional extensions to HTML and APIs currently in earlier stages of development. In this chapter, we will look at some of the upcoming features. Some are in early experimental stages, while others may see eventual standardization and wide availability with only minor changes from their current state.

HTML Evolves

In this section, we’ll explore several exciting features that may appear in browsers in the near future. You probably won’t need to wait until 2022 for these, either. There will probably not be a formalized HTML6; the WHATWG has hinted that future development will simply be referred to as “HTML.” Development will be incremental, with specific features and their specifications evolving individually, rather than as a consolidated effort. Browsers will take up features as they gain consensus, and the upcoming features might even be widely available in browsers well before HTML5 is set in stone. The community responsible for driving the Web forward is committed to evolving the platform to meet the needs of users and developers.

313

CHAPTER 13 THE FUTURE OF HTML5

WebGL

WebGL is an API for 3D graphics on the Web. Historically, several browser vendors including Mozilla, Opera, and Google have worked on separate experimental 3D APIs for JavaScript. Today, WebGL is progressing along a path toward standardization and wide availability across HTML5 browsers. The standardization process is taking place with browser vendors and The Khronos Group, the body responsible for OpenGL, a cross-platform 3D drawing standard created in 1992. OpenGL, currently at specification version 4.0, is widely used in gaming and computer-aided design applications as a counterpart and competitor to Microsoft’s Direct3D.

As you saw in Chapter 2, you get a 2D drawing context from a canvas element by calling getContext("2d") on the element. Unsurprisingly, this leaves the door open for additional types of drawing contexts. WebGL also uses the canvas element, but through a 3D context. Current implementations use experimental vendor prefixes (moz-webgl, webkit-3d, etc.) as the arguments to the getContext() call. In a WebGL-enabled build of Firefox, for example, you can get a 3D context by calling getContext("moz-webgl") on a canvas element. The API of the object returned by such a call to getContext() is different from the 2D canvas equivalent, as this one provides OpenGL bindings instead of drawing operations. Rather than making calls to draw lines and fill shapes, the WebGL version of the canvas context manages textures and vertex buffers.

HTML in Three Dimensions

WebGL, like the rest of HTML5, will be an integral part of the web platform. Because WebGL renders to a canvas element, it is part of the document. You can position and transform 3D canvas elements, just as you can place images or 2D canvases on a page. In fact, you can do anything you can do with any other canvas element, including overlaying text and video and performing animations. Combining other document elements and a 3D canvas will make heads-up displays (HUDs) and mixed 2D and 3D interfaces much simpler to develop when compared to pure 3D display technologies. Imagine taking a 3D scene and using HTML markup to overlay a simple web user interface on it. Quite unlike the nonnative menus and controls found in many OpenGL applications, WebGL software will incorporate nicely styled HTML5 form elements with ease.

The existing network architecture of the Web will also complement WebGL. WebGL applications will be able to fetch resources such as textures and models from URLs. Multiplayer games can communicate with WebSocket. For example, Figure 13-1 shows an example of this in action. Google recently ported the classic 3D game Quake II to the Web using HTML5 WebSocket, Audio, and WebGL, complete with multiplayer competition. Game logic and graphics were implemented in JavaScript, making calls to a WebGL canvas for rendering. Communication to the server to coordinate player movement was achieved using a persistent WebSocket connection.

314

CHAPTER 13 THE FUTURE OF HTML5

Figure 13-1. Quake II

3D Shaders

WebGL is a binding for OpenGL ES 2 in JavaScript, so it uses the programmable graphics pipeline that is standardized in OpenGL, including shaders. Shaders allow highly flexible rendering effects to be applied to a 3D scene, increasing the realism of the display. WebGL shaders are written in GL Shading Language (GLSL). This adds yet another single-purpose language to the web stack. An HTML5 application with WebGL consists of HTML for structure, CSS for style, JavaScript for logic, and GLSL for shaders. Developers can transfer their knowledge of OpenGL shaders to a similar API in a web environment.

WebGL is likely to be a foundational layer for 3D graphics on the Web. Just as JavaScript libraries have abstracted over DOM and provided powerful high-level constructs, there are libraries providing additional functionality on top of WebGL. Libraries are currently under development for scene graphs, 3D file formats such as COLLADA, and complete engines for game development. Figure 13-2 shows Shader Toy—a WebGL shader workbench built by Inigo Quilez that comes with shaders by nine other demoscene artists. This particular screenshot shows Leizex by Rgba. We can expect an explosion of highlevel rendering libraries that bring 3D scene creation power to novice Web programmers in the near future.

315

CHAPTER 13 THE FUTURE OF HTML5

Figure 13-2. Shader Toy is a WebGL shader workbench

Devices

Web applications will need access to multimedia hardware such as webcams, microphones, or attached storage devices. For this, there is already a proposed device element to give web applications access to data streams from attached hardware. Of course, there are serious privacy implications, so not every script will be able to use your webcam at will. We will probably see a UI pattern of prompting for user permission as seen in the Geolocation and Storage APIs when an application requests elevated privileges. The obvious application for webcams is video conferencing, but there are many other amazing possibilities for computer vision in web applications including augmented reality and head tracking.

Audio Data API

Programmable audio APIs will do for <audio> what <canvas> did for <img>. Prior to the canvas tag, images on the Web were largely opaque to scripts. Image creation and manipulation had to occur on the sidelines—namely, on the server. Now, there are tools for creating and manipulating visual media based

316