This content is part of the Essential Guide: Guide to mobile 2015: What is new?

Rise to the challenges in using HTML5 for mobile apps

Developers and architects should know the benefits and limitations of HTML5 for mobile apps. Starting with this tip could be a good first step.

When HTML5 came along, many developers and application architects saw it as an opportunity to create platform-independent applications, simplify bring your own device support and reduce problems with applications that occur when new mobile device OS versions are released. Certainly HTML5 is a step in the right direction, but it's not there yet. Some attention to detail is essential if any of these goals are to be met. Designers should be aware of the benefits and limitations of HTML5 for mobile apps, proactively track the state of feature support across platforms and design applications to minimize the need for customization.

HTML5 brings a much more structured approach to interactivity than previous versions of HTML had, including explicit support for API definition and significantly improved handling of JavaScript integration in field processing. It also provides improved content coding, which may be of less interest to businesses than to game developers who employ video regularly. Overall, most developers think of HTML5 as a more structured approach to managing thin-client experiences, so much so that thin clients can approach custom apps. Because HTML5 is more platform-independent than app development languages in general, that can be a benefit where many different devices are supported.

The qualifier can is significant here, because many developers say HTML5 is not fully mature. It's not surprising that some webpages render correctly in one browser but not in another; that's been true for years with previous versions of HTML. However, HTML5 hiccups are more frequent. Google, for example, for a time could not deliver HTML5 audio correctly for YouTube videos in the Chrome browser. It's difficult to find a central point where differences and difficulties are maintained for developer review, so organizing the approach is important. Developers also say that HTML5 development is a curious blend of webpage design and programming and that best practices lead them toward Web design while application assurance needs pull them toward programming.

Remember that HTML5 for mobile apps is HTML, not JavaScript or another Web language. Unless a developer has a lot of direct HTML5 development experience, it's probably smart to think of HTML5 in HTML4 terms: as an evolution to Web 2.0 concepts that were often added on via extra tools. HTML5 does not handle these extensions in the same way; it does what's "logical" in HTML terms. So, a good starting point for HTML5 design is to think in terms of forms and fields and think of HTML5 as a means of adding processing flexibility and integration to form processes. Because most enterprise architects and developers planning mobile apps are likely thinking in forms-compatible ways, that's not a difficult accommodation.

HTML5 for mobile apps

A more difficult accommodation is to think linearly in terms of integrating processing and fields. Developers often want to group script and process integration into a block, but separating field-oriented processes in forms can create timing issues that will lead to incorrect results with some browsers. Instead, it's best to think of fields and field processes as a group. That means placing scripts, when they're used, with the pages that use them.

Even careful planning of applications and tuning of practices won't always resolve problems with browser compatibility, especially for developers using complex forms and doing back-end process integration with tools like HTML5's API definitions. HTML5 for mobile apps, at least for now, may actually require more careful attention to application lifecycle management (ALM) than standard applications. First, most users expect to be able to change webpages more often, so there are more opportunities to introduce problems. Second, browsers change more often than mobile device OS versions. Often it's difficult to know just when such changes have occurred. System administrators can get information on browser updates from the vendors, and it's smart to review these updates and to trigger an application test and validation cycle when any change to HTML5 rendering is noted.

Users have often reported that it's easier to sustain HTML5 development with a complete HTML5 framework toolkit than if you attempt to pull together elements of a development process on your own. Aptana is a popular choice for general HTML5 work, and Microsoft's Visual Studio is popular for ASP.NET applications. Whatever tools developers pick, they should expect to install development extensions for browsers where available to help them through compatibility problems.

The concern of overall HTML5 design is the final consideration for effective development. Users have found a few general tips to be valuable. First, try to use CSS3 in place of JavaScript for forms-level interactivity everywhere possible. Make scripting the exception, and consider using it primarily to interface with back-end applications. Second, explicitly style every element, not just ones that need it at the moment. A lot of problems develop from failing to properly style elements whose usage has evolved. Finally, separate style sheets from pages rather than embedding styles. This can also facilitate "style-less" reading, should a mobile browser not support styles properly.

HTML5 for mobile apps has special considerations. First, memory and performance limitations on mobile devices can have a major impact on complex HTML5 applications. Developers and architects may have to consider page flow and design carefully to keep an application within the constraints of mobile devices. However, if memory isn't a factor, client-side databases that replace remote HTML access can improve performance. Second, beware of embedded objects, scripts and tables -- these are not consistently implemented in mobile browsers. Third, try to use cloud storage instead of cookies; there may be problems with saving cookies on mobile devices, and user settings can impact the applications. Fourth, avoid third-party plug-ins because they may make the implementation brittle.

Developers can do much more with HTML5 without relying on scripts and sprites, and they should. But for now at least, HTML5's flexibility makes webpages more like applications than forms, and users should seriously consider a formal ALM discipline to ensure their mobile HTML5 apps run consistently as devices, browsers and user needs evolve.

Next Steps

How to create responsive design with HTML5, CSS and JavaScript

Take this quiz on HTML5

Company sought out platform for HTML5 Web apps

Dig Deeper on Mobile app development