Mobile markup - XHTML Basic 1.1
Introduction
There are a number of options developers can take when planning to mobilise their Web sites. The three main approaches are:
- Do nothing and allow the browser to adapt the content.
- Adapt the regular desktop site by providing alternative styling using techniques such as handheld style sheets or media queries.
- Create a mobile specific version.
This article will cover the third approach, introducing the markup options for mobile focused Web pages, and what features they offer.
A note on mobile specific versions
While this article covers the markup options for mobile-specific sites, you should think carefully if this is the approach that you wish to take. Just like creating an additional version for printing or a high-accessibility version, additional sites require more maintenance and run the risk of becoming out of sync with the main version of the site. Your concept of what to remove from the mobile version, and what functionality is most important, may be widely different from the expectations of your user base. At Opera we often get a large number of bug reports when major sites switch to forwarding mobile users to their reduced mobile-specific site.
If you choose to go down this path, make sure that the user is given a visible option to return to the regular version of the site, and that the preference is remembered across sessions. As a general rule of thumb, I’d recommend creating a mobile version only if you are providing extra mobile contextual information or features that do not make sense on the desktop version or if the main site is extremely complex, such as with Ajax-heavy Web applications. Mobile versions often work best as a companion site to the main version, which can be used to quickly achieve common tasks on the move. Examples include updating your status message on a social network or checking the live scores or match schedule on a sports site. Making a version that is to be exclusively used by mobile users can mean that other users miss out on optimisations made for mobile. This includes accessibility improvements for users with disability or bandwidth savings for users with a dial-up connection and old hardware. Many mobile Web best practices overlap with these disciplines.
Once upon a time…
Once you have decided to make a mobile site, you have to choose a markup language. Choosing a markup language for mobile content has never been as obvious as it should be. In the early days of the mobile Web, the WAP forum (now called Open Mobile Alliance) created a XML-based language called WML. This was the markup language of the WAP Web. This wasn’t ideal as it split the Web in two—(X)HTML for the regular Web and WML for the mobile Web. Web developers wanting to make mobile sites had to learn a new language instead of transferring skills, and the principles of One Web
were broken—users couldn’t visit their favorite Web sites and had to discover the WAP versions of sites, if they existed at all. This was further compounded by the situation in Japan, where NTT DoCoMo created their own language—cHTML (Compact HTML), which wasn’t compatible with XHTML or WML.
Seeing this was less than ideal, the W3C created XHTML 1.0 Basic. As the name implies, this is a subset of XHTML 1.1. As XHTML 1.1 is a reformation of XHTML into small bite-sized modules, a subset could be created that just includes the essential modules, elements and attributes that are needed or can be handled on low-end mobile devices.
Building on XHTML
XHTML Basic provides the building blocks for mobile-focused markup languages. In keeping with its XML roots, it was designed to be extended. This is exactly what the WAP Forum and NTT DoCoMo did when they joined together (as the Open Mobile Alliance) to create the successor to both cHTML and WML, called XHTML Mobile Profile. This superset of XHTML Basic adds features that are missing from that language but were included in their previous solutions. This is currently at XHTML-MP 1.2 at the time of writing. It is fairly confusing that there are two markup languages that have seemingly large overlaps in purpose. This looks to be remedied soon, as the W3C have realigned XHTML Basic in version 1.1 to include the features added to XHTML-MP, and the two languages now look more or less identical. Choosing one or the other is just a matter of personal preference, but, in this article, I will stick to XHTML Basic as it is a proposed W3C recommendation.
Counting on a baseline
It can now be accepted that XHTML Basic 1.1 support is a cut-off point for browser support. I’d recommend using this in mobile-specific sites rather than worrying about catering for outdated WAP browsers. The Mobile Web Best Practices from the W3C in fact require XHTML Basic in the mobileOK checker (currently in Beta). Your mileage may vary depending on your target audience, but there are XHTML Basic capable browsers for almost every mobile released over the last couple of years—Opera Mini for example can cope with full (X)HTML and works on most Java-enabled phones. As XHTML Basic is just regular XHTML, it is perfectly possible for regular desktop browsers to render pages correctly that are written using it, with the exception of Internet Explorer; it doesn’t support XHTML served as XML.
Transferable skills with XHTML Basic
As mentioned, XHTML Basic is just a subset of XHTML, so if you know XHTML already, you are almost ready to go. You just need to learn what is and isn’t supported. We’ll start at the beginning with the basic skeleton of a XHTML Basic 1.1 page:
<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.1//EN"
"http://www.w3.org/TR/xhtml-basic/xhtml-basic11.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
<head>
<title>Page title</title>
</head>
<body>
</body>
</html>
As you can see, this is quite standard stuff. The only things you need to take notice of are the XHTML Basic doctype, that xml:lang is used as it is being served as XML, and that the document should be served as application/xhtml+xml not text/html.
Supported XHTML modules
The following modules and elements are supported from XHTML:
Structure Module
Supported elements: html, head, title, body
Unsupported elements: none
Text Module
Supported elements: abbr, acronym, address, blockquote, br, cite, code, dfn, div, em, h1, h2, h3, h4, h5, h6, kbd, p, pre, q, samp, span, strong, var
Unsupported elements: none
Hypertext Module
Supported elements: a
Unsupported elements: none
List Module
Supported elements: dl, dt, dd, ol, ul, li
Unsupported elements: none
The value attribute for the li element was added in XHTML Basic 1.1 and wasn’t available in previous versions of the spec.
Forms Module
Supported elements: button, fieldset, form, input, label, legend, select, optgroup, option, textarea
Unsupported elements: none
Previous versions of XHTML Basic only implemented the Basic Forms Module.
Basic Tables Module
Supported elements: caption, table, td, th, tr
Unsupported elements: none
Nested tables are not supported, but these are rarely needed when using tables for their intended purpose—tabular data. While XHTML Basic implements all of the Basic Tables Module, it does not support the full Table Module, which extends the Basic Table Module. As such col, colgroup, tbody, thead and tfoot are unsupported in XHTML Basic.
Image Module
Supported elements: img
Unsupported elements: none
The Mobile Web Best Practices document recommends that only JPEG or GIF images be used (not PNGs).
Object Module
Supported elements: object, param
Unsupported elements: none
While the object element is supported, it is not recommended to use plug-ins on mobile focused sites unless absolutely necessary. This is because it can’t be predicted if a specific plug-in is available on all or even the majority of target devices. Flash is available for Opera Mobile, for example, but not on the iPhone or Opera Mini.
Presentation Module
Supported elements: b, big, hr, i, small, sub, sup, tt
Unsupported elements: none
While this module is supported, presentation should be kept to CSS (or SVG) and kept out of the page structure. I would, however, argue that superscript (sup) and subscript (sub) are more about structure than presentation, and it is perfectly semantically valid to use the i element for certain cases where it is typographic convention to use italics, such as ship names and publication names, where using emphasis (em) would be incorrect. In earlier versions of XHTML Basic, the Presentation module was not supported.
Metainformation Module
Supported elements: meta
Unsupported elements: none
Link Module
Supported elements: link
Unsupported elements: none
Base Module
Supported elements: base
Unsupported elements: none
Intrinsic Events Module
Supported attributes: onblur, onfocus, onload, onunload, onreset, onsubmit, onchange
Unsupported attributes: none
Most full HTML browsers (e.g., Opera Mobile, iPhone WebKit) support these events, and more; the exception is Opera Mini, which being proxy based, has issues with some events, especially with ones involving constant activity, animation, or refreshing. The article JavaScript support in Opera Mini 4 gives more details on Opera Mini event support. This module was not supported in previous versions of the specification.
Scripting Module
Supported elements: script, noscript
Unsupported elements: none
It is important to be aware that, while scripting is supported in XHTML Basic 1.1, JavaScript support is much more spotty in mobile browsers than desktop. Even for modern full HTML browsers such as Opera Mobile and Mobile Safari, using a lot of scripting, even though supported, can drain the battery. Opera Mini has some restrictions with JavaScript interaction, which you can read up on in the article JavaScript support in Opera Mini 4. Earlier versions of XHTML Basic did not support the Scripting Module.
Style Sheet Module
Supported elements: style
Unsupported elements: none
The Style Sheet Module was not available in previous versions of the specification.
Style Attribute Module
Supported attribute: style
Unsupported attribute: none
This module has been deprecated, and the MobileOK checker will flag up use of this attribute as a warning. Avoid using inline styles in your documents whenever possible. The style attribute was not supported in previous versions of the specification.
Target Module
Supported attribute: target
Unsupported attribute: none
This module was not supported in previous versions of the specification.
New features for XHTML Basic
While XHTML Basic is a subset of XHTML 1.1, it is not fully a subset as XHTML Basic 1.1 adds a new attribute not available in regular XHTML or HTML. This is the inputmode attribute, which has been borrowed from XForms. As this is a new attribute, support for this is spotty at best, but pages should degrade gracefully in browsers that do not support it. The Opera core rendering engine supports inputmode, but it has to be enabled on a project-by-project basis and is not on by default.
The inputmode attribute is supported on the input and textarea elements. Supplying a input mode gives a hint to the browser on what keyboard or input mode should be presented to the user. This is useful for on-screen keyboards, where a limited amount of characters on the keyboard can be shown at once. For a telephone number, it is possible to specify that a numeric keyboard is shown, saving the user from having to switch manually.
The value for the inputmode attribute is specified as a case-sensitive space-separated list. Two kinds of tokens can be specified; a script token (usually corresponding to the Unicode script name, such as arabic or cyrillic) and a modifier token such as predictOff to turn off text prediction or digits to specify numerical input. The following example specifies to the browser to use a Cyrillic input mode with text prediction turned off:
<input type="text" id="surname" inputmode="cyrillic predictOff" />
Unsupported modules and restrictions
One important difference between XHTML and XHTML Basic that has already been covered is the lack of the full Table Module. This restricts splitting a table into a head, body, and footer—so the following example is invalid:
<table>
<thead>
<tr><th scope="col" >Brand</th><th scope="col" >Type</th><th scope="col" >Strength</th></tr>
</thead>
<tbody>
<tr><td>Russian Standard</td><td>Vodka</td><td>40% vol</td></tr>
<tr><td>Putinka</td><td>Vodka</td><td>40% vol</td></tr>
</tbody>
</table>
The th element is supported, so the previous table can be reformulated as follows:
<table>
<tr><th scope="col" >Brand</th><th scope="col" >Type</th><th scope="col" >Strength</th></tr>
<tr><td>Russian Standard</td><td>Vodka</td><td>40% vol</td></tr>
<tr><td>Putinka</td><td>Vodka</td><td>40% vol</td></tr>
</table>
Other modules that are unsupported include the Edit Module (del and ins), Bi-directional Text Module (bdo), Applet Module, Client-side Image Map Module, Server-side Image Map Module, Frames Module, IFrame Module, Name Identification Module (name attribute), and the Legacy Module (basefont, center, dir, font, isindex, menu, s, strike, u). In practice, except for the Table Module, many of these modules are either deprecated, have elements that can hamper usability (such as frames), or are elements that are not commonly used. Of those listed, I personally only use the elements from the Table and Edit modules.
Validation and conformance
As XHTML Basic should be served as XML instead of HTML, it is very important to validate your pages, as the draconian error handling will show an error message if your documents are not well formed. This is especially important to take into account if you allow user-generated content, such as comments. You can validate your documents using the W3C Markup Validator or alternatively by right clicking in Opera and choosing Validate.
You can do more than just validate your pages. The W3C Mobile Web Initiative also makes a mobileOK Checker. This validates against the machine-testable rules specified in the Mobile Web Best Practices document. It is a good idea to try to validate against this to ensure your page is suitable for as wide a range of devices as possible. This is currently not suitable for Web applications, however, as it bans the use of scripts. If your page passes, then you can use the MobileOK trust mark. As a bonus, there are a number of points which correspond to similar points in WAI-WCAG 1 and WAI-WCAG 2, so spending time fixing issues for mobile can help the accessibility of your site, and vice versa.
Smart phones and high end devices
Both XHTML Basic and Mobile Web Best Practises focus on constraint devices and the baseline experience. High-end devices such as Windows Mobile devices like the HTC Touch Diamond or Samsung i900, the iPhone, and S60 devices such as the Nokia N95, are becoming more common, especially in the developed world. While the baseline—such as covered here—should not be forgotten about, depending on the page or application you are writing, it may be worth giving an enhanced experience to these class of devices that have more processing power, higher definition screens, and better quality browsers. The means of deciding and implementing this are beyond the scope of this article, but techniques could include using media queries to detect high-resolution screens and specify a more advanced style sheet, object detection for supplying more advanced scripts, and an XSLT style sheet to transform between XHTML and XHTML Basic if missing features of XHTML are needed.
Conclusion
In this article, I’ve looked into the history of markup for mobile devices, introducing WML, XHTML-MP and XHTML Basic. I covered the features of XHTML 1.1 supported in XHTML Basic, pointing out any differences or potential hazards. I also introduced the Mobile Web Best Practices and how to check for conformance with mobileOK. You should now feel comfortable about writing markup targeted at mobile phones and be ready to explore what features of CSS are supported in CSS Mobile Profile.
David Storey
David Storey heads up the Open the Web initiative at Opera. This small global team is tasked with improving the compatibility of web sites across Opera's wide range of browsers, as well as promoting web standards, accessibility and best practices, so that the Web will work for all standards-aware browsers, platforms, devices and users. He is a member of the W3C Mobile Web Best Practices Working Group.
On his blog, Slightly Ajar, he discusses this work, as well as random topics, from travel to music.
David previously worked for CERN, home of the World Wide Web, before taking up his post at Opera Software.
This article is licensed under a Creative Commons Attribution, Non Commercial - Share Alike 2.5 license.
Comments
The forum archive of this article is still available on My Opera.
-
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang=="en"> - a double equals sign.
-
Thank you, Павел. Now fixed.
No new comments accepted.Павел
Saturday, August 4, 2012
Daniel Davis
Friday, August 31, 2012