Everything you wanted to know about HTML5 in the car, Part I

My HTML5 webinar generated a lot of interesting dialog about what HTML5 means for in-vehicle systems. People asked questions about everything from security and performance to WebGL and cross-platform execution. Many of the same questions come up with when I speak with customers and analysts, which got me to thinking: Why not address them in this blog?

So without further ado, here is the first of my "FAQs" on HTML5 in the car. If you have a question and you don’t see it answered here, leave a comment and let me know! I’ll try my best to answer it in a future post.

How can you create multiple in-vehicle user interfaces using a single HTML5 code base?
The key to achieving this is the Cascading Style Sheets language, or CSS.

CSS controls the look and feel of web pages, but it can also be used to control the look and feel of a vehicle head unit. By changing a single CSS file, you can, for example, change all the fonts and background colors in a website (or head unit) from Arial and white to Verdana and black.

Mind you, CSS does much more than that. It also lets you specify how individual tags in HTML documents are displayed: layout, margins, sizes, colors, behavioral characteristics, events, and so on. Consider, for example, a phone app accessed through the vehicle head unit. If that app provides an HTML5-based user interface, each OEM could provide a default CSS that controls how the app looks on the head unit, adapting the app to meet in-vehicle usability standards and, of course, branding it.

A sample app from the QNX CAR 2 application
platform, created with HTML5

Let’s say your phone has an HTML5 navigation app that you want to run in your Audi today and your Chevy tomorrow. Although the phone serves up the app content identically in both cases, the Audi system can use a CSS to ensure that the app looks ‘Audi-like’, with that distinctive black and silver coloring, and the Chevy system can use a CSS that gives it the app the look-and-feel of OnStar. In effect, CSS can give the OEM more control over brought-in applications than other types of ‘screen replication’ technologies, like MirrorLink or iPod Out.

Keep in mind, though, that CSS can’t solve different OEM input philosophies, such as touch, hardkey, softkey and so on. You could use CSS to change the appearance for different inputs, but you would still need to have JavaScript hooking things up underneath.

You mentioned that cross-platform execution is a key benefit of HTML5. Do you have any recommendations on how to implement it?
Cross-platform execution is definitely something you want to keep in mind when designing software for vehicle head units. If you’re careful to ensure your app avoids features specific to the embedded environment, you can use mobile and embedded apps with the same HTML5 code base. It shouldn’t be difficult to make sure your app runs in both environments, but it’s better to plan for this going into design. That way, you can avoid using anything that prohibits cross-platform execution.

Could HTML5 replace the current HMI systems in head units that support multiple applications, and still be event driven and asynchronous in nature?
Definitely. JavaScript in HTML5 supports the concept of separate threads, called workers, that can handle events asynchronously. Although workers have some restrictions, such as the inability to modify the Document Object Model (DOM) or access globals, they should still be able to handle most asynchronous events. Maximum flexibility may require additional support from the HTML5 engine. To that end, QNX Software Systems has invested a lot of time in improving WebKit to allow code to run in separate engine web views, in different threads, in different processes, and even in completely independent HTML5 engine instances.

Stay tuned for Part II, where I plan to tackle questions on web browsers, web servers, and instrument clusters.