HTML5 is the next major revision of HTML. It’s a really big deal, especially for mobile browsers and on-the-go Web users. If the main features of the latest HTML5 draft specification are present in the final version, HTML5 will standardize many killer use cases for Mobile Web browsing that were previously implemented using proprietary APIs or ad-hoc methodologies.

Killer HTML5 Features for Mobile

HTML5 is great news for the mobile ecosystem. Mobile users get richer Web applications and improved usability. Mobile browsers reclaim the rendering of rich Web content from third-party plug-ins. Mobile developers get testable, cross-platform and standards-based interfaces for content development.

The new features of HTML5 standardize use cases and technologies that are common in smartphone-optimized Mobile Web applications. In today’s Mobile Web of XHTML-MP (pdf) or HTML 4 documents, these killer features are implemented using proprietary device and browser APIs. With HTML5, advanced Web application features are available in all mobile browsers supporting the markup language, using the same standard syntax and displaying the same standard behavior.

Mobile Web applications using HTML5 can natively embed audio and video, incorporate the user’s geographic location and display interactive Flash-like animations on a 2D canvas. Mobile Web applications in HTML5 can also respond to coverage outages by caching external dependencies for offline Web browsing and locally caching data until connectivity is restored.

HTML5’s best features for mobility are location awareness, canvas animation, persistent storage, offline application caching, improvements to the semantic structure of Web documents and native audio and video controls. Let’s look at each of these features in detail.

Location Awareness in HTML5

HTML5’s Geolocation API makes the mobile device’s geographic location available to a Web application. In the past, obtaining device location was only possible using proprietary JavaScript extensions to JavaScript or server-side integration with a mobile operator API. The API allows one-off location queries and repeated location updates by registering callback functions.

Here is an example of the HTML5 geolocation API used to obtain a single update to the user’s position:

function updatePosition(position) {
// Latitude and longitude are available as member variables
var myLatitude = position.coords.latitude;
var myLongitude = position.coords.longitude;
}
// Request the geographic position.
// This method calls back once to the above updatePosition() function.
navigator.geolocation.getCurrentPosition(updatePosition);


Here is an example of the API used for repeated location updates:

function updatePosition(position) {
// Latitude and longitude are available as position.coords.latitude and position.coords.longitude
}
// Request repeated updates.
// This method calls back repeatedly to the updatePosition() function
// until cancelled using clearWatch(), below.
var watchId = navigator.geolocation.watchPosition(updatePosition);
// Cancel the geographic position updates.
function cancelPositionUpdates() {
navigator.geolocation.clearWatch(watchId);
}


2D Canvas Animation API in HTML5

New <canvas> element and JavaScript 2D Canvas API allow two-dimensional drawing, graphics and animations. Cross-platform games become possible in mobile browsers. Reminder: Script execution impacts battery life on mobile devices.

Here is an example of a 400×400 canvas element:

<canvas id="myCanvas" width="400" height="400" />


And here is an example of the 2D Canvas API used to draw inside the canvas:

// Obtain is a reference to a <canvas> element
var canvas = document.getElementById('myCanvas');
// Obtain a context used to draw
var context = canvas.getContext('2d');
// Clear the canvas
canvas.setAttribute('width', '400');
// Draw an image on the canvas, 'myImage' is a reference to an existing image element.
// Image is drawn at position (10, 10) with width of 100 and height of 50.
canvas.drawImage(myImage, 10, 10, 100, 50);
// specify a CSS color used to fill drawn elements
context.fillStyle = 'rgb(255, 0, 0)';
// Draw a red rectangle on the canvas
context.fillRect(0,0,50,50);
// Clear the canvas
canvas.width = canvas.width;


Web Storage API in HTML5

The Web Storage API allows documents to persistently store data in a mobile browser. Mobile browsers can write data in one browsing session and read it in the next session.

Offline Application Caching in HTML5

HTML5 documents use a manifest to list all dependent external resources (i.e. CSS files, JavaScript libraries, etc.). Mobile browsers use the manifest to cache an entire Web application for offline use, allowing mobile users to interact with a Web app while roaming in and out of coverage areas.

Semantic Document Structure in HTML5

New <header>, <footer>, <nav>, <section>, <article>, <figure> and <aside> elements declare the logical structure of a Web document. Structural elements make it easier for mobile browsers to navigate document components and display partial documents.

Native Audio and Video Controls in HTML5

New <video> and <audio> elements embed multimedia into a Web document without using third-party browser plug-ins. Mobile browsers may natively control multimedia display, codecs and user interfaces.

HTML5 Supplants XHTML

HTML5 supplants the XHTML 1.0 specification. In HTML5, XHTML is re-defined as a set of syntax rules and is no longer an independent markup specification. HTML5 can be expressed using either the strict syntax rules of XML or the looser syntax of HTML, which tolerates unclosed tags. Both formats are accepted as HTML5. This sensible change restores the unity of markup language functionality while allowing the mobile developer or designer the flexibility of choosing precise or lenient syntax. Slackers, you can continue to slack off in HTML5.

Motherhood, Apple Pie and HTML5

Mobile pundits tout HTML5 as the antidote to practically every problem in Mobile Web development. HTML5 is indeed a great leap forward in standardizing the advanced features of Web browsers. Its new elements and APIs unlock consistent implementations of rich Web application behavior. Unfortunately, HTML5 will not lessen or extinguish several sins of Mobile Web development, including:

• Fragmentation: Too many vendors implement mobile browsers, creating a fragmented marketplace and forcing developers to adapt Web content to play to browser strengths and avoid browser weaknesses.
• Browsers Bugs: As with any Web standard, HTML5 features may be incompletely or incorrectly implemented in a mobile browser.
• Rushing to Market: Mobile browsers may support HTML5 too quickly, implementing features or syntax that end up changed or cut from the final standard.
• Forgetting the Mass Market: Many popular Mobile Web sites use simple markup to quickly provide snackable chunks of relevant information to users. Upgrading these Mobile Web sites to use HTML5 (without implementing content adaptation) could cut off access to millions of users with older, Web-accessible mobile browsers.

HTML5 on Smartphones and Featurephones

Of course, the promise of HTML5 is only realized on mobile devices with modern, updatable Web browsers. As of this writing, iPhone, Android and Palm smartphones all implement portions of the HTML5 specification. Smartphones provide an excellent platform for rolling out HTML5 applications to savvy Mobile Web users. However, the majority of mobile subscribers still use non-smartphone devices with no ability to update the browser or operating system. Developers must use content adaptation principles to include advanced HTML5 elements only the target mobile browser is known to support HTML5. Content adaptation ensures a satisfactory Mobile Web experience for all mobile users.

This post is adapted from a short section on HTML5 and mobility that I contributed to Janine Warner’s upcoming book, Mobile Web Design for Dummies.

I am newly a mobile development contributor to Fierce Wireless. An excerpt from my first article, Targeting Smartphone Apps for Mass-Market Users, published today, is below. Check out the full article at FierceDeveloper…

Who is the typical smartphone user? I envision a stressed-out businessperson or dangling-headphone hipster. My stereotypical smartphone user is an affluent, tech-savvy individual who harnesses the power of her device for near-constant interactions with mobile data services. She uses her smartphone to send email, browse the Web, stream videos and music, connect with friends on social networks, comparison-shop, and find nearby restaurants and businesses. Oh yes, and she occasionally uses her mobile phone for voice calls.

My stereotype crumbles as more and more mobile users upgrade from feature phones to smartphones. This year, mass-market consumers are stampeding into the smartphone ecosystem. 2010 is the year when “anyone with a touchscreen” is using their shiny, new smartphone to consume mobile data services. Clever mobile developers recognize the exploding smartphone user base as an unparalleled opportunity to simplify the usability of Mobile Web and native applications and provide personalized experiences to suit all kinds of smartphone users.

Capturing HTTP request headers from Web browsers on mobile devices gives you the information required to simulate the device in Firefox or a mobile device or browser emulator.

Here is a handy tool that allows you to easily view, cut and paste the HTTP headers sent by a Web browser on a mobile device. Follow these steps to capture HTTP headers from a mobile browser:

1. Browse to http://learnto.mobi using the mobile browser.
2. Select the View Request Headers link.
3. Notice the HTTP request headers on the displayed Mobile Web page.
4. Remember the four-digit number shown at the top and bottom of the page. (i.e. Viewing Request Headers #1234)
5. Browse to the same View Request Headers page in a desktop browser (i.e. Firefox, Chrome, Safari or IE).
6. Enter the saved number into the textbox at the bottom of the page. Press the Go button to view the HTTP request headers from the mobile device. (i.e. enter “1234″ into the textbox.)
7. Copy and save the HTTP headers for use in Firefox and mobile emulators.

Let’s look at some screenshots of this process. The following screenshot shows the location of the View Request Headers link that is clicked in Step 2 to display the HTTP headers.

The following screenshot shows the location of the four-digit number mentioned in Step 4 that is (temporarily) associated with the HTTP request headers. In this screenshot, the headers are from Firefox 3.5.

The screenshot below shows the location of the textbox from Step 6 into which the four-digit number from Step 4 is entered to call up a (recently) previously-viewed set of HTTP request headers. The HTTP request headers displayed in the screenshot are from a Motorola MB200 Cliq Android smartphone.

Once you are viewing a request headers from a mobile device in a desktop browser, simply copy and paste the headers to save them.

NOTE: The four-digit numbers assigned to HTTP request headers are temporary. They are re-assigned over time to new sets of headers. It’s important to complete the process of viewing headers on a mobile device and capturing headers using a desktop browser over a short time period, say 5 to 15 minutes.

A reader from Minnesota recently emailed me to ask which markup language is best used for a Mobile Web site targeting smartphones:

My company is building an academic iPhone application (showing completed classes, current classes, grades, etc.). We also want to build a Mobile Web site that surfaces this information. If we only want to support smartphone Web browsers, should we use HTML or XHTML-MP?

My preference is to always use XHTML-MP (XHTML Mobile Profile). HTML is too unstructured for mobile devices. XHTML is a better choice, but can be considered "desktop markup" by some services in the mobile ecosystem, potentially subjecting the site to transcoding and exclusion from indexes of Mobile Web sites.

Web browsers in iPhone, Palm webOS, Android and other smartphones will render HTML and XHTML without problems, but if you stick with XHTML-MP, you also achieve built-in compatibility with a greater variety of Internet-capable mobile devices. Using XHTML-MP also allows crawlers for mobile search engines to easily recognize your content as mobile-optimized. In my experience, the Web development goal of "only supporting smartphones" almost always broadens to "supporting all Web-savvy mobile browsers", which are installed on a rapidly increasing percentage of low-end and free featurephones. You set your Mobile Web site up for broader compatibility if you stick with XHTML-MP.

If you must use XHTML or HTML for a Mobile Web site targeting smartphones, then be sure to embed mobile META tags into the markup. The Viewport, HandheldFriendly and MobileOptimized META tags identify Web documents authored in desktop-optimized markup languages as optimized and intended for mobile devices.