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.
Table Of Contents
- Defining HTML5
- HTML5 Applications
- Rendering Control
- Better Programming Model
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 <canvas> 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.
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 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.
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 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.
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.
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 <audio> and <video>, developers can drop multimedia content into an HTML page just like an image, and users should no longer be inconvenienced by required updates for the likes of Flash Player, QuickTime, and Silverlight. Anything inside these tags should simply run, as long as the system provides the appropriate codec support at the native code level (Fig. 3).
Unfortunately, HTML5 video specifications are not as far along as audio. The W3C has specified elements and attributes. (See its entertaining demo with the Big Buck Bunny movie.) 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.
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.
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.
As long as the browser conforms to the HTML5 standard, inside the area specified by the <canvas> 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 <canvas> 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.
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 <iframe> element now has a sandbox attribute that controls content permissions. Settings allow the frame content a range of permissions, from only display content to do everything the containing document is allowed to do, including executing scripts and submitting forms. The default is the most restrictive and safest: display only.
So, an HTML5 HMI can bring together onto a single display page, say, a map, navigation instructions, the weather report, points of interest, and even content provided by the point of interest. With the external, unverified content restricted to a sandbox, there is little concern about malicious content.
Despite the large number of new and very useful features it introduces, arguably the most important change with HTML5 is not part of the specification, but the way that the development community is reacting to application development using HTML5. Since HTML5 is becoming a more popular choice for application development outside of traditional Web browsers, the tendency to keep application logic and display styles out of the DOM is becoming increasingly popular, bringing over the heavily used MVC—Model, View, Controller—design pattern into the HTML world.
Like earlier editions of HTML, HTML5 is inspired by SGML and has inherited some of its syntactic features. For example, it maintains the <!doctype> element. However, HTML5 no longer refers to an SGML Document Type Definition (DTD), and it incorporates into its own syntax new elements (<section>, <header>, <article>, <aside>, <time>, etc.) that, like SGML elements, define the content type rather than its presentation, which is left to the CSS.
Anyone who has tried to mark up documents using <div> tags will appreciate the change. HTML5 is not attempting to replace SGML or XML for document content management. Rather, by adding a limited set of elements identifying content type, it simplifies page markup and content manipulation.
Document Object Models are a mechanism HTML5 offers for controlling the HMI by controlling not the specific page but how it is defined. The best definition of the DOM comes from the W3C itself:
“The Document Object Model is a platform- and language-neutral interface that will allow programs and scripts to dynamically access and update the content, structure and style of documents. The document can be further processed and the results of that processing can be incorporated back into the presented page.”
The HTML5 improvements allow much easier and consistent manipulation of the DOM. This means that application code becomes simpler to write and identical across multiple platforms.
Cascading Style Sheets have been part of HTML design for a long time. With HTML5 they are confirmed as the primary method for defining how the HTML page is displayed. The HTML determines what is displayed, and the style sheets determine how it is displayed.
As long as the devices have appropriate style sheets, applications can be designed once and move easily between devices. The style sheets ensure that applications display correctly on each device, even branding them, or filtering out content such as animations or other distractions when the application moves, say, to an in-vehicle system in which driver distraction is a consideration (Fig. 4).
None of this is entirely new to CSS3. However, CSS3 adds, literally, another dimension to cascading style sheets: time. It introduces new, dynamic capabilities, such as 2D and 3D transforms, and transitions, which cause an object to gradually change from one style to another. In keeping with the HTML5 philosophy of keeping the details of how something should be displayed separate from the actual content, these styles permit generalized manipulations, rather than requiring special code for each instance.
Unfortunately, to date, not all browsers support all the CSS animation styles, and those that do support them require slightly different code in the style; for example, a prefix in front of the transition style: -moz-transition, -webkit-transition, etc.
Taking off in 2011, HTML5 adoption has surpassed expectations. HTML5 is rapidly becoming not just a standard but the standard not just for Web pages but for all types of rich user interfaces. Offering simplicity of use in a familiar environment and capabilities previously supported by disparate and incompatible, proprietary technologies, HTML5 appears to be delivering on its promise.
- HTML5 Rocks; detailed (but usually comprehensible to non-developers) information about HTML5 and how to use it
- Web SQL Database: W3C Working Group Note 18 November 2010; W3C ceased development of and support for the Web SQL Database specification in November 2010
- “Web Audio API: W3C Editor’s Draft”, W3C, 2012
- “HTML5 Video Events and API”, W3C
- “HTML Speech Incubator Group Final Report”, W3C, December 6, 2011
- “Dive into HTML5”, Mark Pilgrim; clear how-to information, with a charming Web page design to boot
- “HTML 5 Reference: A Web Developer’s Guide to HTML 5, W3C Editor’s Draft”, W3C, March 23, 2009
- “Document Object Model (DOM)”, W3C Architecture Domain