W3C

Mobile Web Application Best Practices

W3C Editor's Draft 17 July 2008

This version:
http://www.w3.org/2005/MWI/BPWG/Group/Drafts/BestPractices-2.0/ED-mobile-bp2-20080717
Latest version:
http://www.w3.org/2005/MWI/BPWG/Group/Drafts/BestPractices-2.0/latest
Previous version:
http://www.w3.org/2005/MWI/BPWG/Group/Drafts/BestPractices-2.0/ED-mobile-bp2-20080707
Editors:
Bryan Sullivan, AT&T
Adam Connors, Google

Abstract

This document specifies Best Practices for the development and delivery of Web applications on mobile devices. The recommendations expand and amplify upon general statements made in the Mobile Web Best Practices 1.0 (BP1), especially concerning statements that relate to the exploitation of device capabilities and awareness of the delivery context. Furthermore, since BP1 was written, networks and devices have continued to evolve, with the result that a number of Best Practices that were omitted from BP1 can now be included.

The recommendation is primarily directed at creators, maintainers and operators of Web applications. Readers of this document are expected to be familiar with the creation of Web sites, and to have a general familiarity with the technologies involved, such as Web servers, HTTP, and Web application technologies. Readers are not expected to have a background in mobile-specific technologies.

Status of this Document

This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index at http://www.w3.org/TR/.

Incomplete draft: This document is an editor's copy that has no official standing and is incomplete. It is subject to major changes and is therefore not intended for implementation. It is provided for review and feedback only. Please send feedback to public-bpwg-comments@w3.org (archive).

The W3C Membership and other interested parties are invited to review the document and send comments to public-bpwg-comments@w3.org (with public archive). Advisory Committee Representatives should consult their WBS questionnaires.

This document was developed by the Mobile Web Best Practices Working Group as part of the Mobile Web Initiative.

This document was produced by a group operating under the 4 February 2004 W3C Patent Policy. This document is informative only. W3C maintains a public list of any patent disclosures made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s) must disclose the information in accordance with section 6 of the W3C Patent Policy.

Table of Contents

1 Introduction
1.1 Purpose of the Document
1.2 How the Best Practices are Organized
1.3 Audience
1.4 Scope
1.4.1 Best Practices
1.4.2 Web Application
1.4.3 Mobile Context
1.5 Relationship to other Best Practices and recommendations
1.6 Longevity and Versioning
2 Structure of Best Practice Statements
3 Best Practice Statements
3.1 Personalization
3.1.1 Retain Personalizing Information
3.1.2 Use Automated Means for Identifying the User and Obtaining Personalizing Information
3.2 Security and privacy
3.2.1 Protect Personal Information Used in Transactions
3.3 User awareness and control
3.3.1 Inform the User About Automatic Network Access and Provide Control Over its Use
3.3.2 Inform the User About Use of Personal Information and Degrade Gracefully if Permission is Denied
3.4 Conservative use of resources
3.4.1 Use Transfer Compression for Content
3.4.2 Minimize Redirects in Server-Server API's
3.4.3 Minimize Automatically Issued Network Requests
3.4.4 Use Push Methods to Reduce Pull Traffic
3.4.5 Minimize Application Size
3.4.6 Minimize DOM Manipulation
3.4.7 Minimize External Resources
3.4.8 Use Power-Efficient Methods
3.5 One Web
3.5.1 Offer A Consistent View Across Multiple Devices
3.6 User Interface
3.6.1 Consider Different Device Interaction Methods
3.6.2 Use Scripting for User Interface
3.6.3 Don't Move the Focus on Updates
3.6.4 Group Closely Coupled Views onto the Same Page
3.6.5 Use hash URLs to Preserve Browser History and Enable Deep Links
3.6.6 Use URI Schemes for Device Functions
3.7 Handling Device Capability Variation
3.7.1 Use Device Capability Detection
3.7.2 Use Reliable Methods for Determining Script Support
3.7.3 Use Device Classification to Simplify Content Selection/Adaptation
3.7.4 Provide Alternatives to Client-Side Scripting
3.7.5 Provide for Both Graceful Degradation & Progressive Enhancement of CSS

Appendices

A Sources (Non-Normative)
B Related Reading (Non-Normative)
C Acknowledgements (Non-Normative)
D References (Non-Normative)
D.1 MWI References
D.2 Sources
D.3 Device Independence
D.4 Web, Protocols and Languages
D.5 Other References


List of Best Practices

The following Best Practices are discussed in this document and listed here for convenience.

This section will be completed when the list of Best Practices is more stable.


1 Introduction

1.1 Purpose of the Document

This document sets out a series of recommendations designed to facilitate development and delivery of Web applications on mobile devices. The recommendations are offered to creators, maintainers and operators of mobile Web sites.

1.2 How the Best Practices are Organized

The document is organized as follows:

1.3 Audience

Readers of this document are expected to be familiar with the creation of Web applications, and to have a general familiarity with the technologies involved, such as Web servers, HTTP, and Web 2.0. Readers are not expected to have a background in mobile-specific technologies.

The intention is to make clear to all involved what the Best Practices are, and hence establish a common basis of understanding. As a result of wishing to be clear to those not already involved in the development of mobile friendly content, some statements may appear to be obvious or trivial to those with experience in this area.

The document is not targeted solely at developers; others, such as interaction and graphic designers, and tool developers, are encouraged to read it.

1.4 Scope

These recommendations expand and amplify on the recommendations of the Mobile Web Best Practices (BP1). Where BP1 focussed primarily on the extension of Web browsing to mobile devices, this document considers the development of Web applications on mobile devices.

1.4.1 Best Practices

The approach in writing this document has been to collate and present the most relevant engineering practices prevalent in the development community today and identify those that: a) facilitate the exploitation of modern device capabilities to enable a better user-experience; or b) are considered harmful and can have non-obvious detrimental effects on the overall quality of the application.

The goal of this document is not to invent or endorse future technologies. However, there are a number of cases where explicitly omitting a Best Practice that referred to an emerging technology on the grounds that it is too recent to have received wide adoption would have unnecessarily excluded a valuable recommendation. As such, some Best Practices have been included on the grounds that we believe they will become fully qualified Best Practices (e.g. in prevalent use within the development community) in the very near future.

1.4.2 Web Application

For the purposes of this document, the term "Web application" refers to a web page (XHTML or a variant thereof + CSS) or collection of Web pages delivered over HTTP which use either server-side or client-side processing (e.g. javascript) to provide an "application-like" experience within a Web browser. Web applications are distinct from simple Web content (the focus of BP1) in that they include some elements of interactivity and persistent state.

Whilst the focus of this document is on producing Best Practices that apply to applications running in a Web browser, in many cases these recommendations are equally applicable to other kinds of Web runtime, such as the widget frameworks being considered as part of the Web Widgets [REF] effort and also in a number of vendor-specific initiatives.

1.4.3 Mobile Context

In an increasingly mobilized world the line between mobile and non-mobile is necessarily blurred and a document focussing solely on best-practices that are uniquely mobile would most likely be very short. With this in mind, the focus of this document is to address those aspects of Web application development for which there are additional, non-trivial concerns associated with the mobile context. This applies equally both to the limitations of the mobile context (e.g. small screen, poor connectivity), and also the additional scope and features that must be considered when developing for the mobile context (e.g. device context / location, presence of personal data on the device, etc).

1.5 Relationship to other Best Practices and recommendations

These recommendations are complimentary to the recommendations of BP1.

This document builds on some of the concepts described by the Ubiquitous Web applications (UWA) working group in the Device Independence Principles [DIP]. The document discusses device and delivery channel characteristics, which the DIWG has named "Delivery Context" [DCODI]. In addition, the document uses some terminology from UWA's Glossary of Terms for Device Independence [DIGLOSS].

2 Structure of Best Practice Statements

This section will be completed when the Best Practice statement structure is more stable.

3 Best Practice Statements

3.1 Personalization

Personalization can improve the user experience by minimizing the amount of effort required to find relevant information. This is especially important in the mobile environment where extra effort is necessary to interact with applications.

3.1.1 Retain Personalization Information

3.1.1.1 What it means

If a service relies on user entered personalization information (e.g. application preferences, personal details) that information should be retained in order to avoid the need to re-enter it the next time a user visits the site.

3.1.1.2 How to do it

Cookies are the most natural means to store small amounts of personalization information. More extensive personalization should be stored on the server in order to facilitate recovery if the cookies are lost, sharing of state across multiple devices, and limiting the amount of data traffic.

The following limitations should be considered when storing personalization information inside a browser cookie:

3.1.2 Use Automated Means for Identifying the User and Obtaining Personalization Information

3.1.2.1 What it means

Ensure that personalization information is available to the user with minimal effort.

3.1.2.2 How to do it

The simplest way to do this is to associate personalization information with a given user identity and obtain their login credentials directly on first access. Recommended methods for doing this include:

User login credentials should not be stored directly on the device because this is insecure, but a securely hashed token can be used to enable automatic login the next time a user visits your site.

If you have a relationship with a Service Provider (e.g. Mobile Network Operators or Web Portal Providers) or an Identity Management Provider they may provide means to access trusted user identities automatically. This has the advantage of removing the need for the user to enter their identity, leading to a better overall experience.

3.2 Security and privacy

Use trusted information, and protect all personally identifiable information.

Although HTTPS is the most common means to secure personally identifiable information, the overhead of using it can be significant over a mobile network. As such, HTTPS should not be used unnecessarily, and the level of security should be matched to the level of sensitivity of the information being exchanged.

3.2.1 Protect Personal Information Used in Transactions

3.2.1.1 What it means

Personally identifiable information (e.g. user identity or information usable as a key to user identity) should only be accepted or sent securely. Less sensitive information that cannot be associated with an individual (e.g. a zip code by itself is not personally identifiable) can be exchanged in the clear provided the correlating information is secure.

3.2.1.2 How to do it

HTTPS is the most secure way to exchange sensitive information such as user-identity. To avoid the overhead of using HTTPS for all transactions, a related pseudo-identity or secure hash of the actual identity can be exchanged in non-secure transactions.

The Working Group is interested in receiving feedback on techniques for securing personal data on mobile devices, and the relative impacts of using HTTPS and other techniques.

3.3 User awareness and control

Ensure that the user is aware of application behaviors that might affect the overall service experience, and that the user is offered options to control those behaviors.

Many browsers support the ability to make background server requests without requiring a page refresh. This makes it possible to make server requests that are not automatically reflected in the user-interface and which might surprise the user or lead to unexpected data charges.

Device APIs are being developed in a variety of standards activities and vendor-specific initiatives to give browsers access to personal and device information, for example:

The use of such personal information and device functions can expose the user to privacy and security concerns.

The overall goal is that the user is informed of such activities, given effective means to control them, and also the opportunity to opt-out of application/function use.

3.3.1 Inform the User About Automatic Network Access and Provide Control Over its Use

3.3.1.1 What it means

Whenever an application makes background data requests, whether automatic or user initiated, this should be indicated to the user in an appropriate manner so the user is not surprised by unexpected data-charges, etc.

Means should be provided to disable any automatic network activity.

3.3.1.2 How to do it

Applications should disclose, in a clear and useful way, the basic nature of their use of the network. A simple icon indicating background activity is usually sufficient and will not interrupt the main application flow. If extensive background network activity is required this should be called out when the user first visits the site, when they log-in, or in associated help pages.

If an application makes automatic network requests (e.g. to poll the server for updates or to automatically store an updated client state) a control should be provided to easily disable / re-enable this activity. Endeavor to keep the application as functional as possible even if automatic network activity is disabled.

3.3.2 Inform the User About Use of Personal Information and Degrade Gracefully if Permission is Denied

3.3.2.1 What it means

Ensure that the user is informed when the application accesses personal or device information. Applications should be defensive and remain as functional as possible if the API request for personal or device information is denied.

3.3.2.2 How to do it

In many cases APIs that provide access to personal or device information deliver a native confirmation dialogue to the user before providing access to the data. In this case the application should not force the user to confirm again at the application level, but should make clear in the UI that displayed data has been accessed from the device.

If the user declines a prompt to allow application access to personal or device information, the application must recover gracefully. For example, if a request to a device API fails, do not automatically retry if this might lead to the user being presented with repeated confirmation dialogues by the underlying API.

3.4 Conservative use of resources

Resources and network bandwidth are significantly more limited on mobile devices than on a desktop device. As a result, Web applications should use device and network resources conservatively.

3.4.1 Use Transfer Compression for Content

3.4.1.1 What it means

Compress content for efficiency in delivery.

3.4.1.2 How to do it

HTTP 1.1 compression, which typically uses gzip or deflate as algorithms, is a widely (though not universally) supported method of transfer encoding for delivery optimization. To use HTTP compression, Web servers should be configured to serve Web pages using HTTP 1.1 compression (gzip or deflate), according to the coding supported by the device as indicated by the HTTP Accept-Encoding header.

Note that the processing cost of decompressing data should be balanced against the gains in transport efficiency. As a rule of thumb the following should be considered when configuring HTTP 1.1 compression:

The Working Group is researching the conditions under which compression should be recommended on mobile devices and is looking for feedback on this topic.

3.4.2 Minimize Redirects in Server-Server API's

3.4.2.1 What it means

Request redirection (e.g. through HTTP or meta refresh methods) is a typical method for a service to automatically obtain information from a different server (e.g. account authentication). Such redirect based API's are common in Web applications, and play an useful role in automated personalization. However, the cost of redirects is much higher over limited bandwidth networks and so the number of redirects should be kept to a minimum to avoid degrading the user experience.

3.4.2.2 How to do it

A typical redirect sequence should require no more than two automated redirects, e.g. one to redirect to the information-providing server, and another to redirect back to the service-providing server.

If further redirects are required, it's possible to use a landing page to break up the sequence. However, it's important to balance the desire to add landing pages in order to improve the perceived latency of the application, against the cost of needlessly interrupting the user flow.

3.4.3 Minimize Automatically Issued Network Requests

3.4.3.1 What it means

Applications that automatically issue network requests should provide value for those requests. The "value" in this case should be determined by the application developer based upon the type of service the application provides, and the resulting direct value to the user.

3.4.3.2 How to do it

Consider the following issues when designing application:

3.4.4 Use Push Methods to Reduce Pull Traffic

3.4.4.1 What it means

Network-initiated content delivery ("push") methods can significantly reduce network traffic overhead, as compared to conventional polling (scheduled "pull") methods.

3.4.4.2 How to do it

Push method support may be disclosed through a User Agent Profile document if published by the device vendor, or through other device classification repositories.

If supported by the user agent, options for Push methods include:

3.4.5 Minimize Application Size

3.4.5.1 What it means

This section elaborates on the best practices of BP1 [section ref].

Ensure that the Web application size is optimized in order to minimize the impact of operating on a limited bandwidth network.

3.4.5.2 How to do it

Various techniques can be used to minimize application size:

3.4.6 Minimize DOM Manipulation

3.4.6.1 What it means

On small devices with limited processing capability, the cost of excessive DOM manipulation can significantly impact application performance.

3.4.6.2 How to do it

Only use DOM manipulation for dynamic parts of the page. The static framework of the page is best created using HTML markup which can then be connected to the script using the element ID tag.

3.4.7 Minimize External Resources

3.4.7.1 What it means

This section elaborates on the best practices of BP1 [section ref].

Web applications typically require multiple resource (e.g. stylesheets, scripts, images). On a mobile network, however, the overhead of making additional HTTP requests is high and can significantly impact service latency. Steps should be taken to minimize the number of requests made by the application.

3.4.7.2 How to do it

The following steps can be taken to reduce network requests:

3.4.8 Use Power-Efficient Methods

3.4.8.1 What it means

As mobile Web applications become increasingly ubiquitous they are more likely to be required to run for long periods of time or be on in the background (e.g. an email application or an IM client). In these circumstances, the application's impact on battery life should be considered.

3.4.8.2 How to do it

The working group is currently investigating the relative impacts of Web application activities on battery life in order to make more concrete recommendations.

3.5 One Web

The term "One Web" encapsulates two aspects of mobile Web application development:

3.5.1 Offer A Consistent View Across Multiple Devices

3.5.1.1 What it means

Multiple devices may be used to access a Web application with the same user credentials (e.g. a user may own multiple mobile devices or may access the same application from both mobile and desktop devices). Application consistency should be maintained across different consuming devices.

3.5.1.2 How to do it

The most common cause of failing to offer a consistent application state across multiple consumers is to store too much information on the device (either in cookies or a local device database). To avoid this, use device based storage carefully and avoid storing personalization data on the device that would still be relevant if the application were accessed from a different consumer. See 3.3.1 Inform the User About Automatic Network Access and Provide Control Over its Use

3.6 User Interface

The Working Group is investigating a number of additional recommendations for this section and is looking for suggestions in this area.

Given the difficulties and complexities of interacting with an application on a mobile device, special consideration should be given to the user interface in order to maintain a good level of usability.

3.6.1 Consider Different Device Interaction Methods

3.6.1.1 What it means

Interaction methods vary across different devices. Three main interaction methods should be considered:

Focus Based

This is the traditional mobile browser interface and is analogous to navigating with tabs on a desktop browser. As the user navigates through the page using the keypad the browser focus jumps from link to link, in more advanced devices there is 4-way navigation so a user can control the flow more easily.

Pointer based

Many of the more recent browsers have implemented a navigation influenced by desktop browsers. Using the navigation controls a pointer across the screen. Unlike the focus based devices the pointer can cover all aspects of the screen, not just links.

Touch based

Touch based devices allow the user to select links or other page elements directly with a finger or stylus. There is no concept of a pointer or focus.

3.6.1.2 How to do it

Particularly where content requires multiple links (ie back/forward in carousel) or where the user's interaction with links is designed to give them feedback, the following factors should be considered:

Focus

Pointer

Touch

3.6.2 Use Scripting for User Interface

3.6.2.1 What it means

Using script for dynamic parts of the page means that the view can be updated without a full page reload. Since re-rendering the page can be slow on a device, this greatly improves application usability.

3.6.2.2 How to do it

Script on the client can update specified parts of the page, identified either by the ID tag, the css classname, or from the document structure. The content of these tags can then be updated, and new nodes in the DOM can be created and destroyed.

3.6.3 Don't Move the Focus on Updates

3.6.3.1 What it means

The ECMAScript focus method can be used to move the focus to the part of a page that has changed. However, if unexpected, this can confuse or irritate the user, especially if returning to the previous focus is not easy. It can also make an application unusable, if the focus changes prevent the user from using other parts of the application.

3.6.3.2 How to do it

Use the ECMAScript focus method only if it is essential to the use of the application, and does not inhibit user control/interaction.

3.6.4 Group Closely Coupled Views onto the Same Page

3.6.4.1 What it means

Most applications consist of a number of views (e.g. an email application consists of an inbox and the message detail view). User experience is improved if switching between these views does not require a full page reload.

3.6.4.2 How to do it

Each view can be rendered in a DIV element which is hidden using css. Script can be used to show and hide the relevant views and their content updated with a background server request.

3.6.5 Use hash URLs to Preserve Browser History and Enable Deep Links

3.6.5.1 What it means

Web applications can show multiple views by showing and hiding content. However, this means it is not automatically possible to link directly to these views and the browser <back> button cannot be used to move between previous views. Usability is enhanced by enabling both of these features:

3.6.5.2 How to do it

Script can be used to update the browser URL and append a "hash" part to the URL. A hashed section of the URL is a standard mechanism for defining different views within an application. For example, an email application may support and respect URLs of this form:

3.6.6 Use URI Schemes for Device Functions

3.6.6.1 What it means

Standardized URI schemes (link formats) have been defined for some common device functions, e.g. making phone calls and managing phone address books. These URI schemes, if supported, can enable users to easily use these functions from Web applications.

3.6.6.2 How to do it

The Wireless Telephony Application Interface Specification (WTAI) defines the "wtai:" URI scheme for accessing a variety of telephone functions. WTAI support may be disclosed through a User Agent Profile document if published by the device vendor.

RFC3966 defines the "tel:" URI scheme for making phone calls. "tel:" is widely supported, since it is not a supported attribute in UAProf, support must be determined from the device vendor.

3.7 Handling Device Capability Variation

NOTE: This section is too detailed and requires significant editing. The Working Group is still evaluating the appropriate recommendations for this section and is interested in receiving feedback.

Device capability variation is a basic characteristic of the mobile Web environment. Web applications should adapt their content such that they render in an optimum way on as broad a range of target devices as possible.

3.7.1 Use Device Capability Detection

3.7.1.1 What it means

For some of the best practices included here, support is dependent upon application awareness of related device capabilities. At the current time, this awareness is limited to application server use of device capabilities information provided by the user-agent directly, or obtained from a Device Description Repository (DDR) based upon device identification, e.g. based upon the user-agent header.

3.7.1.2 How to do it

Typically used methods of device capabilities detection:

The type of information used will depend upon the way in which the request was received, and the support for the methods, e.g. headers, by specific user-agents. For example:

3.7.2 Use Reliable Methods for Determining Script Support

3.7.2.1 What it means

It can be tricky to determine the supported script capabilities for a device. Use of reliable methods is recommended.

3.7.2.2 How to do it

When it is unknown whether a user-agent supports a given functionality, use Javascript reflection to check for available functionalities. This avoids the error-prone approach of trying to parse the user-agent string to determine Javascript support. An example of how to use Javascript reflection:

Use Javascript Reflection and if statements
+ if(window.ActiveXObject) {
// Instantiate using new ActiveXObject } else if(window.XMLHttpRequest) {
// Instantiate using new XMHttpRequest }

3.7.3 Use Device Classification to Simplify Content Selection/Adaptation

3.7.3.1 What it means

It can be complex to select and adapt content based upon dynamic assessment of device capabilities. A commonly used alternate approach involves off-line assessment of devices with resulting assignment into "classes", e.g. "good", "better", "best". The definitions of the classes, and device assignment to classes, is typically Content Provider specific, i.e. based upon assessments specific to the needs of the Content Provider.

3.7.3.2 How to do it

Adapting Web application content and services to mobile devices may be simplified by assigning devices and user-agents (e.g. browsers or other Web applications as identified by the HTTP user-agent header, or other information) to "classes". The "richness" of the Web application as provided can then be more easily matched to the broad range of capabilities represented by the device class.

Device classification is partly subjective and partly objective. The aspects that affect the classification will vary depending upon the focus of the Web application, and the device/user-agent features it depends upon. Some example classes for web browsers may include:

Once the device/user-agent is identified, the assigned class can be obtained from the DDR used by the Content Provider, and content then provided consistent with the assigned class.

3.7.4 Provide Alternatives to Client-Side Scripting

3.7.4.1 What it means

Scripted applications, e.g. using asynchronous I/O methods or ECMAScript/Javascript in general, may not be supported by some browsers. Pages designed to use scripting will require alternate approaches in browsers that do not support scripting, so you should be prepared for that and provide similar functionality in case scripting is not available.

3.7.4.2 How to do it

Detect browser capabilities or user preferences, and react accordingly with graceful degradation or progressive enhancement of Javascript/ECMAScript.

Design targeting purely desktop/laptop audiences (where media="screen") tends to be structured to degrade gracefully if ECMAScript/Javascript is not present or if advanced capabilities like asynchronous I/O (and other "AJAX" techniques) are not supported. Design targeting a mixed audience of mobile (where media="handheld") and desktop/laptop users should be structured to both degrade gracefully (if ECMAScript/Javascript is not present) and likewise to progressively enhance page- and user-behavior capabilities (if ECMAScript/Javascript does turn out to be present).

Separate behavior from content and presentation, for graceful degradation and progressive enhancement.

Good logical design separates XHTML content (the "data model"), CSS presentation (the "view"), and ECMAScript/Javascript behavior (the "controller"). Designers targeting purely desktop/laptop audiences (where media="screen") tend to duplicate this in the physical site structure, placing each in its own file and having pages issue an HTTP request for each separately through use of the <link/> or <script/> tags. Designers targeting purely mobile (where media="handheld") audiences tend to interleave the three concerns into one physical payload/file delivered to the client in order to reduce per-request charges.


Designers targeting a mixed audience of mobile and desktop/laptop users can build Web pages which load sufficient ECMAScript/Javascript (in the <head/> element) to determine device display and interaction capabilities when first loaded. This allows for progressive enhancement, just as good structural design of XHTML allows for graceful degradation.


Techniques similar to progressive enhancement of CSS (see 5.9.5) may also be used to inject event-handling Javascript/ECMAScript code into files at request-time and to attach Javascript/ECMAScript behaviors at run-time for progressive enhancement. In the example below, page-scope variables and functions are declared in a <script/> element in the <head/> while run-time test code for progressive enhancement is declared in a <script/> element in the <body/> element (to allow the DOM to be loaded before the code runs):

[NOTE to WG: see http://chw.rit.edu/test/progressiveEnhancement.html for complete code as running example]

<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE html PUBLIC "-//WAPFORUM//DTD XHTML Mobile 1.2//EN"
  "http://www.openmobilealliance.org/tech/DTD/xhtml-mobile12.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en"> <head>
  <meta http-equiv="content-type" 
          content="application/vnd.wap.xhtml+xml; charset=utf-8" />
  <meta http-equiv="cache-control" content="no-cache" />
  <title>Javascript Insertion Test</title>
  <style type="text/css" media="all">
/* <![CDATA[ */
#testMe {
  border: thin solid red;
}
/* ]]> */
</style>
  <script type="text/javascript" charset="utf-8"> 
// <![CDATA[ 
var someVariable; 
var triggerTest = 480; 
function actualValue() {
  [...]
  return someRuntimeValue;
}
function setSomeVariable( newValue ) {
  [...]
}
// ]]>
  </script>
</head>
<body>
  <p id="testMe">
    Please click on this area to test this scripting example.
  </p>
  <script type="text/javascript" charset="utf-8"> 
// <![CDATA[ 
function thisFunction() {
  [do something, possibly using someVariable] } if( actualValue() >= triggerTest ) {
  setSomeVariable( 'some new value' );
  document.getElementById( targetID ).onclick = thisFunction; 
} 
// ]]>
  </script>
</body>
</html>

3.7.5 Provide for Both Graceful Degradation & Progressive Enhancement of CSS

3.7.5.1 What it means

CSS may be incompletely supported by some browsers. Pages using positioning and visibility control are not supported by some browsers.

Site design to support both desktop/laptop users and mobile device users will require alternate approaches for browsers that do not support positioning and visibility control. You should provide for both graceful degradation (in the case of no or minimal CSS support) and progressive enhancement (in the case of full positioning and visibility control support) of CSS by the client at run-time.

3.7.5.2 How to do it

Detect browser capabilities or user preferences and react accordingly.

Design targeting purely desktop/laptop audiences (where media="screen") tends to be structured to degrade gracefully: first if ECMAScript/Javascript is not present, and then if CSS is not supported. Design targeting a mixed audience of mobile (where media="handheld") and desktop/laptop users should be structured to also progressively enhance CSS. Advanced CSS capabilities should be separated from basic CSS, and inserted into the DOM by the client as appropriate at run-time.

Separate behavior from content and presentation, for graceful degradation and progressive enhancement.

Designers targeting a mixed audience of mobile and desktop/laptop users can build Web pages which load (using the <style/> tag in the <head> element) CSS for mobile audiences and (using the <script/> tag in the <head> element) sufficient ECMAScript/Javascript to determine device display and interaction capabilities first. This allows for progressive enhancement, just as good structural design of XHTML allows for graceful degradation.

The following example code illustrates a possible request-time payload aimed at a mixed mobile and desktop/laptop audience. In this case, if ECMAScript/ Javascript is present and if the screen-width is determined to exceed a minimum, then the display device is assumed to be a desktop/laptop (where per-download charges are unlikely to apply), an additional stylesheet is requested, and ithe new stylesheet is inserted into the DOM:

<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE html PUBLIC "-//WAPFORUM//DTD XHTML Mobile 1.2//EN"
  "http://www.openmobilealliance.org/tech/DTD/xhtml-mobile12.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en"> <head>
  <meta http-equiv="content-type" 
      content="application/vnd.wap.xhtml+xml; charset=utf-8" />
  <meta http-equiv="cache-control" content="no-cache" />
  <title>Example Payload for Progressive Enhancement</title>
  <style type="text/css" media="all">
/*
<![CDATA[ */
                         [put initial CSS here]
/* ]]>
*/
  </style>
  <script type="text/javascript" charset="utf-8"> 
// <![CDATA[ 
var triggerWidth = 480; 
function appendStylesheet( uriString, mediaTypeTarget ) {
                         [inject stylesheet into DOM here] 
} 
function getViewportWidth() {
                         [determine viewportWidth here] } 
function adaptToScreen( uriString ) {
  if ( getViewportWidth() >= triggerWidth ) {
    appendStylesheet( uriString, 'screen' );
  }
}
// ]]>
  </script>
</head>
<body onload="adaptToScreen( './stylesheets/bigScreen.css' );">
  [...]

In the above case, the base-CSS for mobile users is delivered along with ECMAScript/Javascript to determine client capabilities as a result of the initial request. Subsequent requests for CSS (and possibly other resources) allow for progressive enhancement where determined appropriate by client-side code.

Good physical design can take advantage of just-in-time technologies like "server-side includes" to assemble the above payload on demand, resulting in the <style/> and <script/> nodes being inserted at request-time. The following code in an HTML file would cause the server to insert (as above) site-wide <style/> and <script/> nodes at request-time in the payload actually being delivered at response-time:

[... replace style and script elements with:]
  <style type="text/css" media="all">
/*
<![CDATA[ */
<!--#include virtual="./stylesheets/content.css" --> 
<!--#include virtual="./stylesheets/tabNav.css" -->
/* ]]>
*/
  </style>
  <script type="text/javascript" charset="utf-8"> 
// <![CDATA[ 
<!--#include virtual="./javascripts/appendStylesheet.js" --> 
// ]]>
  </script>
[...]

Separating logical and physical design like this helps reduce site-wide maintenance costs and site-redesign difficulties as well as supporting graceful degradation and progressive enhancement of CSS.

Appendix: Best Practice Dependent Device Properties

[To include the set of minimum device properties supporting specific best practices.]

A Sources (Non-Normative)

The Best Practice statements have been assembled by the BPWG from a number of sources. Primary among those are:

While the Best Practice statements have mainly been assembled by secondary research, the sources for that research have in many cases been assembled from primary research. In addition, group members' contributions are to some extent informed by primary research carried out by their company.

B Related Reading (Non-Normative)

Readers interested in the topic of this document will find a variety of other publications of interest. As noted in the Scope paragraph above, topics such as internationalization and accessibility have been addressed separately by the W3C and have not been covered here.

The Character Model for the World Wide Web and other materials prepared by the W3C Internationalization (i18n) Activity cover important interoperability drivers for content prepared for the One Web and the mobile-services arena.

The Web Accessibility Initiative has prepared a variety of Guidelines and Techniques that likewise bear on the preparation and processing of content in and for the Web.

Section 3.2 Background to Adaptation above introduced the idea of content adaptation. Readers who contemplate implementing server-side adaptation will be interested in the ongoing work of the Device Independence Activity.

C Acknowledgements (Non-Normative)

D References (Non-Normative)

D.1 MWI References

to be added

D.2 Sources

to be added

D.3 Device Independence

XML
Delivery Context: Client Interfaces (DCCI) 1.0, W3C Candidate Recommendation 21 December 2007 (See http://www.w3.org/TR/DPF/)

D.4 Web, Protocols and Languages

XML
Extensible Markup Language (XML) 1.0 (Third Edition), Tim Bray, Jean Paoli, C. M. Sperberg-McQueen, Eve Maler, François Yergeau, Editors, W3C Recommendation, 04 February 2004 (See http://www.w3.org/TR/2004/REC-xml-20040204/)
XHTML-Basic
XHTML Basic 1.1, Shane McCarron, Masayasu Ishikawa, Editors, W3C Working Draft, 5 July 2006 (See http://www.w3.org/TR/xhtml-basic/)
CSS
Cascading Style Sheets (CSS1) Level 1 Specification, Håkon Wium Lie, Bert Bos, Editors, W3C Recommendation, 11 Jan 1999 (See http://www.w3.org/TR/REC-CSS1)
CSS2
Cascading Style Sheets, level 2 CSS2 Specification, Bert Bos, Håkon Wium Lie, Chris Lilley, Ian Jacobs, Editors, W3C Recommendation, 12 May 1998 (See http://www.w3.org/TR/REC-CSS2/)
HTTP1.0
Hypertext Transfer Protocol -- HTTP/1.0 Request for Comments: 1945, T. Berners-Lee, R. Fielding, H. Frystyk, May 1996 (See http://www.w3.org/Protocols/rfc1945/rfc1945)
HTTP1.1
Hypertext Transfer Protocol -- HTTP/1.1 Request for Comments: 2616, R. Fielding, J. Gettys, J. Mogul, H. Frystyk, L. Masinter, P. Leach, T. Berners-Lee, June 1999 (See http://www.w3.org/Protocols/rfc2616/rfc2616.html)

D.5 Other References

UAPROF
Open Mobile Alliance OMA-TS-UAProf-V2_0-20060206-A User Agent Profile Approved Version 2.0 � 06 Feb 2006 (See http://www.openmobilealliance.org/release_program/docs/UAProf/V2_0-20060206-A/OMA-TS-UAProf-V2_0-20060206-A.pdf)
WTAI
WAP Forum wap-268-wtai-20010908-a Wireless Telephony Application Interface Specification (See http://www.openmobilealliance.org/tech/affiliates/LicenseAgreement.asp?DocName=/wap/wap-268-wtai-20010908-a.pdf)
RFC 3966
The tel URI for Telephone Numbers, H. Schulzrinne. IETF, December 2004 (See http://www.ietf.org/rfc/rfc3966.txt)
RFC 2119
Key words for use in RFCs to Indicate Requirement Levels, S. Bradner. IETF, March 1997 (See http://ietf.org/rfc/rfc2119)