Understanding HTML5

A brief overview of HTML5 that will be useful to people who are technical enough to understand what we mean by a chromeless browser.

Since the advent of the Internet, the non-initiates who try to understand a new technology often face not too little information, but too much. HTML5 is no exception. If anything, information about HTML5 is over-abundant: the World Wide Web Consortium (W3C) documents themselves, business cases, evangelists’ musings, and seemingly innumerable and ever-more abundant how-to articles and tutorials chock full of code samples.

This article attempts to bridge the gap between the musings and the tutorials and present a brief overview of HTML5 that will be useful to people who are technical enough to understand what we mean by a chromeless browser, but who are not already up to their elbows in HTML5 and looking for, say, a tip on how to optimize a bit of JavaScript for equalizing audio output.

Defining HTML5

We can start by defining what we mean by HTML5. Strictly, HTML5 is the latest, and as yet incomplete, edition of the HTML standard for presenting content. However, in common usage HTML5 usually refers to the HTML5 standard itself (Fig. 1), plus ancillary standards and technologies: CSS3 (Cascading Style Sheets), the JavaScript scripting language and associated standards, such as AJAX (Asynchronous JavaScript And XML) and JSON (JavaScript Object Notation), Document Object Model (DOM), and other non-proprietary standards, including XML. This broader definition of HTML5 interests us here.


1. Strictly speaking, HTML5 refers to the W3C HTML5 standard, but in common usage the term usually includes ancillary technologies such as CSS3 and JavaScript.


Second, we can simplify the discussion by grouping into three areas the bewildering number of new features, capabilities, and improvements HTML5 brings over its predecessors:

  • Applications: HTML5 now supports enough capability to construct applications either inside or outside of a browser, with all the expected capabilities: databases, threading, input from the device hardware, etc.
  • Rendering: Using CSS3 animations, the element, WebGL, and SVG graphics, HTML5 provides control over the human-machine interface (HMI) rendering that is precise enough for games and flexible enough for applications.
  • Improved application development model: The influx of application developers (as opposed to Web page designers) adopting HTML5 to build cross-platform applications is reorienting the HMI development community, which is increasingly following traditional design patterns in its applications, separating the model (HTML/DOM), view (CSS), and controller (JavaScript) in a more maintainable architecture.

Finally, we should note that with these changes, HTML5 reaches beyond the traditional domain of HTML. It is no longer just the standard for presenting Web content, but a viable technology for HMIs for all sorts of applications—connected and not connected, using traditional browsers or chromeless browsers (rendering engines minus all the browser widgets: navigation, history bookmarking, etc.).

HTML5 Applications

HTML5 introduces features that give an HTML page many of the capabilities typically associated with an application. One of the key benefits of these capabilities is that with HTML5, HMI designers don’t need to choose between a downloaded app running on the device and a service hosted in the cloud. They can support both use cases from the same code base.

For example, ideally, an in-vehicle navigation app is always connected, receiving traffic and weather data, updating the vehicle location, and so on. In practice, however, connectivity can’t always be guaranteed. Cars travel outside network coverage areas, down urban canyons, and through tunnels. A hybrid navigation app that stores data locally could continue without a blink in any of these situations, synchronizing its locally stored information with updates when connectivity is re-established.

Local Data Storage

A key requirement for many offline apps is local data storage. With previous versions of HTML, local storage was limited, unreliable, and restrictive: cookies, (small, hence very limited capacity), plug-ins (annoying, often out of date, blocked by firewalls), or custom browser features (which created browser lock-in). HTML5 offers designers Web Storage and IndexedDB.

Web Storage

Web Storage supersedes the old cookies local storage model. It’s faster, since every server request doesn’t require a new data transmission; more secure, since stored data is accessible only to the Web page that stored it; and more useful since data size is not severely limited as it is with cookies.

Web Storage comes in two flavors: Local Storage (data is persistent; it remains on the local device until it is expressly removed) and Session Storage (data is not persistent; it is removed when the browser window with which it is associated is closed). All Web Storage data is stored in key/value pairs.

However, Web Storage does not support indexing, since searches on large amounts of data can hurt performance. It also doesn’t support locking for database transactions. Apps in multiple tabs can overwrite each other’s data, so applications must manage their own database transactions to ensure data integrity.


IndexedDB offers faster searches and transaction locking. It is less complex than Web SQL Database, which W3C dropped, perhaps since neither Microsoft nor Mozilla supported it.

As its name suggests, IndexedDB supports indexing of specified fields, which speeds searches; and locking of the entire database, tables, or individual rows, which ensures data integrity when more than one app accesses the database. IndexedDB requires a bit more knowledge than Web Storage, but applications can do a lot more with the stored data.

We need to keep in mind, though, that IndexedDB is still in the proposal stage and is not yet part of the HTML5 specification, and it isn’t yet fully supported by all browsers. Though Microsoft has rumored that IE10 will support IndexedDB, few details are available about mobile browser support.


According to one Web site designer, threading support is worth pretty much every other improvement in HTML5. Threading is handled with JavaScript improvements, which provide a pseudo-threading implementation with the newly added Web Workers. A Web Worker is “a single JavaScript file loaded and executed in the background.” Web Workers do not have access to all JavaScript features. For example, they can’t access the Document Object Model (DOM) or any global variables or JavaScript functions. Despite these limitations, threading means that complex HTML5 applications can be designed much more naturally.

For instance, HTML5 could be used to write an application running a fuel dispensing pump. The application would have to include functionality such as reading the buyer’s credit card and managing the connection for the transaction, picking up the fuel rate of flow from native code connected to the pump hardware, displaying the amount of fuel dispensed, and so on.

Without threading, this sort of application would be complex and cumbersome—so much so that almost all of the functionality would likely have to be pushed down into underlying C/C++ services. But with JavaScript threading support, most of the user interface can be implemented within the HMI, providing an appropriate level of decoupled development (Fig. 2). 

2. JavaScript Web Workers threading is used at the start of a transaction in fuel-dispensing pump applications. A thread initiates the credit card check, and a second thread handles the fuel selection without waiting for the check to complete. When the credit card check returns, a third thread begins dispensing fuel, and the credit card thread waits for this action to complete so it can transmit the payment amount.



HTML5 establishes non-proprietary specifications that all content-creation tools and browsers are supposed to respect, doing away with most of today’s requirements for plug-ins. With new HTML tags such as

3. This automotive infotainment HMI uses HTML5 and cascading style sheets to present a simple and easy-to-use interface designed specifically for in-vehicle systems.


Though the expectation is that lower-level code such as C or C++ will continue to handle most audio processing, the HTML5 standard allows for JavaScript to perform audio processing and synthesis directly. Giving the top-level developers direct access to audio simplifies HMI development and greatly increases developer efficiency. Performance in JavaScript will never be equal to that in native processing. Yet depending on the platform, audio file, and complexity of the processing, for some use cases it may very well be a viable alternative.

Unfortunately, HTML5 video specifications are not as far along as audio. The W3C has specified elements and attributes. But with various browsers pulling in different directions, no consensus on a standard video codec has yet been reached. The strongest contenders appear to be H.264, Ogg, and WebM, but the debate is still far from over, and everyone seems to have an opinion.

Speech Interface

The HTML5 Speech Incubator Group has proposed a standardized interface that allows JavaScript to talk to an underlying speech engine. This interface supports both speech recognition and synthesized speech output, and it is designed to allow a “Web application author… to add speech to a Web application” using familiar methods.  Thus, assuming that the underlying system supports a speech engine, a designer building an HMI that includes speech recognition and output only needs to know the HTML5 interface.

Device Interaction

In a nod to the migration of HTML implementations onto mobile platforms from smart phones to in-vehicle systems, HTML5 offers application programming interfaces (APIs) that provide access to device information such as orientation and geolocation. This information can be used to adjust HMIs based on screen orientation, and for anything from tracking a taxi through its navigation system to adjusting the time zone on a mobile phone—provided the device has GPS or accelerometer chips, of course.

Rendering Control

One of the advantages of HTML pages and browsers is their forgiving nature. Browsers were originally designed to do their best to display what they’re served and ignore what they don’t understand. If a specified font is missing, the browser substitutes another; if an element or attribute is unknown, it is omitted, and so on.

The downside of this tolerance is that no two browsers display content exactly the same way. This is rarely a significant issue with traditional Web content: text, images, forms, the occasional embedded video or audio. However, it is a serious impediment to using HTML for displays where precision is required.

The location of a ball or brick or whatever being thrown in a video game must be exactly controlled. It can’t be left up to the browser to do its best and place the object more or less where the game designer intended it to go. Similarly, maps must be precise, as must medical imaging such as, say, a 3D rendering of a mammogram.

HTML5 introduces new features that allow HMI designers to do things such as render images and control displays down to the individual pixel, as well as to safely bring together content from different sources. In addition to offering precision, these features can often take advantage of hardware acceleration.


The HTML5 element sets aside one or more screen areas where JavaScript can be used for precise rendering of shapes and images. With this element, no special code is required to detect the browser and serve up the appropriate code for that particular browser flavor and edition, so there are no unpleasant surprises.

As long as the browser conforms to the HTML5 standard, inside the area specified by the height and width attributes, bitmap images render exactly as specified. Hence, in a game for instance, a brick will fall precisely where it is supposed to fall. It will not fall on the left foot if it was supposed to fall on the right foot due to some small difference in browser behaviors.

It is important to note that the element also imposes design demands. If the application output moves to a different device (for example, from a tablet to an in-vehicle infotainment system), the browser will not automatically adjust a display drawn on a canvas to a new aspect ratio. This means that the application developer must consider it and implement it if required.


SVG (Scalable Vector Graphics) offer relatively lightweight 2D graphics rendering. Also, designers now can use JavaScript with WebGL to access OpenGL ES 2.0 rendering to display 3D images. HTML5 and JavaScript, then, can be used to present any sort of image or animation called for by the application.

Sandbox (Nested Browsing)

Composite screens—screens made up of frames from different sources—usually have been something to avoid. Allowing the browser to render content from multiple sources left the door ajar for security breaches. For example, if multiple content sources were permitted, a malicious site could lay a hidden page over a legitimate page and use it to gather banking or medical information.

HTML5 lets HMI developers bring content from different sources onto a single HTML page and, critically, manage permissions for this content. In particular, the