W3C

Mobile Web Best Practices 2.0

Basic Guidelines

W3C Editor's Draft 09 April 2008

This version:
http://www.w3.org/2005/MWI/BPWG/Group/Drafts/BestPractices-2.0/ED-mobile-bp2-20080409
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-20080327
Editors:
Bryan Sullivan, AT&T

Abstract

This document specifies Best Practices for delivering Web content to mobile devices. The principal objective is to enable development and delivery of great Web applications on mobile devices, through recommendations for exploitation of mobile device capabilities and delivery context.

The recommendations refer to Web applications as experienced on mobile devices. The recommendations necessarily reflect upon the processes by which the applications are developed and delivered, and the nature of the devices and user agents through which they are experienced. However the main focus is upon the applications themselves, including content that is delivered and presented through the applications.

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 2.0 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) through . 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 5 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 Phasing
     1.5 Relationship to other Best Practices and recommendations
     1.6 Longevity and Versioning
2 Requirements
     2.1 Personalization
     2.2 Security and privacy
     2.3 User awareness and control
     2.4 Use of cookies and redirection
     2.5 Conservative use of network traffic
     2.6 One Web
     2.7 Presentation Issues
     2.8 Interaction Issues
     2.9 Handling Device Capability Variation
     2.10 Handling Delivery Context Variation
     2.11 Resource Constraints
     2.12 Applicability to Non-Browser Web Runtime Environment
     2.13 Toolkit Developer Issues
3 The Mobile Context
4 Structure of Best Practice Statements
5 Best Practice Statements
     5.1 Personalization
         5.1.1 Use Automated Means for Obtaining Personalizing Information
         5.1.2 Retain Manually Entered Personalizing Information
         5.1.3 Simplify Manual Entry of Personalizing Information
     5.2 Security and privacy
         5.2.1 Protect Personal Information Used in Transactions
     5.3 User awareness and control
         5.3.1 Inform the User About Automatic Use of Networks
         5.3.2 Inform the User About Device Memory Impact for Application Installation and Use
         5.3.3 Inform the User About Use of Personal Information
         5.3.4 Provide Disclosures that are Timely and Accessible
         5.3.5 Provide Useful Control over Application Behavior
     5.4 Use of cookies and redirection
         5.4.1 Automatically Recover Cookie-Based Information
         5.4.2 Minimize Redirects in Server-Server API's
     5.5 Conservative use of network traffic
         5.5.1 Use Transfer Compression for Content
         5.5.2 Minimize Automatically Issued Network Requests
         5.5.3 Use Push Methods to Reduce Pull Traffic
         5.5.4 Minimize Application Size
         5.5.5 Minimize DOM Manipulation
     5.5.6 Minimize External Script Files
     5.6 One Web
         5.6.1 Offer Synchronized View for Multi-Device Capable Applications
     5.7 Presentation Issues
         5.7.1 Use Scripting for User Interface
         5.7.2 Retain Focus on Updates
     5.8 Interaction Issues
         5.8.1 Use URI Schemes for Device Functions
     5.9 Handling Device Capability Variation
         5.9.1 Use Device Capability Detection
         5.9.2 Use Reliable Methods for Determining Script Support
         5.9.3 Use Device Classification to Simplify Content Selection/Adaptation
         5.9.4 Provide Alternatives to Client-Side Scripting
         5.9.5 Provide for Both Graceful Degradation & Progressive Enhancement of CSS
     5.10 Handling Delivery Context Variation
     5.11 Resource Constraints
         5.11.1 Use Power-Efficient Methods
     5.12 Applicability to Non-Browser Web Runtime Environment
     5.13 Toolkit Developer Issues
6 Conformance and mobileOK
     6.1 Classes of Products
     6.2 Extensibility
7 Acronyms

Appendices

Appendix: Best Practice Dependent Device Properties
Appendix: Classification of Devices
A Sources (Non-Normative)
B Related Reading (Non-Normative)
C Acknowledgements (Non-Normative)
D References (Non-Normative)

List of Best Practices

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

  1. [AUTOMATE_PERSONALIZATION] Use Automated Means for Obtaining Personalizing Information

  2. [RETAIN_PERSONALIZATION] Retain Manually Entered Personalizing Information

  3. [SIMPIFY_MANUAL_ENTRY] Simplify Manual Entry of Personalizing Information

  4. [USE_POWER_EFFICIENT_METHODS] Use Power-Efficient Methods

  5. [PROTECT_PERSONAL_INFO] Protect Personal Information Used in Transactions

  6. [DISCLOSE_AUTOMATION] Inform the User About Automatic Use of Networks

  7. [DISCLOSE_MEMORY_IMPACT] Inform the User About Device Memory Impact for Application Installation and Use

  8. [DISCLOSE_PERSONAL_INFO_USE] Inform the User About Use of Personal Information

  9. [PROVIDE_EFFECTIVE_DISCLOSES] Provide Disclosures that are Timely and Accessible

  10. [PROVIDE_USER_CONTROL] Provide Useful Control over Application Behavior

  11. [RECOVER_COOKIES] Automatically Recover Cookie-Based Information

  12. [MINIMIZE_REDIRECT] Minimize Redirects in Server-Server API's

  13. [USE_CONTENT_COMPRESSION] Use Transfer Compression for Content

  14. [MINIMIZE_AUTOMATIC_REQUESTS] Minimize Automatically Issued Network Requests

  15. [USE_PUSH_METHODS] Use Push Methods to Reduce Pull Traffic

  16. [MINIMIZE_APPLICATION_SIZE] Minimize Application Size

  17. [MINIMIZE_DOM_MANIPULATION] Minimize DOM Manipulation

  18. [MINIMIZE_EXTERNAL_SCRIPTS] Minimize External Script Files

  19. [SYNC_VIEW_ACROSS_DEVICES] Offer Synchronized View for Multi-Device Capable Applications

  20. [USE_SCRIPTING_FOR_UI] Use Scripting for User Interface

  21. [RETAIN_FOCUS_ON_UPDATES] Retain Focus on Updates

  22. [USE_DEVICE_URI_SCHEMES] Use URI Schemes for Device Functions

  23. [DETECT_DEVICE_CAPABILITIES] Use Device Capability Detection

  24. [DETECT_SCRIPT_SUPPORT] Use Reliable Methods for Determining Script Support

  25. [CLASSIFY_DEVICES] Use Device Classification to Simplify Content Selection/Adaptation

  26. [MATCH_SCRIPTING_SUPPORT] Provide Alternatives to Client-Side Scripting

  27. [MATCH_CSS_SUPPORT] Provide for Both Graceful Degradation & Progressive Enhancement of CSS


  28. 1 Introduction

    1.1 Purpose of the Document

    This document sets out a series of recommendations designed to enable development and delivery of great Web applications on mobile devices.

    The recommendations are offered to creators, maintainers and operators of Web applications.

    1.2 How the Best Practices are Organized

    The document is organized as follows:

    1. Introduction. Describes the audience, purpose and scope of the document.

    2. Requirements. An illustration of the type of problems that the Best Practices are intended to address.

    3. Delivery Context. Discusses the environment within which mobile access to Web applications is realized, with particular reference to adaptation.

    4. Overview of Best Practices. A discussion of the organization of the Best Practices, and sources from which they were derived.

    5. Best Practices. The statements themselves.

    6. Conformance. A brief conformance statement.

    7. Appendices

      Sources

      Related Reading

      Acknowledgements

      References

    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.

    Our intention is to make it 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 of our 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 (BP2) follow in the footsteps of the Mobile Web Best Practices 1.0, (BP1), for which the scope was laid out in "Scope of Mobile Web Best Practices" [Scope] . In summary, BP1 refered primarily to the extension of Web browsing onto mobile devices.

    BP2 extends the focus to Web applications generally, which means an application that is accessed and presented via Web technologies. Web applications represent a spectrum of services and content, at the simple end of which are typical Web browsing sites, presented in browsers, which were the focus of BP1. The BP2 focus includes further recommendations for addressing delivery context issues and for use of Web technologies more advanced than covered in BP1, which apply both to browsers and non-browser web runtime environments.

    Web applications considered in scope for BP2 typically have many of the following characteristics:

    The recommendations refer to applications as experienced on mobile devices. The recommendations necessarily reflect upon the processes by which the applications are developed and delivered, and the nature of the devices and user agents through which they are experienced. However the main focus is upon the applications themselves, including content that is delivered and presented through the applications.

    1.4.1 Phasing

    As discussed in the Scope document [Scope] there are many aspects to Mobile Web Best Practices. BP2 represents the second phase of the Best Practices development, i.e. beyond "Traditional Web Browsing".

    1.4.1 Criteria for Best Practice recommendations

    The BP2 is not intended as a landscape document, e.g. a general survey of technologies and related issues in the mobile context. Recommendations are included here if they meet specific criteria:

    1.5 Relationship to other Best Practices and recommendations

    These recommendations follow in the footsteps of the 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].

    1.6 Longevity and Versioning

    The Best Practices have been written at a level of generality that allows them to be applicable across a range of Web technologies. They have been written with mobile user experience aspects in mind, which over time will change, but should remain relevant as technology evolves.

    This document may be reviewed from time to time. When necessary, an updated version will be released with clear documentation as to the changes that have been introduced.

    2 Requirements

    This section discusses the requirements of the Mobile Web Best Practice statements in section 5. The statement of requirements is intended to be illustrative rather than exhaustive or complete.

    2.1 Personalization

    Personalization increases the value of content and services to users, which is important in the mobile environment due to the extra effort necessary to find relevant content, interact with applications, and the limited output possible in mobile devices. In the PC environment, users have a variety of useful/easy input methods and controls making it easier to input personalizing information and surf to the content they want, and can more easily scan a large amount of content for the bits that are relevant to them. Each of these aspects are more limited, and thus more difficult to address in the mobile environment. The overall goal for personalization in the mobile context is to use user-friendly methods.

    2.2 Security and privacy

    Related to the more frequent dependence upon personal information is the need to secure that information from eavesdropping or tampering when exchanged over the Internet. In order to ensure privacy and information accuracy you should only used trusted information, and protect any personally identifiable information, especially user identifiers or keys to user identity. While this also applies for PC based applications, for mobile applications additional options are typically available for access to trusted personalizing information, and the efficiency of methods for personal information security need to be more carefully considered. The overall goal for security is to use efficient methods to protect any personally identifiable information, and especially user identifiers or keys to user identity.

    2.3 User awareness and control

    Applications should ensure the user is aware of sensitive functions, i.e. that may affect the service experience, and is offered some options for user control.

    2.4 Use of cookies and redirection

    In BP1, HTTP cookies and redirection were recommended to "not be relied upon" due to constraints of limited-capability mobile browsers and slower mobile networks. BP2 however recognizes that cookies are widely supported by current mobile browsers, and mobile network speeds have considerably increased since BP1. Thus while the BP1 recommendations are still useful to consider when the delivery context can't be determined, BP2 focuses on use of HTTP cookies and redirection for capable browsers and mobile networks.

    HTTP cookies and redirection fulfill useful purposes in the mobile context. Cookies support statefulness and personalization in browsers, two considerations which can simplify the user experience and add value to content and services. Redirect supports server-server interaction via the browser, which is often essential for distributed services which rely upon partitioning of service functions across different servers.

    As compared to their use for web browser applications, cookies and redirect may play less of a role in maintaining statefulness and personalization for for web applications in general. Application-specific methods may be used, and may include use of more advanced technologies that are not available to some browsers. However, support for statefulness and personalization will still need to consider similar issues, e.g. state preservation/recovery and traffic overhead. As well, distributed services may still rely upon redirect for web applications.

    The overall goal is to set reasonable expectations on the impact for use of cookies and redirect in service delivery to browsers and web applications, and to address alternatives for maintaining statefulness and personalization.

    2.5 Conservative use of network traffic

    In mobile networks, the amount of network traffic that web applications generate can have a very significant impact on service cost, especially for applications that autonomously interact with network-based services. These costs can be borne by the user and/or network service provider. Users with usage-based service plans can find themselves responsible for huge charges. Network service providers can bear these costs for users that subscribe to "bucket" or unlimited service plans, and as a result may only recommend or support efficient applications for use with such plans. The overall goal is that users are informed of the potential impact of application operation, and that regardless of the user's service plan, applications use network resources conservatively.

    2.6 One Web

    Web applications should be designed with consideration that users often want to use multiple/different devices to access services. Keeping such goals in mind will enhance the usefulness of web applications, especially those that do offer multi-device access options, e.g. mobile and desktop.

    2.7 Presentation Issues

    As addressed in BP1, presentation issues of mobile devices can also be applicable to web applications in general, e.g.

    • variations in page rendering/layout in different devices
    • context/overview constraints due to limited screen size and the limited amount of visible material
    • dependency upon scrolling through material
    • presentation space expense for images and navigation links
    • overall lack of site/content cohesiveness due to fragmentation of display and site structure

    However, advanced web browser features and evolving web technologies are adding additional specific issues that need to be addressed in the mobile context, including:

    • support for popup windows and layers which can overlap partially/fully
    • support for popup menus
    • dynamic changes in screen orientation
    • need for content adaptation (e.g. image resizing/cropping) due to variable presentation space
    • overall usability issues resulting from more complex presentation options

    2.8 Interaction Issues

    As addressed in BP1, issues of interaction with applications on mobile devices can also be applicable to web applications in general, e.g.

    • limited keypad, e.g. 16-key, leading to difficulty in selecting \characters, and the need for application help in selecting the input character type
    • physical keying difficulty due to small key size
    • form field navigation
    • overall difficulty in entering text impacting usability, e.g. for forms and long URLs
    • no pointing device
    • variations in softkeys for navigation and local application menus

    However, evolution of mobile devices is adding additional specific issues that need to be addressed in the mobile context, including:

    • new pointing methods, e.g. touch screens
    • dynamic changes in keyboard layout, e.g. between 16-key, querty, and soft keyboards
    • solve the top left navigation problem [need a definintion of what this is, and consideration of whether it is actually testable]

    2.9 Handling Device Capability Variation

    Device capability variation is a basic characteristic of the mobile web environment. The need to consider it when selecting, adapting, and delivering content and services is essential effectiveness of mobile web applications.

    Addressing this challenge also depends upon knowing which device and/or user-agent is in use (or intended to be served by the application), and its specific capabilities.

    2.10 Handling Delivery Context Variation

    Delivery context variation is another basic characteristic of the mobile web environment. Variation occurs in several aspects, e.g.

    BP2 addresses these aspects in the following ways:

    2.11 Resource Constraints

    As addressed in BP1, the basic aspects of delivery context in the mobile environment, and how awareness of delivery context relates to the goal of the "one web", also apply to web applications in general.

    2.12 Applicability to Non-Browser Web Runtime Environment

    The focus of the BP2 document is on producing Best Practices that apply to the browser sandbox, while recognising that they may have broader applicability to the Web Runtime (CSS, HTML, Javascript, DOM, Persistent Storage, additional libraries, no browser chrome, cache, etc.), esp Mobile Widgets

    2.13 Toolkit Developer Issues

    Audience of BP2 document will include CPs as well as Ajax and other toolkit developers.

    3 The Mobile Context

    Document will include a descriptive passage about mobile context (including device, browser, network) we are talking about.

    4 Structure of Best Practice Statements

    The Heading

    The functional area that is addressed by the statements.

    The Statements

    One or more Best Practice statements, identified in the following way:

    [EXAMPLE] This is a Best Practice statement.

    What it means

    An explanation of the significance of the statements under this heading.

    How to do it

    A discussion of techniques and some suggestions as to how to implement.

    What to Test

    The aspects of the delivered content that an external validator could examine to assess conformance with the Best Practice statements. This section is not present for process related statements.

    In this section it is noted whether the statement is Machine Testable (Automated testing is possible) or Human Testable (Testing requires human assessment). Some Best Practices are partially machine testable, i.e. based on the result of an automated test, some human interaction may be required. In such cases both a Machine Testable and a Human Testable statement are present.

    Some Best Practice statements use words such as "minimize" and "avoid" which are intentionally non-prescriptive. This is in order to provide guidance while leaving room to accommodate a wide variety of applications whose requirements cannot be anticipated. It also allows creativity and diversity within the same Best Practice framework.

    References

    Where appropriate, references to related WCAG points and other immediate references from the preceding text.

    5 Best Practice Statements

    5.1 Personalization

    5.1.1 Use Automated Means for Obtaining Personalizing Information

    5.1.1.1 What it means

    Personalized services are enabled by content provider awareness of personalizing information, e.g. user identity, preferences, characteristics. Personalized services should be capable of using automated means of obtaining such personalizing information, in order to reduce user effort in obtaining the personalized service.

    5.1.1.2 How to do it

    Content providers can often use personalizing information that is directly forwarded by network proxies, e.g. as HTTP headers. Such information may be made available by network operators through developer and content provider programs.

    Content providers can also use information, e.g. user credentials, which is provided directly by the user on a first access, and then automatically provided by the user-agent on subsequent accesses. Recommended methods for this include use of HTTP Digest Authentication to identify the user, or a form-field entry of a user identity which is delivered over a secure connection and stored in a cookie or server database. The key objective here is that the personalizing information (in this case a user's identity) does not have to be manually entered often.

    Content providers may also be able to acquire personalizing information directly through features of the user-agent, e.g. via Delivery Context Client Interface (DCCI)methods.

    5.1.2 Retain Manually Entered Personalizing Information

    5.1.2.1 What it means

    Personalized services that rely upon manual entry of information should retain that information to avoid the need to re-enter it upon each site access or use session. Users are likely to quit using services that ask for the same information often.

    5.1.2.2 How to do it

    Information retention is possible by using cookies, as hidden information in content (e.g. forms or URL parameters), in server-side databases, etc. The duration of retention should be matched to the type of application and typical user session profile, e.g. how often users typically access the application and how long they interact with it during each use.

    5.1.3 Simplify Manual Entry of Personalizing Information

    5.1.3.1 What it means

    If the user must be asked to enter information to personalize a service, the application should simplify what they have to enter, i.e. minimize the effort required to manually personalize the service. Users are likely to quit using services that ask for too much manual information entry, especially if obviously simpler forms of entry are not provided.

    5.1.3.2 How to do it

    BP1 included various generic recommendations on how to reduce user input requirements. In addition, other techniques can simplify input of personal information, e.g.:

    • require only entry of variable information, e.g. if an email address domain can be assumed, require only the username, and don't require the user to enter "@domain".
    • allow abbreviations, e.g. of locations

    5.2 Security and privacy

    5.2.1 Protect Personal Information Used in Transactions

    5.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. This will ensure the confidentiality and integrity of the information. Information is personally identifiable if it is by itself directly related to an individual, e.g. a user's public identity such as name or phone number, or can be correlated to an individual by being exchanged along with other personally identifying information.

    5.2.1.2 How to do it

    Public user identities should only be exchanged between user-agent and content server using secure methods, e.g. HTTPS, or as securely hashed information through a strong secure hash algorithm. 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.

    Since information is not personally identifiable unless it can be associated with an individual, e.g. a zip code which is by itself not personally identifiable, such information can be exchanged in the clear if the correlating information is itself secure, e.g. as a securely hashed identifier. As long as an application meets the basic objective that user identities are protected during exchange, other information can be exchanged in the clear.

    5.3 User awareness and control

    5.3.1 Inform the User About Automatic Use of Networks

    5.3.1.1 What it means

    Users should be informed if applications will make automatic data requests that can impact service cost, and should be given information that will help the user assess the significance of that impact. While the significance ultimately may depend upon information that only the user knows (e.g. their data service plan), having such notices up-front can avoid unexpected negative side-effects, e.g. significant usage charges or effect upon battery life.

    5.3.1.2 How to do it

    Applications should disclose, in a clear and useful way, the basic nature of their automatic use of the internet for data exchange, e.g.:

    • how often the application will interact via the internet, e.g. every 5 minutes, hourly, daily
    • how long the automatic behavior will continue
    • roughly how much data traffic will occur, e.g. in kilobytes, in a given period e.g. over each day, month, or per use of the application

    5.3.2 Inform the User About Device Memory Impact for Application Installation and Use

    5.3.2.1 What it means

    Users should be informed of impacts to device memory for installable web applications. Because mobile devices typically are memory-constrained, the effect of application installation and use can be much more significant than in other devices.

    5.3.2.2 How to do it

    The following information should be disclosed:

    • the installed size of the application
    • the percentage of free device memory consumed by the installation, and the amount of free device memory left after installation
    • the typical/maximum amount of device memory to be used for application data

    The most effective timing and method of resource impact disclosure will vary depending upon the type of web application, as described in section 5.3.4.

    5.3.3 Inform the User About Use of Personal Information

    5.3.3.1 What it means

    While use of personal or contextual information can enhance service effectiveness, applications should ensure that the user is aware of such information use and exchange.

    5.3.3.2 How to do it

    The following information should be disclosed:

    • the types of personal information (data or contextual information, e.g. location) that will be used by the application
    • what data will be exchanged via the internet

    5.3.4 Provide Disclosures that are Timely and Accessible

    5.3.4.1 What it means

    Disclosures about application behavior are useful (i.e. result in user awareness of the implications of using an application) only if they are provided at a useful time and in useful ways. A non-useful disclosure is practically a non-disclosure.

    5.3.4.2 How to do it

    Disclosures should be provided during application selection, install, on first runtime, or first use of sensitive functions.

    Disclosures should be automatically provided e.g. as a user dialog, or easily accessible to the user e.g. via an "about this application" menu option.

    5.3.5 Provide Useful Control over Application Behavior

    5.3.5.1 What it means

    Unless a sensitive application behavior is essential to the application, users should be given the option to control the behavior. If the behavior is essential to the application, users should be given the option to opt-out of application use.

    5.3.5.2 How to do it

    Users should be given easy-to-use controls to personalize application behavior, e.g.

    • Configure automatic operations, e.g. content update schedules
    • Manage data memory use
    • Select privacy/security options

    If user control over sensitive application functions is not provided, users should be given the chance to opt-out for the function, or to terminate the application.

    User control preferences should be saved by the application to avoid the need to reenter them each time the application is used.

    5.4 Use of cookies and redirection

    5.4.1 Automatically Recover Cookie-Based Information

    5.4.1.1 What it means

    Cookies may play an essential role in application design. However since they may be lost, applications should be prepared to recover the cookie-based information when necessary. If possible, the recovery should use automated means, so the user does not have to re-enter information.

    5.4.1.2 How to do it

    Server databases can be used to store user information with persistence longer than typical session or cookie lifetime. Applications can be designed to recognize loss of cookie information, and direct the user or user-agent to a resource through which the information can be recovered from a database server. After recovery, the user or user-agent may be directed to a server which then provides service based upon the restored cookie information. These methods can increase information persistence, while limiting database server expense.

    5.4.2 Minimize Redirects in Server-Server API's

    5.4.2.1 What it means

    User-agent redirect is a typical method for a service to automatically obtain necessary information from a different server. Such redirect based API's are very common in web applications, and play an useful role in automated personalization for mobile web applications, e.g. to avoid manual information entry. However latency, efficiency, and interoperability considerations benefit from minimizing the number of automated redirects in a sequence, for this purpose.

    5.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, e.g. to a second information-providing server based upon the information obtained from the first information-providing server, a landing page can be used to break up the overall sequence, into two automated redirect sequences with a user "continue" click in the middle. This has the effect of reducing the apparent latency for the user, but should be balanced against the need for an extra user action, as four redirects in sequence (when necessary) are rarely an interoperability issue.

    5.5 Conservative use of network traffic

    Web applications that autonomously interact with network-based services should be designed to minimize the overhead of network traffic for such automatic functions. Such web applications are refered to here as "autonomously interacting web applications".

    5.5.1 Use Transfer Compression for Content

    5.5.1.1 What it means

    Compress content for efficiency in delivery. Balance use of compression with the potential cost, e.g. to battery life for compress/uncompress operation. Use techniques if possible that are more efficient, e.g. tokenization.

    5.5.1.2 How to do it

    HTTP 1.1 compression, which typically uses gzip or deflate as algorithms, is a widely supported method of transfer encoding for delivery optimization, and is most useful for text-based content e.g. markup languages and documents. Typical performance for HTTP compression use is 5:1 compression ratio for web pages, which also translates into a 5x latency improvement. To use HTTP compression, web servers should be configured to serve web pages using HTTP 1.1 compression (gzip or deflate), for both upload and download transactions.

    For tokenization, examples that may be supported include:

    • Efficient XML Interchange, EXI
    • WAP Binary XML encoding (WBXML)

    Explain and expand upon the difference between use of encoding as a transport compression technique vs. an application compression technique. Note that transfer compression may not be supported for all network request techniques.

    5.5.2 Minimize Automatically Issued Network Requests

    5.5.2.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. For applications that automatically issue network requests, e.g. dynamically updating applications built using AJAX methods and XMLHttpRequest in particular, managing data usage should be a key consideration.

    5.5.2.2 How to do it

    Overall data usage effectiveness can be improved by:

    • Applications can minimize the number of interactions with the server, e.g. via XMLHttpRequest, by following some basic guidelilnes, e.g.:
      • wait until there is sufficient value to the user before sending requests, i.e. focus on how the request improves the user exerience
      • if there is no direct value to the user from sending individual requests, bundle transactions by combining multiple operations into one, e.g. for prefetching data that is known to be useful at a later time
    • Applications can vary network request intensity based upon the current value to the user, depending e.g. upon whether the user is actively using the application, whether new information is ready to be uploaded/downloaded, etc. Applications that are designed to "back off" automatic behaviors during low-value periods can improve the overall cost effectiveness of their use. Example criteria for determining the useful transaction rate:
      • based upon intensity of user interaction with the application, e.g. if use slows down considerably for an extended period, the application may assume a lower user benefit from network traffic
      • based upon success ratio of network transactions, e.g. number of messages received for mail/social-networking applications, news feed items published, etc
      • based upon typical usage patterns, e.g. reduced automated transactions at night or periods of typical low usage/success
    • If possible, use awareness of the current serving bearer network type, and roaming status, to select an appropriate intensity of network requests

    5.5.3 Use Push Methods to Reduce Pull Traffic

    5.5.3.1 What it means

    Network-initiated content delivery ("push") methods can significantly reduce network traffic overhead, as compared to conventional polling (scheduled "pull") methods. While scheduled pull is a useful method for content that is regularly published, e.g. news/traffic/weather etc., some service types such as messaging/social-networking and "breaking news" monitoring can greatly benefit from use of push methods in terms of overall traffic effectiveness and timely content delivery.

    5.5.3.2 How to do it

    Push method support may be disclosed through a User Agent Profile document if published by the device vendor, and may be known through other means e.g. a DDR.

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

    5.5.4 Minimize Application Size

    5.5.4.1 What it means

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

    Developers sometimes don't consider the impact of the size of their application content, e.g. web pages, on mobile browsers. Recognizing that you are developing for a mobile web application, and using effective techniques for minimizing the overall application size, will improve the user experience for mobile web applications.

    5.5.4.2 How to do it

    Optimize use of CSS, e.g.:

    • Avoid overuse of nested css classes that can bloat repeated blocks of content. Instead, make good use of selectors to minimize the size of repeated blocks of HTML. Bear in mind that css is easier to cache than generated HTML pages.
    • The cost of CSS optimization needs to be balanced against impacts to maintainability. A way to retain maintainability is to optimize the CSS at point of delivery, instead of designing optimizations into the application.

    5.5.5 Minimize DOM Manipulation

    5.5.5.1 What it means

    Developers sometimes use scripting to create basic framework parts of their document. This has a higher cost in terms of content size and battery, rather than creating the framework in HTML.

    5.5.5.2 How to do it

    Use markup language to create the minimal page framework and flesh out repetitive/dynamic aspects of the page using javascript. For example:

    • For a page displaying 100 contacts, the data for those contacts is much more compactly transmitted as a JSON string [JSON] than as fully-rendered HTML.
    • The framework page ideally contains no dynamic data so it can be much more aggressively cached.
    • A "loading" spinner can be displayed while an asynchronous request is made to get the guts of the data. Since a small and/or aggressively cached html page would load quickly this creates a better user-experience overall.

    5.5.6 Minimize External Script Files

    5.5.6.1 What it means

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

    When an application depends upon multiple external script files, it typically must retrieve them separately from the main resource (e.g. web page) itself. This can increase data usage and service latency. Overall reduction of the number and size of script files can avoid these effects.

    5.5.6.2 How to do it

    If your application depends upon external scripts:

    • Reduce the number of HTTP GETs required to retrieve the script files, e.g. by
      • Keep the number of script files to a minimum, e.g. by combining several script files into one
      • Send the scripts and main page together as a multipart/related package
    • Reduce the size of your script files, e.g. by
      • Removing whitespace and comments
      • Making variable names in the code shorter
      • Use HTTP 1.1 compression [5.5.1 Support HTTP 1.1 Compression] when sending script files

    Note that caching can also diminish the overhead for transfer of external script files, however as script files are collected into single packages, the efficiency of caching may diminish. So you should seek an optimum balance between script aggregation and cache efficiency..

    See http://developer.yahoo.com/yui/compressor/ for an example approach to script compression.

    5.6 One Web

    5.6.1 Offer Synchronized View for Multi-Device Capable Applications

    Editor's note: This is a placeholder for input re the ETRI "seamless content mobility" input paper.

    5.6.1.1 What it means

    Users may have access to applications from both a deskop user-agent and mobile user-agents, e.g. as described in [ref to BP1 3.1 One Web].

    5.6.1.2 How to do it

    If available as a server feature, provide a synchronized (i.e. current) view of user data when a multi-device enabled application is accessed from a mobile device.

    5.7 Presentation Issues

    5.7.1 Use Scripting for User Interface

    5.7.1.1 What it means

    Use script for the dynamic aspects of the user interface

    5.7.1.2 How to do it

    Use script for the dynamic aspects of the user interface

    5.7.2 Retain Focus on Updates

    5.7.2.1 What it means

    The ECMAScript focus method can be used to move the focus to the part of a page that has changed, e.g. for automatically updating pages. 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.

    5.7.2.2 How to do it

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

    5.8 Interaction Issues

    5.8.1 Use URI Schemes for Device Functions

    5.8.1.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.

    5.8.1.2 How to do it

    If you want the user to be able to easily take a device-specific action such as making a phone call to a number included in a web page, use URI schemes supported by the device. This will allow the user to take the action using a normal means, i.e. clicking a link.

    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, and may be known through other means e.g. a DDR.

    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 or through a DDR.

    5.9 Handling Device Capability Variation

    5.9.1 Use Device Capability Detection

    5.9.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.

    5.9.1.2 How to do it

    Typically used methods of device capabilities detection:

    • The "user-agent" header can be used to identify the device and/or user-agent, with detailed device capabilities then retrieved from a DDR.
    • The "accept" header can be used to indicate specific MIME types compatible-to/preferred-by the user-agent.
    • The "x-wap-profile" header (User Agent Profile or UAProf) can be used both as device identification and as a source for detailed device capabilities info.
    • Retained information about the current/last used device for the specific user, can be used when preparing content for delivery to the user-agent at a later time.

    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:

    • for requests received directly from the user-agent, based upon information from the user-agent directly or forwarded by intermediaries
    • for requests received from other intermediaries, information as available from the intermediary, e.g.
      • for SMS-interworking gateways, the user's phone number

    5.9.2 Use Reliable Methods for Determining Script Support

    5.9.2.1 What it means

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

    5.9.2.2 How to do it

    When it is unknown whether a user-agent supports Javascript, 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 }

    5.9.3 Use Device Classification to Simplify Content Selection/Adaptation

    5.9.3.1 What it means

    It can be complex to select and adapt content based upon dynamic assessmement 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.

    5.9.3.2 How to do it

    [Placeholder for guidance on building device classes and assigning devices to them]

    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.

    5.9.4 Provide Alternatives to Client-Side Scripting

    5.9.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.

    5.9.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>
    

    5.9.5 Provide for Both Graceful Degradation & Progressive Enhancement of CSS

    5.9.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.

    5.9.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.

    5.10 Handling Delivery Context Variation

    5.11 Resource Constraints

    5.11.1 Use Power-Efficient Methods

    5.11.1.1 What it means

    Various design techniques can negatively impact battery life. These should be avoided and alternate techniques used where possible, to Use Power-Efficient Methods.

    5.11.1.2 How to do it

    Use script only for the dynamic aspects of the user interface. DOM manipulation and creation of new nodes can consume a lot of battery at the device side, so as much as possible create user interface elements using the markup language and modify (if needed) those elements using scripting. For example:

    • When a page is first served from the server side, it should contain all the markup that declares and populates user interface elements (forms, selects, input, etc). If rich interactions are needed later then use scripting to mutate or modify the DOM of the page.
    • Update existing elements for new content, instead of creating new high-level elements. Elements that must be added should be appended after the focus point as a parent of an existing element, instead of the document. For example, use an existing <div> element as the parent for new content, without removing/recreating the parent <div> itself. (from http://www.unc.edu/webaccess/training/ajax/ajax_best_practices.pdf)

    5.12 Applicability to Non-Browser Web Runtime Environment

    [It may not be necessary to address this specifically, as our current approach is that if a best practice is useful, it is useful regardless of the runtime environment the application is executing under.]

    5.13 Toolkit Developer Issues

    6 Conformance and mobileOK

    The Best Practice statements are intended to be capable of having conformance statements constructed around them in support of the mobileOK trustmark and for other purposes. Work on the mobileOK trustmark will develop specific recommended requirements for a trustmark, which will be based on some profile, or subset, of the statements in this document.

    As such, the mobileOK trustmark will serve as the main conformance claim for the Best Practices document.

    All of the Best Practice statements have a fragment identifier to allow formal reference to them and allow the construction of compliance claims that refer to them.

    6.1 Classes of Products

    This specification applies to one class of product: content delivered to a mobile device, including the metadata transferred as part of the delivery protocol.

    6.2 Extensibility

    This specification may be compatible with other specifications that describe a different set of requirements for content, insofar as such requirements do not conflict with the current specification.

    7 Acronyms

    DDR
    Device Description Repository. A system hosting device capability information, for use by content providers and application developers in selecting, adapting, and delivering content and services based upon the capabilities of the device in use.

    Appendix: Best Practice Dependent Device Properties

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

    Appendix: Classification of Devices

    [Address device classification as a common practice through examples of classes and related characteristics.]

    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:

    "Good": Serve these devices very basic pages. These devices are typically WAP1 or WML-only handsets with black and white screens. Ringtones are supported, but MIDP applications, wallpapers, and scripted applications are not. "Good" devices also include such color-screen WML phones on which pictures can be presented through the browser, and javascript applications can be emulated by web servers. Some devices in this category may claim xHTML support, but have slow processors, or the supported xHTML is incomplete.

    "Better": These devices have solid xHTML support with color screens, and support MIDP, graphics, and ringtones. However they do not support scripted applications.

    "Best": The "best" device category includes features from the "better" category plus streaming video capabilities, UMTS/HSDPA, and special audio clients. Scripted applications may be supported, but script support likely requires verification before use.

    A Sources (Non-Normative)

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

    • to be added

    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)

    • to be added

    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)