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.

My Mobile Web Development course returns to Portland Community College. this summer. Students learn how to build web sites for browsers on all kinds of mobile phones. We focus on standards-based mobile web development, exploring mobile standards and industry best practices. This practical course includes in-class coding and experimentation. Register now at PCC.

Mobile Web Development class details:

• CRN: 34044
• Fee: $380
• July 14 – August 18, 2010
• 5:30pm – 9:30pm on Wednesday evenings
• Class meets in Room 118, Mt Tabor Hall at PCC SE Center (SE 82nd and SE Division)
• Class location is a computer lab. Computers are provided. Laptops and personal web space are encouraged. If using the PCC computers, bring a thumb drive to save your work.
• 2.40 CEU credits from PCC Computer Education Training and Certification program

See you there!

A reader recently wrote in from the UK, remarking on the lack of support for streaming Windows Media audio formats in mobile devices, especially smartphones. He attributed the poor support levels to lazy software engineering practices on the part of mobile device manufacturers. The reader was trying to create a Mobile Web page that streamed Windows Media audio (as an *.asx file) to a mobile phone. He provided me with sample markup and asked me why it didn’t work on many phones.

Let’s analyze whether it is possible to stream Windows Media audio to mobile browsers as a case study in cross-platform Mobile Web development.

MIME Types for Windows Media Players and Services

Microsoft publishes the following MIME types for Windows Media services. Microsoft does not declare that any of these MIME types are mobile-specific media formats.

Support for Windows Media Player MIME Types in Mobile Browsers

Now, let’s use mobile device databases and Accept HTTP request headers to determine whether a mobile browser supports the MIME types for Windows Media streaming formats.

Use the WURFL or DeviceAtlas mobile device databases to determine whether a mobile device supports any Windows Media MIME types for streaming media. These two industry-leading device databases track support for many mobile-friendly streaming media and audio formats. If a device database cannot determine support for streaming media formats, fall back to inspecting the value of a mobile browser’s Accept HTTP request header to find a list of supported content types. Any Windows Media MIME types found in the Accept header are supported by the mobile phone.

The WURFL device database documentation provides several characteristics and characteristic groups related to media playback and streaming. In the playback group, WURFL tracks whether a mobile device supports common video formats (Windows Media Video, H.263, MPEG4, H.264, Real Media, Flash Video and MOV) and audio formats (AMR, AAC and QCELP). Unfortunately, WURFL tracks only whether a mobile device supports a single Windows Media streaming format, Windows Media Video (WMV). The WURFL device database does not provide information about mobile support for Windows Media streaming audio formats.

The DeviceAtlas property explorer (free registration required) shows properties in the streaming group that track support for several streaming media formats in mobile devices. DeviceAtlas provides information about streaming audio (AAC, AMR) and video (H.263, H.264, MPEG4) formats in the 3GPP and 3GP streaming envelopes. DeviceAtlas’s audio player group tracks playback support for AAC, AMR, MIDI, MP3 and QCELP audio file formats on the device’s pre-installed audio player. Unfortunately, DeviceAtlas properties do not provide infomration about mobile support for any Windows Media streaming formats.

Unfortunately, both the WURFL and DeviceAtlas mobile device databases do not help developers determine whether Windows Media streaming audio formats are supported on mobile devices. The lack of device database properties for Windows Media formats can and should be interpreted as a commentary on the appropriateness of media streaming to mobile devices using Windows Media formats. If Windows Media streaming was possible on a wide variety of mobile devices, mobile developers would lobby to create properties in public device databases to document support levels.

On smartphones, downloadable third-party applications may provide support for streaming media formats that are not recognized by the built-in audio player. In this case, Windows Media audio streaming might work flawlessly but device databases would not recognize that the media types are supported on the mobile device. WURFL and DeviceAtlas track the capabilities of mobile device hardware and built-in browser applications but not device functionality extended by third-party applications.

Since device databases can’t help us find out whether Windows Media streaming is supported on mobile devices, let’s inspect Accept request header values from browsers on a few popular mobile device models. If we find MIME types for Windows Media streaming formats in the header value, then we know that the mobile device supports Windows Media streaming media.

Motorola Droid (Verizon):
Accept: application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5


Palm Pre (Sprint):
Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5


Apple iPhone (AT&T):
Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5


BlackBerry Curve 8310 (T-Mobile):
Accept: application/vnd.rim.html,text/html,application/xhtml+xml,application/vnd.wap.xhtml+xml,text/vnd.sun.j2me.app-descriptor,image/vnd.rim.png,image/jpeg,application/xvnd.rim.pme.b,application/vnd.rim.ucs,image/gif;anim=1,application/vnd.wap.wmlc;q=0.9,application/vnd.wap.wmlscriptc;q=0.7,text/vnd.wap.wml;q=0.7,*/*;q=0.5


LG VX9100 (Verizon):
Accept: application/vnd.phonecom.mmc-xml, application/vnd.wap.wmlc;type=4365,application/vnd.wap.wmlscriptc,application/vnd.wap.xhtml+xml,application/xhtml+xml;profile="http://www.wapforum.org/xhtml", image/bmp,image/gif, image/jpeg, image/png, image/vnd.wap.wbmp, image/x-up-wpng,multipart/mixed, multipart/related, text/html, text/plain,text/vnd.wap.wml;type=4365, audio/midi, audio/qcelp, audio/vnd.qcelp,audio/mid, audio/x-midi, audio/x-mid


The Accept request headers aren’t much help! The mobile devices with WebKit browsers (Motorola Droid, Palm Pre and Apple iPhone) specify only their preferred mobile markup and image formats, choosing to include media support indirectly in the regular expression for fallback content types (i.e. */*;q=0.5). For the BlackBerry Curve 8310, the header lists support for additional content types but does not list any streaming video or audio formats (outside of the fallback regular expression). The LG VX9100, an older mobile phone from Verizon, accepts several audio formats (i.e. audio/midi, audio/qcelp) but no streaming media formats.

Are Windows Media Streaming Formats Viable in Mobile Browsers?

Are Windows Media streaming formats viable on mobile devices? Clearly, Windows Mobile devices include the pre-installed Windows Media Player Mobile, so some smartphones can natively support streaming audio and video in Windows Media formats. Microsoft does not claim that Windows Media streams are compatible with any mobile platform besides its own mobile OS, Windows Mobile. We can conclude that Windows Media streaming audio and video formats are not broadly supported on mobile devices. Only Windows Mobile devices and the iPhone are known to support Windows Media streaming formats.

When implementing streaming audio and video targeted to mobile devices, a better solution is to choose a more lightweight streaming format that is widely supported by mobile devices and browsers. 3GP, 3GPP, H.263, H.264 and MPEG4 are well-supported by mobile devices and are better choices.

Improving a Mobile Web Page that Implements Streaming Windows Media

Our reader provided the following sample XHTML Mobile Profile document that embeds a Windows Media player. His sample code is below (modified slightly to preserve anonymity). Assuming that this code is intended for a Windows Mobile device, let’s improve the Mobile Web page to adhere to Web and Mobile Web standards and use only valid markup.

Here is the original XHTML-MP code sample:

<!DOCTYPE html PUBLIC "-//WAPFORUM//DTD XHTML Mobile 1.0//EN" "http://www.wapforum.org/DTD/xhtml-mobile10.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<title>Streaming Audio</title>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
</head>
<body topmargin="0" leftmargin="0" marginheight="0" marginwidth="0">
<table width="300"border="0" cellspacing="0" cellpadding="0">
<tr>
<td align="left"><img src="logo.jpg" width="200" height="50"></td>
</tr>
<tr>
<td><object id="mediaplayer" name="mediaplayer" classid="clsid:22D6F312-B0F6-11D0-94AB-0080C74C7E95" codebase="http://activex.microsoft.com/activex/controls/mplayer/en/nsmp2inf.cab#Version=6,4,5,715" height="50" width="200">
<param name="filename" value="http://foo.com/audio/start.php">
<param name="autosize" value="true">
<param name="autostart" value="true">
<param name="showcontrols" value="true">
<param name="showtracker" value="false">
<param name="autosize" value="true">
<param name="showstatusbar" value="true">
<param name="showdisplay" value="false">
<param name="showpositioncontrols" value="false">
<embed type="application/x-mplayer2" pluginspage="http://microsoft.com/windows/mediaplayer/en/download" id="mediaplayer" name="mediaplayer" displaysize="3" autosize="-1" showcontrols="-1" showtracker="0" showdisplay="0" showstatusbar="1" showpositioncontrols="0" width="200" height="50" src="http://foo.com/audio/stream.asx" autostart="true">
</embed></object></td>
</tr>
</table>
</body>
</html>


The W3C Markup Validation Service uncovers many flaws in the sample code, including:

• The doctype is XHTML-MP but the markup content is clearly HTML. Many HTML elements and attributes are used that are not supported in XHTML-MP. (i.e. topmargin, marginheight, marginwidth, border, cellpadding, etc.)
• Image elements must include an alt attribute.
• XHTML-MP requires well-formed XML syntax. The img and param elements are unclosed in the markup sample.
• The object element contains attributes that are unsupported in XHTML-MP.

There is also a common-sense flaw in the code sample. The object element that actually embeds the Windows Media Player client includes classid and codebase attributes that reference the desktop version of Windows Media Player. These values should be checked for compatibility with Windows Mobile devices.

Since this markup is intended only for Windows Mobile devices, which are known to support the HTML doctype, let’s clean up the sample by:

• Changing the doctype to XHTML Transitional.
• Correcting the XML to restore well-formedness.
• Removing unsupported elements and attributes.
• Keeping the markup intact that embeds the Windows Media player. (I’m not a streaming media expert. Please leave comments if you can improve the object and embed elements for Windows Mobile clients.)

The updated XHTML code sample is below. It is still invalid markup, according to the W3C Markup Validation Service, but at least all validation errors are confined to the syntax of the object and embed elements that control the Windows Media player.

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<title>Streaming Audio</title>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
</head>
<body style="margin: 0px;">
<table width="300" border="0" cellspacing="0" cellpadding="0">
<tr>
<td align="left"><img src="logo.jpg" width="200" height="50" alt="logo" /></td>
</tr>
<tr>
<td><object id="mediaplayer" name="mediaplayer" classid="clsid:22D6F312-B0F6-11D0-94AB-0080C74C7E95" codebase="http://activex.microsoft.com/activex/controls/mplayer/en/nsmp2inf.cab#Version=6,4,5,715" height="50" width="200">
<param name="filename" value="http://foo.com/audio/start.php" />
<param name="autosize" value="true" />
<param name="autostart" value="true" />
<param name="showcontrols" value="true" />
<param name="showtracker" value="false" />
<param name="autosize" value="true" />
<param name="showstatusbar" value="true" />
<param name="showdisplay" value="false" />
<param name="showpositioncontrols" value="false" />
<embed type="application/x-mplayer2" pluginspage="http://microsoft.com/windows/mediaplayer/en/download" id="mediaplayer" name="mediaplayer" displaysize="3" autosize="-1" showcontrols="-1" showtracker="0" showdisplay="0" showstatusbar="1" showpositioncontrols="0" width="200" height="50" src="http://foo.com/audio/stream.asx" autostart="true">
</embed></object></td>
</tr>
</table>
</body>
</html>


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.