HTML 5 may not be finished yet, but it’s already
transforming a wide variety of mobile web development tasks.1. The Standard
At the time of this writing, HTML 5 is a draft for the future standard for website
markup. It will replace both XHTML 1.1 and HTML 4.0, adding new markup,
deprecating some existing tags (like font and center), and adding some new JavaScript APIs.
You can find the latest documentation at http://dev.w3.org/html5.
Mobile browsers are very hungry for new features in web
applications, and this hunger has driven these browsers to have partial
support of HTML 5 before it’s available in desktop browsers. Many of the
new elements that have been proposed (remember, HTML 5 is still a draft
and in discussion) are semantic tags intended to reduce
divitis (the abuse of the div tag). To this end, the draft standard
includes new tags such as section,
article, footer, nav, video,
audio, canvas, and command.
It also adds support for new types of form controls, including
tel, search, url, email,
datetime, date, month, week, time,
number, range, and color. For input tags, it also defines the
attributes placeholder, autofocus, required, autocomplete, and pattern.
Note:
Although this is not an HTML or JavaScript basics book, we are
going to get deeper into some of the new HTML 5 features because they
are new for almost every web developer. There are some new books
appearing on the market for this new technology: visit http://www.oreilly.com/css-html for the latest books in
this area.
Unfortunately, with a few exceptions (as shown in Table 9-11), the HTML 5 support in mobile
browsers today is not about markup and attributes. It primarily includes
the JavaScript API additions.
However, many of the new semantic tags (e.g., section, article, or footer) can still be used in smartphone
browsers; they will just be ignored until support for them is added, and
in the meantime we can emulate the incompatible tags and event behavior
using CSS styles and JavaScript.
On compatible devices, the video and audio tags allow users to play the media
object defined using the src
attribute without having Adobe Flash Player or any other plug-in
installed. This object can be managed through JavaScript
(playing/pausing/stopping and volume control). A great way to use
progressive enhancement here is that the tags allow us to insert
children for noncompatible devices, and we can use another player
solution there:
<video src="video.avi" controls>
<!-- This will be rendered on noncompatible browsers -->
<object data="player.swf" type="application/x-shockwave-flash">
<param value="video.flv" name="movie"/>
</object>
</video>
Table 1 reports on
browser support for HTML 5 tags, tag emulation, and form
controls.
Table 1. HTML 5 compatibility table
| Browser/platform | Official tag
support | Tag
emulation | Form
compatibility |
|---|
| Safari | canvas, audio, video | Yes | Partial: email, tel, phone, and number input types |
| Android
browser | canvas | Yes | No |
| Symbian/S60 | No | Yes | No |
| Nokia Series
40 | No | Yes | No |
| webOS | canvas | Yes | No |
| BlackBerry | No | Yes | Yes, multiple input types
from 5.0, datalist support |
| NetFront | canvas from 3.5 | No | No |
| Internet
Explorer | No | Yes | No |
| Motorola Internet
Browser | No | No | No |
| Opera
Mobile | canvas | Yes | No |
| Opera Mini | canvas | Yes | No |
2. Editable Content
HTML 5 introduces an attribute called contenteditable that
allows almost any text HTML element to be edited by the user. For
example:
<p contenteditable="true"> </p>
<div contenteditable></div>
The element will respond to text input events, like blur or focus. Almost all desktop browsers support
this attribute, including Internet Explorer 6, because it was originally
an extension of that browser. It has been used in many online tools for
documents, spreadsheets, and presentation management.
No mobile web browsers currently support the contenteditable attribute, but WebKit-based
browsers like Android and Safari can emulate this behavior using a
textarea with a -webkit-appearance of none:
<textarea style="-webkit-appearance: none"></textarea>
The CSS style will remove the default visual design of the
textarea, including borders.
3. New Input Types
HTML 5 adds new form input types that can be used on
compatible devices. Incompatible browsers will generally show a typical
text input instead.
The new input types include number, email, search, url, color,
date, datetime, time, week,
month, and range.
Even when the new fields invite the user to insert dates and
numbers, we will always read the value as a string. The only difference
from type="text" is some kind of
visual hint to help the user with filling in the field: for example,
when the input is defined as email
the virtual onscreen keyboard changes to include an @, with range the user gets a slider, and select lists
are provided for date inputs.
At the time of this writing, only BlackBerry 5.0 has full support
for these new input types. Safari on iOS partially supports some of
them, and it is very possible that other platforms will add this support
soon.
The types that have specific attributes are date and range (and other date-related types, like
month), which add two new attributes
for limits: min and max. For example:
<input type="date" min="2010-01-01" max="2020-01-01" id="date" />
<input type="range" min="21" max="110" id="age" />
These new controls also accept the step attribute—for example, showing every 10
minutes in a time input control—but
it seems that at the time of this writing no mobile browsers support
it.
4. Data Lists
HTML 5 also adds a new datalist tag that is
useful for autocomplete features. As of this writing, only the
BlackBerry browser included with version 5.0 or newer of the operating
system supports it.
We can define a data list with an ID and a set of child option elements:
<datalist id="dataCountries">
<option>France</option>
<option>Portugal</option>
<option>Spain</option>
</datalist>
Then, we can use that list for suggestions in a text input,
matching the list attribute with the
data list’s id:
<input type="text" id="txtCountry" list="dataCountries" />
The data list will not have any UI if it is not associated with
one or more form elements. When the user focuses on an associated text
input, the browser will suggest options regarding the data list.
On noncompatible browsers, the user may see the option’s values.
We can replace <option>value</option> with <option
label="value" /> to avoid this problem.
