OnQ Blog

HTML5: Friending the Mobile Web

Back in the fall of 2010, we did a post on the value of HTML5 for Web developers -- how it brings standards-based features to the browser and consistency to the Web application environment: HTML5: Back to the Future Fragmentation?

In my opinion, the Web is the most used platform in the world and its reach, far greater than any single operating system. HTML5 is it’s nirvana for developers, the great equalizer. You don’t have to build your cute, social game for separate OSs, build for the Web and you can reach them all. Right?

Not so fast. More than a year and a half after that original 2010 post, HTML5 continues to evolve with drafts of new standards specifications and a plethora of new features, but some of the most fundamental (that developers really need to move from native application development to the Web) are still missing from mobile browsers. A way to lock display-orientation for game developers, access to hardware features available to native apps like cameras and sensors, just to name a few. Not only are they missing, but in the case of the file system API, a multitude of conflicting draft specifications exist within the W3C. The unfortunate result is confusion for both application developers and those of us implementing various browsers on hardware. Which file API should I use in my application? Which file API is supported by my browser?

HTML5 encompasses a wide range of feature specifications, and if a basic set of those features are implemented across ALL browsers, it would be on the road to nirvana for mobile application developers. The problem is that HTML5 doesn’t have a way of forcing browser vendors or mobile device manufacturers to implement features. It’s created a load of draft specifications, but no way of ensuring they get implemented. HTML5 does not have requirements for a basic set of feature enablement. We’re back to the age-old developer problem of fragmentation.

Today, developers write innovative desktop browser-based applications due to the increasing functionality found in the HTML5 family of standards. What mobile developers sorely need from HTML5 is a browser conformance test suite ensuring a certain level of feature support. As with all standards bodies, building consensus on what features constitute a “basic” level of support is a challenge, especially given the differences between desktop and mobile browsers. A basic set of requirements for desktop would likely be excessive for mobile. Also there are mobility centric requirements, such as a location, which aren’t as important in the desktop scenario.

Facebook’s formation of the W3C Core Mobile Web Platform Community Group is a big step in the right direction and I’m very pleased to collaborate with them and the other members at the launch of this the newly created group. The Community Group’s goal is to accelerate the adoption of the Mobile Web as a compelling platform for the development of modern Web applications.

The Community Group will bring developers, device manufacturers, browser vendors, operators and other relevant members of the industry together to agree on core features that developers can depend on, create related conformance test suites and provide use cases, scenarios, and other input related to enabling successful mobile Web application development to W3C (and non-W3C) groups.

Qualcomm Innovation Center, Inc. is excited to support the new Community Group to help further this same growth within mobile devices.

Opinions expressed in the content posted here are the personal opinions of the original authors, and do not necessarily reflect those of Qualcomm Incorporated or its subsidiaries ("Qualcomm"). Qualcomm products mentioned within this post are offered by Qualcomm Technologies, Inc. and/or its subsidiaries. The content is provided for informational purposes only and is not meant to be an endorsement or representation by Qualcomm or any other party. This site may also provide links or references to non-Qualcomm sites and resources. Qualcomm makes no representations, warranties, or other commitments whatsoever about any non-Qualcomm sites or third-party resources that may be referenced, accessible from, or linked to this site.