index.html 90.9 KB

Raw Blame History Permalink

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
  <head>
    <title>Mobile Web Application Best Practices</title>
    <meta http-equiv="content-type" content="text/html; charset=UTF-8" />
    <link href="http://www.w3.org/StyleSheets/TR/W3C-REC" type="text/css"
          rel="stylesheet" />
    <style type="text/css">
      ul.coverage_list li { text-indent: -3em; padding-left: 3em; list-style-type: none;}

      code           { font-family: monospace; }
      .comment  {background-color: #FFc0c0;}

      div.constraint,
      div.issue,
      div.note,
      div.notice     { margin-left: 2em; }

      ol.enumar      { list-style-type: decimal; }
      ol.enumla      { list-style-type: lower-alpha; }
      ol.enumlr      { list-style-type: lower-roman; }
      ol.enumua      { list-style-type: upper-alpha; }
      ol.enumur      { list-style-type: upper-roman; }

      .stmt, .stmt1
      {   border: 1px solid black ;
      background-color: #c0e0e0;
      padding: 5pt}
      .ednote {border: 1px dashed black ;
      background-color: #FFc0c0}
      .new {background-color: #FFFF80}
      .note {background-color: #00FFFF}

      div.exampleInner pre { margin-left: 1em;
      margin-top: 0em; margin-bottom: 0em}
      div.exampleOuter {border: 4px double gray;
      margin: 0em; padding: 0em}
      div.exampleInner { background-color: #d5dee3;
      border-top-width: 4px;
      border-top-style: double;
      border-top-color: #d3d3d3;
      border-bottom-width: 4px;
      border-bottom-style: double;
      border-bottom-color: #d3d3d3;
      padding: 4px; margin: 0em }
      div.exampleWrapper { margin: 4px }
      div.exampleHeader { font-weight: bold;
      margin: 4px}
      p { margin-bottom: 15px }
    </style>
  </head>

  <body>

    <div class="head">
      <p><a href="http://www.w3.org/"><img src="http://www.w3.org/Icons/w3c_home" alt="W3C" height="48" width="72" /></a></p>

      <h1><a id="title" name="title">Mobile Web Application Best Practices</a></h1>

      <h2><a id="w3c-doctype" name="w3c-doctype">W3C Recommendation 14 December 2010</a></h2>

      <dl>
        <dt>This version:</dt>
        <dd><a href="http://www.w3.org/TR/2010/REC-mwabp-20101214/">http://www.w3.org/TR/2010/REC-mwabp-20101214/</a></dd>
        <dt>Latest version:</dt>
        <dd><a href="http://www.w3.org/TR/mwabp/">http://www.w3.org/TR/mwabp/</a></dd>
        <dt>Previous version:</dt>
        <dd><a href="http://www.w3.org/TR/2010/PR-mwabp-20101021/">http://www.w3.org/TR/2010/PR-mwabp-20101021/</a></dd>
        <dt>Editors:</dt>
        <dd>Adam Connors, Google</dd>
        <dd>Bryan Sullivan, AT&amp;T (until 2008)</dd>
      </dl>

      <p>Please refer to the <a href="http://www.w3.org/2010/12/mwabp-errata.html"><strong>errata</strong></a> for this document, which may include some normative corrections.</p>

      <p>See also <a href="http://www.w3.org/2003/03/Translations/byTechnology?technology=mwabp"><strong>translations</strong></a>.</p>

      <p class="copyright"><a href="http://www.w3.org/Consortium/Legal/ipr-notice#Copyright">Copyright</a> ©2010 <a href="http://www.w3.org/"><acronym title="World Wide Web Consortium">W3C</acronym></a><sup>®</sup> (<a href="http://www.csail.mit.edu/"><acronym title="Massachusetts Institute of Technology">MIT</acronym></a>, <a href="http://www.ercim.eu/"><acronym title="European Research Consortium for Informatics and Mathematics">ERCIM</acronym></a>, <a href="http://www.keio.ac.jp/">Keio</a>), All Rights Reserved. W3C <a href="http://www.w3.org/Consortium/Legal/ipr-notice#Legal_Disclaimer">liability</a>, <a href="http://www.w3.org/Consortium/Legal/ipr-notice#W3C_Trademarks">trademark</a> and <a href="http://www.w3.org/Consortium/Legal/copyright-documents">document use</a> rules apply.</p>
    </div>
    <hr />

    <div>
      <h2><a id="abstract" name="abstract">Abstract</a></h2>

      <p>The goal of this document is to aid the development of rich and dynamic mobile Web applications. It collects the most relevant engineering practices, promoting those that enable a better user experience and warning against those that are considered harmful.</p>

      <h2><a id="status" name="status">Status of This Document</a></h2>

      <p><em>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 <a href="http://www.w3.org/TR/">W3C technical reports index</a> at http://www.w3.org/TR/.</em></p>

      <p>This is the <strong>W3C Recommendation</strong> of Mobile Web Application Best Practices. This document was developed by the <a href="http://www.w3.org/2005/MWI/BPWG/">Mobile Web Best Practices Working Group</a> as part of the <a href="http://www.w3.org/Mobile/">Mobile Web Initiative</a>.</p>

      <p>Since publication as a Proposed Recommendation on <a href="http://www.w3.org/TR/2010/PR-mwabp-20101021/" title="W3C Proposed Recommendation of the Mobile Web Application Best Practices">21 October 2010</a>, the Working Group clarified that alternative compression formats (such as EXI) referred to in section <a href="#bp-conserve-compress">3.4.1 Use Transfer Compression</a> may not share some of the impediments of common compression formats. A <a href="diff.html" title="Differences between Proposed Recommendation and Recommendation of Mobile Web Application Best Practices">diff version</a> is available. No substantive change has been made.</p>

      <p>The document contains statements that may be regarded as forward-looking when this document is published (14 December 2010). Examples provided in the <em>How to do it</em> sections sometimes reference on-going works on technologies that the Working Group expects to become prevalent in the development community soon. These sections should be taken with a grain of salt, depending on the actual evolution of these technologies. The best practices statements should remain valid in any case. An <a href="http://www.w3.org/2010/07/mwabp-implementation-report.html">implementation report</a> is available.</p>

      <p>Comments on this specification may be sent to <a href="mailto:public-bpwg-comments@w3.org">public-bpwg-comments@w3.org</a> (with <a href="http://lists.w3.org/Archives/Public/public-bpwg-comments/">public archive</a>).</p>

      <p>This document has been reviewed by W3C Members, by software developers, and by other W3C groups and interested parties, and is endorsed by the Director as a W3C Recommendation. It is a stable document and may be used as reference material or cited from another document. W3C's role in making the Recommendation is to draw attention to the specification and to promote its widespread deployment. This enhances the functionality and interoperability of the Web.</p>

      <p>This document was produced by a group operating under the <a href="http://www.w3.org/Consortium/Patent-Policy-20040205/">5 February 2004 W3C Patent Policy</a>. This document is informative only. W3C maintains a <a rel="disclosure" href="http://www.w3.org/2004/01/pp-impl/37584/status">public list of any patent disclosures</a> 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 <a href="http://www.w3.org/Consortium/Patent-Policy-20040205/#def-essential">Essential Claim(s)</a> must disclose the information in accordance with <a href="http://www.w3.org/Consortium/Patent-Policy-20040205/#sec-Disclosure">section 6 of the W3C Patent Policy</a>.</p>

      <div class="toc">
        <h2><a id="contents" name="contents">Table of Contents</a></h2>

        <p class="toc">1 <a href="#introduction">Introduction</a> <br />
            1.1 <a href="#purpose">Purpose of the Document</a> <br />
            1.2 <a href="#audience">Audience</a> <br />
            1.3 <a href="#scope">Scope</a> <br />
                1.3.1 <a href="#goal">Best Practices</a> <br />
                1.3.2 <a href="#webapp-defined">Web Application</a> <br />
                1.3.3 <a href="#mobile-context">Mobile Context</a> <br />
                1.3.4 <a href="#delivery-context">Delivery Context</a> <br />
            1.4 <a href="#relationship">Relationship to other Best Practices and
        recommendations</a> <br />
            1.5 <a href="#terminology">Terminology</a> <br />
        2 <a href="#structure">Structure of Best Practice Statements</a> <br />
        3 <a href="#bp">Best Practice Statements</a> <br />
            3.1 <a href="#bp-applicationdata">Application Data</a> <br />
                3.1.1 <a href="#bp-data-cookies">Use Cookies Sparingly</a> <br
        />
                3.1.2 <a href="#bp-data-html5">Use Appropriate Client-Side
        Storage Technologies for Local Data</a> <br />
                3.1.3 <a href="#bp-data-server">Replicate Local Data</a> <br />
            3.2 <a href="#bp-security">Security and privacy</a> <br />
                3.2.1 <a href="#bp-security-json">Do not Execute Unescaped or
        Untrusted JSON data</a> <br />
            3.3 <a href="#bp-inform-control">User Awareness and Control</a> <br />
                3.3.1 <a href="#bp-inform-personalinfo">Ensure the User is
        Informed About Use of Personal and Device Information</a> <br />
                3.3.2 <a href="#bp-enable-automatic-login">Enable Automatic
        Sign-in</a> <br />
            3.4 <a href="#bp-conserve">Conservative use of resources</a> <br />
                3.4.1 <a href="#bp-conserve-compress">Use Transfer
        Compression</a> <br />
                3.4.2 <a href="#bp-conserve-contentsize">Minimize Application
        and Data Size</a> <br />
                3.4.3 <a href="#bp-redirect-minimize">Avoid Redirects</a> <br />
                3.4.4 <a href="#bp-conserve-requests">Optimize Network
        Requests</a> <br />
                3.4.5 <a href="#bp-conserve-ext-files">Minimize External
        Resources</a> <br />
                3.4.6 <a href="#bp-conserve-sprites">Aggregate Static Images
        into a Single Composite Resource (Sprites)</a> <br />
                3.4.7 <a href="#bp-conserve-css-images">Include Background
        Images Inline in CSS Style Sheets</a> <br />
                3.4.8 <a href="#bp-conserve-fingerprint">Cache Resources By
        Fingerprinting Resource References</a> <br />
                3.4.9 <a href="#bp-conserve-ajax">Cache AJAX Data</a> <br />
                3.4.10 <a href="#bp-conserve-cookie">Do not Send Cookie
        Information Unnecessarily</a> <br />
                3.4.11 <a href="#bp-conserve-dom">Keep DOM Size
        Reasonable</a><br />
            3.5 <a href="#bp-presentation">User Experience</a> <br />
                3.5.1 <a href="#bp-presentation-startup">Optimize For
        Application Start-up Time</a><br />
                3.5.2 <a href="#bp-presentation-perceived">Minimize Perceived
        Latency</a> <br />
                3.5.3 <a href="#bp-presentation-interaction">Design for
        Multiple Interaction Methods</a> <br />
                3.5.4 <a href="#bp-presentation-focus">Preserve Focus on
        Dynamic Page Updates</a> <br />
                3.5.5 <a href="#bp-presentation-fragment">Use Fragment IDs to
        Drive Application View</a><br />
                3.5.6 <a href="#bp-interaction-uri-schemes">Make Telephone
        Numbers "Click-to-Call"</a> <br />
                3.5.7 <a href="#bp-presentation-flow">Ensure Paragraph Text
        Flows</a> <br />
                3.5.8 <a href="#bp-consistency">Ensure Consistency Of State
        Between Devices</a> <br />
                3.5.9 <a href="#bp-conserve-usepush">Consider Mobile Specific
        Technologies for Initiating Web Applications</a> <br />
                3.5.10 <a href="#bp-viewport">Use Meta Viewport Element To
        Identify Desired Screen Size</a> <br />
            3.6 <a href="#bp-devcap">Handling Variations in the Delivery
        Context</a> <br />
                3.6.1 <a href="#bp-devcap-detection">Prefer Server-Side
        Detection Where Possible</a> <br />
                3.6.2 <a href="#bp-devcap-scripting">Use Client-Side Detection
        When Necessary</a> <br />
                3.6.3 <a href="#bp-devcap-classify">Use Device Classification
        to Simplify Content Adaptation</a> <br />
                3.6.4 <a href="#bp-devcap-scripting-support">Support a
        non-JavaScript Variant if Appropriate</a> <br />
                3.6.5 <a href="#bp-devcap-user-choice">Offer Users a Choice of
        Interfaces</a> <br />
            3.7 <a href="#bp-further">Further Considerations</a> <br />
                3.7.1 <a href="#bp-canvas">Consider Use Of Canvas Element or
        SVG For Dynamic Graphics</a> <br />
                3.7.2 <a href="#bp-inform-automation">Inform the User About
        Automatic Network Access</a> <br />
                3.7.3 <a href="#bp-inform-network">Provide Sufficient Means to
        Control Automatic Network Access</a> <br />
      </p>

      <h2><a id="appendices" name="appendices">Appendices</a></h2>

      <p class="toc">Appendix 1: <a href="#dependent-properties">Best Practice
      Dependent Device Properties</a><br />
      Appendix 2: <a href="#references">References</a><br />
          2.1 <a href="#ref-mwi">MWI References</a> <br />
          2.2 <a href="#ref-dip">Device Independence</a> <br />
          2.3 <a href="#ref-web">Web, Protocols and Languages</a> <br />
          2.4 <a href="#ref-other">Other References</a> <br />
      Appendix 3: <a href="#acknowledgements">Acknowledgments</a></p>
    </div>

    <h2><a id="list-bp" name="list-bp">List of Best Practices</a></h2>

    <p>The following Best Practices are discussed in this document and listed here
    for convenience.</p>
    <ol>
      <li><p class="stmt"><a href="#bp-data-cookies">Use Cookies Sparingly</a></p>
      </li>
      <li><p class="stmt"><a href="#bp-data-html5">Use Appropriate Client-Side
      Storage Technologies for Local Data</a></p>
      </li>
      <li><p class="stmt"><a href="#bp-data-server">Replicate Local Data</a></p>
      </li>
      <li><p class="stmt"><a href="#bp-security-json">Do not Execute Unescaped or
      Untrusted JSON data</a></p>
      </li>
      <li><p class="stmt"><a href="#bp-inform-personalinfo">Ensure the User is
      Informed About Use of Personal and Device Information</a></p>
      </li>
      <li><p class="stmt"><a href="#bp-enable-automatic-login">Enable Automatic
      Sign-in</a></p>
      </li>
      <li><p class="stmt"><a href="#bp-conserve-compress">Use Transfer
      Compression</a></p>
      </li>
      <li><p class="stmt"><a href="#bp-conserve-contentsize">Minimize Application
      and Data Size</a></p>
      </li>
      <li><p class="stmt"><a href="#bp-redirect-minimize">Avoid Redirects</a></p>
      </li>
      <li><p class="stmt"><a href="#bp-conserve-requests">Optimize Network
      Requests</a></p>
      </li>
      <li><p class="stmt"><a href="#bp-conserve-ext-files">Minimize External
      Resources</a></p>
      </li>
      <li><p class="stmt"><a href="#bp-conserve-sprites">Aggregate Static Images
      into a Single Composite Resource (Sprites)</a></p>
      </li>
      <li><p class="stmt"><a href="#bp-conserve-css-images">Include Background
      Images Inline in CSS Style Sheets</a></p>
      </li>
      <li><p class="stmt"><a href="#bp-conserve-fingerprint">Cache Resources By
      Fingerprinting Resource References</a></p>
      </li>
      <li><p class="stmt"><a href="#bp-conserve-ajax">Cache AJAX Data</a></p>
      </li>
      <li><p class="stmt"><a href="#bp-conserve-cookie">Do not Send Cookie
      Information Unnecessarily</a></p>
      </li>
      <li><p class="stmt"><a href="#bp-conserve-dom">Keep DOM Size
      Reasonable</a></p>
      </li>
      <li><p class="stmt"><a href="#bp-presentation-startup">Optimize For
      Application Start-up Time</a></p>
      </li>
      <li><p class="stmt"><a href="#bp-presentation-perceived">Minimize Perceived
      Latency</a></p>
      </li>
      <li><p class="stmt"><a href="#bp-presentation-interaction">Design for
      Multiple Interaction Methods</a></p>
      </li>
      <li><p class="stmt"><a href="#bp-presentation-focus">Preserve Focus on
      Dynamic Page Updates</a></p>
      </li>
      <li><p class="stmt"><a href="#bp-presentation-fragment">Use Fragment IDs to
      Drive Application View</a></p>
      </li>
      <li><p class="stmt"><a href="#bp-interaction-uri-schemes">Make Telephone
      Numbers "Click-to-Call"</a></p>
      </li>
      <li><p class="stmt"><a href="#bp-presentation-flow">Ensure Paragraph Text
      Flows</a></p>
      </li>
      <li><p class="stmt"><a href="#bp-consistency">Ensure Consistency Of State
      Between Devices</a></p>
      </li>
      <li><p class="stmt"><a href="#bp-conserve-usepush">Consider Mobile Specific
      Technologies for Initiating Web Applications</a></p>
      </li>
      <li><p class="stmt"><a href="#bp-viewport">Use Meta Viewport Element To
      Identify Desired Screen Size</a></p>
      </li>
      <li><p class="stmt"><a href="#bp-devcap-detection">Prefer Server-side
      Detection Where Possible</a></p>
      </li>
      <li><p class="stmt"><a href="#bp-devcap-scripting">Use Client-side Detection
      When Necessary</a></p>
      </li>
      <li><p class="stmt"><a href="#bp-devcap-classify">Use Device Classification
      to Simplify Content Adaptation</a></p>
      </li>
      <li><p class="stmt"><a href="#bp-devcap-scripting-support">Support a
      non-JavaScript Variant if Appropriate</a></p>
      </li>
      <li><p class="stmt"><a href="#bp-devcap-user-choice">Offer Users a Choice of
      Interfaces</a></p>
      </li>
    </ol>

    <p>The following advisory notes from the Mobile Web Best Practices Working
    Group are also discussed in this document and listed here for convenience.</p>
    <ol>
      <li><p class="stmt"><a href="#bp-canvas">Consider Use Of Canvas Element or
      SVG For Dynamic Graphics</a></p>
      </li>
      <li><p class="stmt"><a href="#bp-inform-automation">Inform the User About
      Automatic Network Access</a></p>
      </li>
      <li><p class="stmt"><a href="#bp-inform-network">Provide Sufficient Means to
      Control Automatic Network Access</a></p>
      </li>
    </ol>

    <h2><a id="introduction" name="introduction">1 Introduction</a></h2>

    <h3><a id="purpose" name="purpose">1.1 Purpose of the Document</a></h3>

    <p>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.</p>

    <h3><a id="audience" name="audience">1.2 Audience</a></h3>

    <p>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, but are not expected to have a background in mobile technologies or
    previous experience with Mobile Web Best Practices (BP1) <a
    href="#MWBP">[MWBP]</a>.</p>

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

    <h3><a id="scope" name="scope">1.3 Scope</a></h3>

    <p>These recommendations expand on the recommendations of BP1. Where the focus
    of BP1 is primarily the extension of Web <em>browsing</em> to mobile devices,
    this document considers the development of Web <em>applications</em> on mobile
    devices.</p>

    <h4><a id="goal" name="goal">1.3.1 Best Practices</a></h4>

    <p>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 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 an
    application.</p>

    <p>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 was 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 the Working Group believes that they <em>will soon become</em> fully
    qualified Best Practices (e.g. in prevalent use within the development
    community).</p>

    <p>In building a Web application, it is not necessary to implement <em>all</em>
    Best Practices. Instead, each Best Practice should be considered as a possible
    measure that might be implemented towards the goal of providing as rich and
    dynamic an experience as possible on a mobile Web browser.</p>

    <h4><a id="webapp-defined" name="webapp-defined">1.3.2 Web Application</a></h4>

    <p>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 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 locally executable elements of interactivity and persistent
    state.</p>

    <p>While the focus of this document is the Best Practices that apply to
    applications running in a Web browser, in many cases these recommendations are
    equally applicable to other kinds of Web run-time, such as the W3C work on Web
    Widgets [<a href="#WIDGETS">WIDGETS</a>] and also in a number of
    vendor-specific initiatives.</p>

    <h4><a id="mobile-context" name="mobile-context">1.3.3 Mobile Context</a></h4>

    <p>In a world where the line between mobile and non-mobile is necessarily
    blurred and a document that restricts its focus solely to best practices that
    are <em>uniquely</em> 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, intermittent connectivity), and also the
    additional scope and features that should be considered when developing for the
    mobile context (e.g. device context / location, presence of personal data on
    the device, etc).</p>

    <h4 id="delivery-context">1.3.4 Delivery Context</h4>

    <p>This document builds on some of the concepts described by the Ubiquitous Web
    Applications Working Group (UWA) and the Device Independence Principles <a
    href="#DIP">[DIP]</a>. It also discusses device and delivery channel
    characteristics, which the UWA has named "Delivery Context" <a
    href="#DCODI">[DCODI]</a>.</p>

    <p>This document does not make any explicit assumptions about features of the
    Delivery Context, but most Best Practices assume devices with support for
    standard XHTML, JavaScript, and CSS capability. At the time of writing,
    developers of relatively complex Web applications targeting mid- to high-end
    devices are most likely to benefit from these Best Practices, but as the
    technology evolves it is expected that the range of relevant devices will
    increase.</p>

    <p>Additionally, some Best Practices are relevant only if the device exposes
    certain capabilities (for example, access to device information such as
    location). In these cases the requirements are summarized as a separate
    sub-heading.</p>

    <p>Saying that applications should be sensitive to the Delivery Context implies
    that some level of device knowledge and content adaptation is required. For
    Best Practices specifically related to this area, see <a
    href="#bp-devcap-detection">3.6 Handling Variations in Delivery Context</a>.</p>

    <h3><a id="relationship" name="relationship">1.4 Relationship to other Best
    Practices and recommendations</a></h3>

    <p>These recommendations are complementary to the recommendations of Mobile Web
    Best Practices 1.0 (BP1) though their focus is somewhat orthogonal. Whereas BP1
    focused on delivering a good experience on a broad range of devices, this
    document's focus is on making use of advanced device capabilities to deliver
    the best possible experience on those devices that can support it. For this
    reason, while readers of this document are likely to benefit from reading BP1
    it is not a pre-requisite.</p>

    <h3 id="terminology">1.5 Terminology</h3>

    <p>Note that the term "JavaScript" is used in place of the (arguably more
    correct) term "ECMAScript" in order to provide consistency with the companion
    Web application technologies (JSON and AJAX) which are in common use and both
    implicitly refer to JavaScript in their names.</p>

    <p>Also, the terms "AJAX" and XMLHttpRequest (XHR) are used to refer to any
    asynchronous browser request.</p>

    <h2><a id="structure" name="structure">2 Structure of Best Practice
    Statements</a></h2>
    <dl>
      <dt>The Heading</dt>
      <dd>A summary of the functional area to be addressed by these
      statements.</dd>
    </dl>
    <dl>
      <dt>What it means</dt>
      <dd>An explanation of the intention of the Best Practice statement.</dd>
    </dl>
    <dl>
      <dt>How to do it</dt>
      <dd>A discussion of the techniques and device capabilities required to
      implement this Best Practice.</dd>
    </dl>
    <dl>
      <dt>[Requires]</dt>
      <dd>A summary of device capabilities required in order for this Best
      Practice to apply.</dd>
    </dl>

    <h2><a id="bp" name="bp">3 Best Practice Statements</a></h2>

    <h3><a id="bp-applicationdata" name="bp-applicationdata">3.1 Application
    Data</a></h3>

    <p>Most applications have the need to store data of various forms, both
    intrinsic content (e.g. the emails of an email application, the calendar events
    of a calendar application) and supplementary personalization settings (e.g.
    preferred theme, default view, etc).</p>

    <p>These Best Practices relate to the appropriate technologies and techniques
    to use for managing a Web application's data.</p>

    <h4><a id="bp-data-cookies" name="bp-data-cookies">3.1.1 Use Cookies
    Sparingly</a></h4>

    <h5><a id="d1e792" name="d1e792">3.1.1.1 What it means</a></h5>

    <p>Cookies are a common and effective means to store small amounts of state on
    the client. They are appropriate for simple personalization data and are
    commonly used to store a token representing user identity in order to enable
    automatic sign-in.</p>

    <p>Information stored in cookies, however, is sent to the server for every
    request and so using them for excessive amounts of data can negatively impact
    performance, particularly on a mobile network.</p>

    <p>Also, in the mobile context, cookie support cannot be relied upon since it
    may be disabled either in the device configuration or by the mobile network.
    For this reason, applications should endeavor to remain functional even if
    cookies are unavailable. See <a
    href="http://www.w3.org/TR/mobile-bp/#COOKIES">BP1 [COOKIES] Do not rely on
    cookies being available</a> for more cookie related caveats.</p>

    <h4><a id="bp-data-html5" name="bp-data-html5">3.1.2 Use Appropriate
    Client-Side Storage Technologies for Local Data</a></h4>

    <h5><a id="d1e818" name="d1e818">3.1.2.1 What it means</a></h5>

    <p>If supported by the device, client-side storage APIs provide a mechanism to
    store more extensive amounts of data than would be appropriate with cookies. At
    the time of writing, work is still undergoing to unify these APIs, see the W3C
    WebApps working group [<a href="#WEBAPPS">WEBAPPS</a>] and Device APIs working
    group [<a href="#DAP">DAP</a>] for more information. Additionally, some
    examples of existing technologies that support client-side storage APIs are
    BONDI [<a href="#BONDI">BONDI</a>], HTML5 [<a href="#HTML5">HTML5</a>], and
    Opera Widgets [<a href="#OPERA">OPERA</a>].</p>

    <p>Making use of client-side storage in Web applications is a powerful
    technique that brings Web applications into parity with native applications in
    terms of start-up time and responsiveness. Two key advantages are worth noting
    explicitly:</p>
    <ul>
      <li>Application data stored locally can be displayed immediately when the
      application is started (without the need for a server roundtrip) allowing
      start-up latency to be reduced.
      <p></p>
      </li>
      <li>By making updates locally at first and replicating changes back to the
      server in the background when connectivity is available, Web applications
      can continue to operate responsively even when the network signal is
      unreliable.</li>
    </ul>

    <h5><a id="d1e839" name="d1e839">3.1.2.2 How to do it</a></h5>
    Each technology offers a variety of storage facilities that range from simple
    "key = value" models appropriate for relatively simple, unstructured data, to
    full SQL Database APIs appropriate for more extensive and structured content.
    For a good technical discussion of these facilities in the context of HTML5 see
    Offline Web Applications [<a href="#OFFLINE">OFFLINE</a>].

    <p></p>

    <p><strong>[ Client-Side Storage ]</strong> Requires: Local Storage API.</p>
  </div>

  <div class="head">
    <h4><a id="bp-data-server" name="bp-data-server">3.1.3 Replicate Local Data</a>
    To A Server If Necessary</h4>

    <h5><a id="d1e870" name="d1e870">3.1.3.1 What it means</a></h5>

    <p>If a client-side storage API is being used the data in it is not visible to
    the user's other devices. Whilst this is appropriate for some forms of data
    (e.g. preferences and state relevant only to a given device), it is often
    necessary to send this data back to a server in order to provide a consistent
    view across devices (e.g. between mobile and desktop instances of an
    application) and make it possible to recover data if the device is lost or
    damaged. See <a href="#bp-consistency">3.5.8 Ensure Consistency Of State
    Between Devices</a> for further discussion on these topics.</p>

    <p>As a rule of thumb, data that needs to be shared with other devices or
    recovered in the case of a lost or damaged device, should be replicated back to
    the server as soon as possible.</p>

    <h5><a id="d1e882" name="d1e882">3.1.3.2 How to do it</a></h5>

    <p>The technologies that provide client-side storage APIs provide facilities to
    detect the current network connectivity. For example, HTML5 provides a property
    on the navigator object (<code>navigator.onLine</code>) to
    indicate whether the client is currently online, and dispatches two events on
    the Window object to indicate a change of network state (<code>online</code> and <code>offline</code>).</p>

    <p>However, these APIs should be used with caution. Even if the browser is
    reporting an online state, on an intermittent network this is no guarantee that
    a subsequent connection will succeed. The most effective approach is to fail
    gracefully in the event of a connection failure, store unsaved data in a queue
    of uncommitted changes, and set a timer to try again later.</p>

    <p><strong>[ Client-Side Storage ]</strong> Requires: Local Storage API.</p>

    <h3><a id="bp-security" name="bp-security">3.2 Security and privacy</a></h3>

    <p>Use trusted information, and protect all personally identifiable
    information. Mobile Web applications are subject to the same security
    considerations and risks as desktop Web applications, and as such most desktop
    related security advice is applicable to mobile. (For example, see OWASP [<a
    href="#OWASP">OWASP</a>] for a good summary of common Web security
    Best Practices). This document does not attempt to provide an exhaustive survey
    of security issues but the following Best Practice has been called out on the
    grounds that it is specifically relevant to mobile.</p>

    <h4><a id="bp-security-json" name="bp-security-json">3.2.1 Do not Execute
    Unescaped or Untrusted JSON data</a></h4>

    <p><em>3.2.1.1 What it means</em></p>

    <p>A common technique is to use JSON to transfer data to a client and then use
    JavaScript's <code>eval()</code> function to
    parse it. This is a powerful technique, since on constrained devices <code>eval()</code> can execute
    more quickly than the alternatives. However, direct execution of a datafeed
    that contains unescaped user-generated data represents a significant security
    risk and should be avoided.</p>

    <p>Inadvertently executing malicious JavaScript is particularly dangerous on
    mobile devices where personal information (current location, contact data, etc)
    may be exposed.</p>

    <p><em>3.2.1.2 How to do it</em></p>

    <p>Where possible, instead of parsing JSON data by executing it with the <code>eval()</code> function, use a JSON parser (for example a <a href="https://github.com/douglascrockford/JSON-js/raw/master/json_parse.js">JavaScript implementation of a JSON parser</a> [<a href="#JSON-PARSE">JSON-PARSE</a>]).</p>

    <p>If this is impractical ensure that the data contains no user-generated
    content (e.g. the server is responsible for the content of all fields in the
    datafeed) or that any user-generated content is correctly escaped.</p>

    <p>See RFC4627 [<a href="#RFC4627">RFC4627</a>] for details on how to ensure a JSON
    datafeed is suitably escaped and can be safely passed into JavaScript's <code>eval()</code> function.</p>

    <h3><a id="bp-inform-control" name="bp-inform-control">3.3 User Awareness and
    Control</a></h3>

    <p>Allow the user to control application behaviour that might not otherwise be
    apparent, such as access to the network and access to device data. For
    example:</p>
    <ul>
      <li>Pictures, music, and video clips;</li>
      <li>Contacts, calendar (PIM data);</li>
      <li>Call history;</li>
      <li>System data (battery, coverage, roaming, location);</li>
      <li>Media recording (record audio/video clip, get new picture);</li>
      <li>Device context (e.g. location, connectivity, profile setting).</li>
    </ul>

    <p>Note that where possible it is preferable to rely on the browser's native
    functionality to notify the user of these activities, however the Best
    Practices below provide further advice on appropriate <em>application</em>
    behaviour in situations where the native functionality of the browser may not
    be sufficient.</p>

    <h4><a id="bp-inform-personalinfo" name="bp-inform-personalinfo"
           >3.3.1 Ensure the User is Informed About Use of Personal and Device
    Information</a></h4>

    <h5><a id="d1e656" name="d1e656">3.3.1.1 What it means</a></h5>

    <p>Ensure that the user is informed if the application needs to access personal
    or device information. The user should be informed of the types of information
    that will be used by the application and whether / how that data will be
    exchanged with the server.</p>

    <p>These notices should be provided when the user first accesses the Web
    application, or on first access to user information. It should provide the user
    with enough information to judge whether or not they want to allow the
    application access to their data.</p>

    <h5><a id="d1e666" name="d1e666">3.3.1.2 How to do it</a></h5>

    <p>In many cases use of APIs that provide access to personal or device
    information causes a native confirmation dialog to be presented to the user. 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.</p>

    <p>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 will lead to
    the user being presented with repeated native confirmation dialog boxes.</p>

    <p><strong>[ DEVICE DATA</strong> <strong>]</strong> Requires: Device Data
    APIs.</p>

    <h4><a id="bp-enable-automatic-login" name="bp-enable-automatic-login"
           >3.3.2 Enable Automatic Sign-in</a></h4>

    <h5><a id="bp-enable-automatic-login-what"
           name="bp-enable-automatic-login-what">3.3.2.1 What it means</a></h5>

    <p>If an application requires user identity it is usual to prompt for user
    credentials (username and password) and provide the option to sign-in
    automatically on next usage session. This is especially important on a mobile
    device where data input is more difficult than on a desktop.</p>

    <p>Note that if automatic sign-in is enabled, a sign-out link should also be
    provided.</p>

    <h5><a id="bp-enable-automatic-login-how"
           name="bp-enable-automatic-login-how">3.3.2.2 How to do it</a></h5>

    <p>User credentials can be stored in a cookie or in local storage. However, it
    is important not to store unencrypted password information since this is
    insecure. Typically, a securely hashed token which, if necessary, can be
    revoked on the server, is stored locally in order to enable automatic
    sign-in.</p>

    <h3><a id="bp-conserve" name="bp-conserve">3.4 Conservative use of
    resources</a></h3>

    <p>The most effective way to ensure that applications run smoothly and with low
    latency is to minimize use of device memory, processor power, and network
    bandwidth which are more limited on mobile devices than on the desktop.</p>

    <h4><a id="bp-conserve-compress" name="bp-conserve-compress">3.4.1 Use Transfer
    Compression</a></h4>

    <h5><a id="d1e687" name="d1e687">3.4.1.1 What it means</a></h5>

    <p>Compress content for efficient delivery.</p>

    <h5><a id="d1e693" name="d1e693">3.4.1.2 How to do it</a></h5>

    <p>HTTP 1.1 compression, which uses the gzip and DEFLATE algorithms, is widely supported. Web servers should be configured to serve appropriately compressed responses.</p>

    <p>Note however, that the cost (in time and battery usage) of decompressing
    data should be balanced against the gains in transport efficiency. When
    configuring HTTP 1.1 compression note that:</p>
    <ul>
      <li>Most image formats (especially JPEGs) do not benefit from compression,
      but SVG does;</li>
      <li>Most other media formats (e.g. audio, video) do not benefit from
      compression;</li>
      <li>Very small files (e.g. &lt;1k) generally do not benefit from
      compression.</li>
    </ul>

    <p>Where supported, alternative compression formats (such as EXI [<a href="#EXI">EXI</a>]) that do not share some of the above impediments, may provide benefit.</p>

    <h4><a id="bp-conserve-contentsize" name="bp-conserve-contentsize"
           >3.4.2 Minimize Application and Data Size</a></h4>

    <h5><a id="d1e823" name="d1e823">3.4.2.1 What it means</a></h5>

    <p>This section elaborates on the Best Practices of BP1 (<a
    href="http://www.w3.org/TR/mobile-bp/#MINIMIZE">MINIMIZE</a>). Smaller
    applications will download and execute more quickly and more reliably than
    larger ones on constrained devices.</p>

    <h5><a id="d1e832" name="d1e832">3.4.2.2 How to do it</a></h5>

    <p>Process HTML, JavaScript and CSS files to remove whitespace and minify
    before delivery. </p>

    <p>"Minification" / "optimization" may take a number of forms from simple
    removal of white space and comments, to the global substitution of tokens
    (variables, method names, selector names) with shorter alternatives. In
    general, minification based upon a lexical / grammatical understanding of that
    source is less fragile and is preferred to simple regular-expression based
    tools.</p>

    <p>See <a href="http://compressorrater.thruhere.net/">the JavaScript CompressorRater</a> [<a href="#JSCOMP">JSCOMP</a>] for a comparison of JavaScript minification tools.</p>
  </div>

  <h4><a id="bp-redirect-minimize" name="bp-redirect-minimize">3.4.3 Avoid
  Redirects</a></h4>

  <h5><a id="d1e729" name="d1e729">3.4.3.1 What it means</a></h5>

  <p>The redirection of requests (using HTTP 3xx status or HTML meta refresh) is
  typically used to exchange information between servers (e.g. account
  authentication). The delay incurred by redirects is much higher over mobile
  networks and so the number of redirects should be kept to a minimum.</p>

  <h5><a id="d1e736" name="d1e736">3.4.3.2 How to do it</a></h5>

  <p>Try not to use redirects. If more than two redirects are required consider
  using an interstitial page to communicate to the user that the application is
  still working.</p>

  <div class="head">
    <h4><a id="bp-conserve-requests" name="bp-conserve-requests">3.4.4 Optimize
    Network Requests</a></h4>

    <h5><a id="d1e751" name="d1e751">3.4.4.1 What it means</a></h5>

    <p>Establishing the necessary connections in order to complete an HTTP request
    can take significantly longer on a mobile network than on a fixed network. Even
    though bandwidth is typically more restricted on a mobile network it is still
    preferable to make fewer, larger requests.</p>

    <h5><a id="d1e757" name="d1e757">3.4.4.2 How to do it</a></h5>

    <p>Consider the following possibilities when designing an application:</p>
    <dl>
      <dt><strong>Batching requests:</strong></dt>
      <dd>Since a single request for more data is likely to provide a better user
      experience than several smaller requests, wherever possible, batch up
      multiple requests at the application level.</dd>
    </dl>
    <dl>
      <dt><strong>Throttle low-priority requests:</strong></dt>
      <dd>In some applications certain requests may be less critical than others
      (e.g. logging requests). Throttle low-priority requests to ensure they
      don't block the network and prevent more critical requests from being
      serviced quickly.</dd>
    </dl>
    <dl>
      <dt><strong>Back off during periods of inactivity:</strong></dt>
      <dd>If the application polls for updates, it should monitor user activity
      and poll less frequently during inactive periods.</dd>
    </dl>
    <dl>
      <dt><strong>Device Context:</strong></dt>
      <dd>If supported by the device, use awareness of current connectivity (e.g.
      WiFi) to select an appropriate level of interaction.</dd>
    </dl>
  </div>

  <div class="head">
    <h4><a id="bp-conserve-ext-files" name="bp-conserve-ext-files"
           >3.4.5 Minimize External Resources</a></h4>

    <p><em>3.4.5.1 What it means</em></p>

    <p>A Web application typically requires a number of resources (style sheets,
    scripts, image, etc) each of which requires an HTTP request. As above, HTTP
    requests are particularly expensive on a mobile network and so fewer, larger
    requests should be favored over a larger number of smaller requests.</p>

    <p><em>3.4.5.2 How to do it</em></p>

    <p>As far as makes sense after taking into account <a
    href="#bp-presentation-perceived">3.5.2 Minimize Perceived Latency</a> combine
    all style sheets into a single resource and all scripts into a single resource.
    If multiple scripts and style sheets are required as part of the authoring
    process, then try to arrange that they are merged before the page is served.</p>
  </div>

  <div class="head">
    <h4><a id="bp-conserve-sprites" name="bp-conserve-sprites">3.4.6 Aggregate
    Static Images into a Single Composite Resource (Sprites)</a></h4>

    <p><em>3.4.6.1 What it means</em></p>

    <p>Web applications often depend on a number of static images to provide icons,
    buttons, etc. If served as a separate image each one incurs an additional HTTP
    request which is detrimental to performance.</p>

    <p><em>3.4.6.2 How to do it</em></p>

    <p>Define candidate images as CSS background images and combine them into a
    single image for transfer (spriting). To optimize efficiency combine images of
    similar sizes and color palettes. Also, combine images that do not change
    often, since if one of the component images changes the entire combination
    image will need to be refreshed. To render individual components of a resource
    use CSS positioning and clipping.</p>

    <p>Note that this technique should only be applied to <strong>decorative
    </strong>images (e.g. those that don't require an <em>alt</em> text). Spriting
    informational images leads to an undesirable coupling of content and layout and
    is detrimental to accessibility.</p>

    <p><strong>[ CSS ]</strong> Requires: CSS2 Clipping and Positioning Support</p>

    <h4><a id="bp-conserve-css-images" name="bp-conserve-css-images">3.4.7 Include
    Background Images Inline in CSS Style Sheets</a></h4>

    <p><em>3.4.7.1 What it means</em></p>

    <p>Visual effects (e.g. background images and gradients) are often used to
    improve the look and feel of an application. These can be included in CSS as
    base64 encoded strings in order to avoid an additional HTTP request</p>

    <p>Note that base64 encoding adds around 10% to the image size after gzip
    compression and this additional cost should be weighed against the benefits of
    fewer requests.</p>

    <p><em>3.4.7.2 How to do it</em></p>

    <p>Background images can be encoded using the data URI scheme:
    <code>url('data:image/png;base64, [data])</code></p>

    <p><strong>[ CSS ]</strong> Requires: <a
    href="http://tools.ietf.org/html/rfc2397">RFC2397</a> [<a href="#RFC2397">RFC2397</a>] data uri support.</p>

    <h4><a id="bp-conserve-fingerprint" name="bp-conserve-fingerprint">3.4.8 Cache
    Resources By Fingerprinting Resource References</a></h4>

    <p><em>3.4.8.1. What it means</em></p>

    <p>Dynamic resources that change occasionally (e.g. a user's avatar) can still
    be cached by identifying them with a URI that includes a hash of the resource
    content. Using this technique means that the browser does not need to check the
    resource headers in order to validate its cache, instead, any change in the
    resource will lead naturally to a corresponding change in the resource
    reference.</p>

    <p>For example, </p>

    <p style="text-align:center;"><code>&lt;img
    src="http://www.example.com/userimages/joeblogs-67f90da089da"&gt;</code></p>

    <p>Where the actual resource at joeblogs-[xxx] could be either generated in
    some offline process or served dynamically.</p>

    <p><em>3.4.8.2 How to do it</em></p>
    <ul>
      <li>Set the resource caching policy to "never expire" by setting the
      <code>Expires</code> header to a date in the far future.</li>
      <li>Reference the resource using a URI that contains a Hash of the content.
      If the content changes, this reference will change and the browser will
      fetch the updated data.</li>
    </ul>

    <h4><a id="bp-conserve-ajax" name="bp-conserve-ajax">3.4.9 Cache AJAX
    Data</a></h4>

    <p><em>3.4.9.1 What it means</em></p>

    <p>If possible, data designed to be accessed by AJAX requests from the client
    should be cached in the same way as primary content.</p>

    <p><em>3.4.9.2 How to do it</em></p>

    <p>The standard caching techniques (<code>Expires</code> header and
    <code>Cache-Control</code> header), as well as resource fingerprinting (see <a
    href="#bp-conserve-fingerprint">3.4.8</a>) can be used on AJAX data as readily
    as primary content pages.</p>

    <h4><a id="bp-conserve-cookie" name="bp-conserve-cookie">3.4.10 Do not Send
    Cookie Information Unnecessarily</a></h4>

    <p><em>3.4.10.1 What it means</em></p>

    <p>Static resources do not need cookie information and so performance can be
    improved by serving them from a path or sub-domain for which the application's
    cookies are out of scope.</p>

    <p><em>3.4.10.2 How to do it</em></p>

    <p>Use a different domain, sub-domain, or path name for static resources to the
    main application, and restrict the valid path of cookies such that they will
    not be exchanged when they are not needed.</p>

    <p>For example:</p>

    <div style="padding-left: 5px; border:1px solid black">
      <p><code>Set-Cookie:
      somePreferenceInformation=purple; path=/myapp/</code></p>
    </div>

    <p>Application data served from <code>/myapp</code> will receive
    cookie information.</p>

    <p>Static data served from <code>/static</code> will not
    receive unneeded cookie information.</p>

    <h4><a id="bp-conserve-dom" name="bp-conserve-dom">3.4.11 Keep DOM Size
    Reasonable</a></h4>

    <h5><a id="bp-conserve-dom-what" name="bp-conserve-dom-what">3.4.11.1 What it
    means</a></h5>

    <p>The in-memory size of the Document Object Model (DOM) may be limited on
    mobile devices. Large / complex pages may exceed this limit and cause
    unpredictable errors.</p>

    <h5><a id="bp-conserve-dom-how" name="bp-conserve-dom-how">3.4.11.2 How to do
    it</a></h5>

    <p>Limit the amount of information in the DOM at a single time using pagination
    or other appropriate techniques.</p>

    <h3><a id="bp-presentation" name="bp-presentation">3.5 User Experience</a></h3>

    <p>Given the additional complexities of interacting with an application on a
    mobile device, special consideration should be given to the overall user
    experience. User experience is influenced by a number of factors, including:
    latency, interaction method, and data consistency.</p>

    <h4><a id="bp-presentation-startup" name="bp-presentation-startup">3.5.1
    Optimize For Application Start-up Time</a></h4>

    <h5><a id="bp-presentation-startup-what"
           name="bp-presentation-startup-what">3.5.1.1 What it means</a></h5>

    <p>User experience is strongly influenced by the initial start-up time of an
    application. </p>

    <p>Offline Web application technologies like HTML5 AppCache [<a
    href="#HTML5-OFFLINE">HTML5-OFFLINE</a>] bring Web applications into parity
    with native applications in terms of their start-up time and their ability to
    be used even where network coverage is intermittent. The following steps should
    be considered to minimize the start time of a Web application.</p>

    <h5><a id="bp-presentation-startup-how"
           name="bp-presentation-startup-how">3.5.1.2 How to do it</a></h5>

    <p>Consider the following techniques to help minimize application start
    time:</p>
    <ul>
      <li><strong>Use Offline Technology:</strong> Offline Web technologies (for
      example, AppCache) allow the resources of a Web application (its HTML,
      JavaScript, and CSS files) to be specified and stored locally so that the
      application can start without requiring a round-trip to the server.</li>
      <li><strong>Consider Partitioning Large Scripts:</strong> In complex Web
      applications, JavaScript parsing can contribute a significant portion of
      start time. If some functionality is rarely used it should be moved into
      separate scripts that can be loaded on demand, lowering the amount of core
      code that needs to be parsed at start-up.</li>
      <li><strong>Use Local Storage:</strong> Where appropriate, store a snapshot
      of the last application state so it can be displayed immediately on
      start-up without requiring a server roundtrip.</li>
      <li><strong>Minimize Number of Local Storage Queries:</strong> The number of
      local storage queries required to generate the initial view is a
      significant contribution to start-up latency. Try to minimize the number of
      local storage queries required before the first view can be displayed.</li>
    </ul>
  </div>

  <div class="head">
    <h4><a id="bp-presentation-perceived" name="bp-presentation-perceived"
           >3.5.2 Minimize Perceived Latency</a></h4>

    <h5><a id="bp-presentation-perceived-meaning"
           name="bp-presentation-perceived-meaning">3.5.2.1 What it means</a></h5>

    <p>Lowering perceived latency is an important factor in improving the overall
    usability of a Web application.</p>

    <h5><a id="bp-presentation-perceived-howto"
           name="bp-presentation-perceived-howto">3.5.2.2 How to do it</a></h5>

    <p>A number of techniques can be used to lower perceived latency:</p>
    <ul>
      <li><strong>Enable Incremental Rendering</strong>: Place JavaScript at the
      bottom of the page (since browsers rendering halts while parsing
      JavaScript) and configure the page so that any useful information that
      might be available is viewable while the main content of the application is
      still loading.</li>
      <li><strong>Keep the User Informed of Activity:</strong> Use spinners
      progress bars to keep the user informed during network and device API
      accesses so that they do not think the application is halted.</li>
      <li><strong>Avoid Page Reloads:</strong> To reflect changes in state or show
      different views within an application, update pages dynamically (by
      manipulating the DOM) rather than reloading them.</li>
      <li><strong>Preload Probable Next Views:</strong> Preload data for frequently
      traversed paths in the application so it can be displayed more quickly when
      the user requests it.</li>
    </ul>

    <h4><a id="bp-presentation-interaction"
           name="bp-presentation-interaction">3.5.3 Design for Multiple Interaction
    Methods</a></h4>

    <h5><a id="bp-presentation-interaction-what"
           name="bp-presentation-interaction-what">3.5.3.1 What it means</a></h5>

    <p>Interaction methods vary across devices. Three main interaction methods
    should be considered when designing the UI:</p>
    <ul>
      <li>Focus Based: The browser focus "jumps" from element to element;</li>
      <li>Pointer Based: Key-based navigation controls a pointer that can cover any
      part of the screen;</li>
      <li>Touch Based: Events are related directly to a finger or stylus touch
      position on the screen.</li>
    </ul>

    <p>The optimum configuration of UI elements varies depending on the interaction
    method used by the device. Ideally, the UI should be adapted based on a
    knowledge of the interaction methods supported by the target device. If this is
    not possible, then the UI should be designed to provide a good experience for
    each of these different interaction methods.</p>

    <p>Additionally note that (as always) new interaction methods are likely to
    emerge in the future, particularly in the fields of voice and assistive
    technology. For additional, non-mobile specific, guidelines on accessibility
    and designing for assistive technologies, see Web Content Accessibility Guidelines (WCAG) 2.0 [<a href="#WCAG20">WCAG20</a>]. </p>

    <h5><a id="bp-presentation-interaction-how"
           name="bp-presentation-interaction-how">3.5.3.2 How to do it</a></h5>

    <p>Particularly where navigation of content requires multiple links (i.e.
    back/forward in a carousel) the following factors should be considered:</p>

    <p><strong>Focus Based:</strong></p>
    <ul>
      <li>The current focus of the page is easily determined because the focus
      element will be highlighted;</li>
      <li>Focus area will jump automatically from one selectable element to another
      (e.g. from link to link) without affecting usability even when widely
      spaced.</li>
    </ul>

    <p><strong>Pointer Based:</strong></p>
    <ul>
      <li>Selectable elements that are associated with each other need to be close
      as moving the pointer can be slow;</li>
      <li>Selectable elements need to be large enough to be easily selected --
      since the pointer often moves in steps of between 5 - 10 pixels;</li>
      <li>Selectable elements should have rollovers to make it clear when the
      pointer has entered their active area.</li>
    </ul>

    <p><strong>Touch Based:</strong></p>
    <ul>
      <li>Selectable elements may be (but don't have to be) widely spaced since the
      user can select them directly;</li>
      <li>Selectable elements must be large enough to be easily selected (e.g. list
      items should have a screen height of at least around 1cm);</li>
      <li>No elements are in focus until they are selected so extra information
      cannot be passed to the user (e.g. rollovers will not work).</li>
    </ul>

    <h4><a id="bp-presentation-focus" name="bp-presentation-focus"
           >3.5.4 Preserve Focus on Dynamic Page Updates</a></h4>

    <h5><a id="d1e1198" name="d1e1198">3.5.4.1 What it means</a></h5>

    <p>The JavaScript <code>focus</code> 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.</p>

    <h5><a id="d1e1205" name="d1e1205">3.5.4.2 How to do it</a></h5>

    <p>Use the JavaScript <code>focus</code> method only if it is essential to the
    use of the application, and does not inhibit user control/interaction.</p>

    <h4><a id="bp-presentation-fragment" name="bp-presentation-fragment">3.5.5 Use
    Fragment IDs to Drive Application View</a></h4>

    <p><em>3.5.5.1 What it means</em></p>

    <p>Web applications can switch views without a full page reload by showing and
    hiding sections of content. However, this means that the browser &lt;back&gt;
    button doesn't work by default, and it is not possible to link directly to
    specific views within an application. Usability is enhanced by enabling both of
    these features:</p>
    <ul>
      <li>Enabling deep links (e.g. to the content of a specific email) means the
      user can bookmark this view and return to it quickly;</li>
      <li>Enabling the browser history provides a natural method to navigate
      application views that is natively supported by the browser.</li>
    </ul>

    <p><em>3.5.5.2 How to do it</em></p>

    <p>Assign a URI with a distinguishing fragment identifier (e.g.
    <code>http://myapp.example.org/myapp#view</code>). Use JavaScript to
    interrogate the browser location in order to determine which view to
    display.</p>

    <p>For further discussion on this topic see: <a href="http://ajaxpatterns.org/Unique_URLs">Unique URLs pattern</a> [<a href="#AJAX-UNIQUE">AJAX-UNIQUE</a>] on the Ajax Design Patterns Web site.</p>
    Note that showing and hiding content in this way can have adverse affects on
    accessibility if not carefully handled. See WAI-ARIA [<a href="#ARIA">ARIA</a>] for more information on writing accessible rich Web applications.

    <h4><a id="bp-interaction-uri-schemes" name="bp-interaction-uri-schemes"
           >3.5.6 Make Telephone Numbers "Click-to-Call"</a></h4>

    <h5><a id="d1e1257" name="d1e1257">3.5.6.1 What it means</a></h5>

    <p>Standardized URI schemes have been defined for some common device functions,
    e.g. making phone calls, sending an SMS, and managing address books. These URI
    schemes, if supported, can enable users to easily use these functions from Web
    applications.</p>

    <h5><a id="d1e1263" name="d1e1263">3.5.6.2 How to do it</a></h5>

    <p>The most broadly supported scheme is tel: as described in RFC3966 [<a href="#RFC3966">RFC3966</a>]. Code such as the following can be used to enable
    "Click-to-Call":</p>

    <p style="text-align:center;"><code>&lt;a
    href="tel:[PHONE-NUMBER]"&gt;[PHONE-NUMBER]&lt;/a&gt;</code></p>

    <p>Note that [PHONE-NUMBER] should always be entered using the full
    international prefix (e.g. +1-201-555-0111) to ensure that it works outside of
    its home country.</p>

    <p>Similarly RFC5724 [<a href="#RFC5724">RFC5724</a>] can be used to send a GSM SMS (text message) as follows:</p>

    <p style="text-align:center;"><code>&lt;a
    href="sms:[PHONE-NUMBER]?body=[MESSAGE]"&gt;[PHONE-NUMBER]&lt;/a&gt;</code></p>

    <p>Note that at the time of writing support for this RFC is limited and device
    compatibility should be verified before deployment.</p>

    <h4><a id="bp-presentation-flow" name="bp-presentation-flow">3.5.7 Ensure
    Paragraph Text Flows</a></h4>

    <p><em>3.5.7.1 What it means</em></p>

    <p>On small screens it is important that paragraph text flows both so that it
    doesn't require horizontal scrolling and so that it will re-flow if the view
    orientation is changed. See <a href="http://www.w3.org/TR/mobile-bp/#MEASURES"
    >BP1 [MEASURES]</a> for more details.</p>

    <p><em>3.5.7.2 How to do it</em></p>

    <p>Do not use absolute or pixel measures. Use percentage and RELATIVE measures
    for containers so that text can re-flow automatically.</p>

    <h4><a id="bp-consistency" name="bp-consistency">3.5.8 Ensure Consistency Of
    State Between Devices</a></h4>

    <p><em>3.5.8.1 What it means</em></p>

    <p>This recommendation builds on the recommendation in BP1 (<a
    href="http://www.w3.org/TR/mobile-bp/#tc">5.5.1 Thematic Consistency</a>) and
    expands it to consider the <em>application preferences</em>,
    <em>personalization data</em>, and <em>state</em> that form part of the overall
    experience on a mobile Web application.</p>

    <p>User credentials valid on one device should be valid on other devices. User
    preferences captured on one device should be accessible on other devices. Data
    updated on one device should be viewable consistently on other devices.</p>

    <p>An important example of this is offering a consistent experience where data
    entered on a desktop is available on a mobile and vice versa.</p>

    <p><em>3.5.8.2 How to do it</em></p>

    <p>For any application data that is not exclusively relevant to the current
    device, favor storing it on the server so it can be shared by other devices.
    See <a href="#bp-applicationdata">3.1 Application Data</a> for more details.</p>

    <div class="head">
      <h4><a id="bp-conserve-usepush" name="bp-conserve-usepush">3.5.9 Consider
      Mobile Specific Technologies for Initiating Web Applications</a></h4>

      <h5><a id="d1e7921" name="d1e7921">3.5.9.1 What it means</a></h5>

      <p>Network-initiated content delivery ("push") methods allow notifications and
      updates to be sent to the user even when they are outside of the application
      context.</p>

      <h5><a id="d1e798" name="d1e798">3.5.9.2 How to do it</a></h5>

      <p>Push method support may be disclosed through a User Agent Profile [<a href="#UAPROF">UAPROF</a>] document if published by the device vendor, or through a device classification repository.</p>

      <p>If supported by the user agent, options for Push methods include:</p>
      <ul>
        <li>OMA Push: a widely supported enabler providing methods for user-confirmed and automatic content push, directed to mobile browsers and other user-agents. See <a href="http://www.openmobilealliance.org/Technical/wapindex.aspx">OMA Push specifications</a> [<a href="#OMA-PUSH">OMA-PUSH</a>] for more details;</li>
        <li>SMS;</li>
        <li>QR Codes;</li>
        <li>Alternative vendor-specific initiatives.</li>
      </ul>

      <h4><a id="bp-viewport" name="bp-viewport">3.5.10 Use Meta Viewport Element To
      Identify Desired Screen Size</a></h4>

      <h5><a id="d1e1944" name="d1e1944">3.5.10.1 What it means</a></h5>

      <p>Certain classes of browser attempt to display desktop pages on a small
      screen by automatically zooming the display. This can be problematic for
      applications that have already been optimized for a small screen. The viewport
      meta tag tells the device at what scale to render the page.</p>

      <h5><a id="d1e1951" name="d1e1951">3.5.10.2 How to do it</a></h5>

      <p>A typical viewport setting looks like this:</p>

      <p style="text-align:center;"><code>&lt;meta name="viewport"
      content="width=device-width, initial-scale=1.0"/&gt;</code> ,</p>

      <p>and is inserted into the <code>&lt;head&gt;</code> element
      of the HTML document. This setting informs the browser to always render the
      page at 100% (e.g. no browser based scaling) and is appropriate for pages
      specifically designed for the target screen-size.</p>
    </div>

    <h3><a id="bp-devcap" name="bp-devcap">3.6 Handling Variation in the Delivery
    Context</a></h3>

    <p>Variations in the Delivery Context (such as different device capabilities)
    is a prominent feature of the mobile Web. Web applications should adapt to
    known or discoverable properties of the Delivery Context by adjusting the
    content, navigation or page flow, with a view to offering a good user
    experience on as broad a range of devices as possible.</p>

    <h4><a id="bp-devcap-detection" name="bp-devcap-detection">3.6.1 Prefer
    Server-Side Detection Where Possible</a></h4>

    <h5><a id="d1e1397" name="d1e1397">3.6.1.1 What it means</a></h5>

    <p>Where possible, use the evidence available on the server to determine the
    properties of the Delivery Context, and adapt the responses to the client
    before transfer, thus improving the user experience and avoiding transfer of
    unnecessary or incompatible data.</p>

    <h5><a id="d1e1403" name="d1e1403">3.6.1.2 How to do it</a></h5>

    <p>In its most basic form, the minimum evidence from the requesting device is
    the HTTP request header fields. Typically, the following header fields provide
    evidence of device capabilities: </p>
    <ul>
      <li><strong>Accept:</strong> this list of MIME types can aid in the selection
      or creation of alternative content representations to suit the requesting
      device. This field is not always reliable however, and its value often
      includes "*/*", suggesting that clients can accept every MIME type.</li>
      <li><strong>User-Agent:</strong> as a generally unique (albeit opaque) string
      it can be used as a key into a device description repository [<a
      href="#DDR">DDR</a>]. The set of properties recorded in these repositories
      varies from implementation to implementation. The W3C DDR Simple API
      defines a common interface and a means of expressing the vocabulary of
      properties for such repositories.</li>
      <li><strong>X-Wap-Profile:</strong> this is a reference to the User Agent
      Profile [<a href="#UAPROF">UAPROF</a>] for the requesting device. In
      practice, the referenced profile is not always guaranteed to be available,
      valid or up-to-date, so the value of this field is sometimes used with a
      DDR where corrections to the profiles are stored. Some devices may send an
      additional field <strong>X-Wap-Profile-Diff</strong> advertising temporary
      or permanent variations of a specific device with respect to its standard
      profile.</li>
    </ul>

    <h4><a id="bp-devcap-scripting" name="bp-devcap-scripting">3.6.2 Use
    Client-Side Capability Detection Where Necessary</a></h4>

    <h5><a id="d1e1422" name="d1e1422">3.6.2.1 What it means</a></h5>

    <p>Where it is not possible to determine certain properties of the Delivery
    Context from the server, this information may be available at the client. Once
    obtained at the client, the information can be used directly to adapt the
    presentation, or it can used to request alternative, adapted content from the
    server.</p>

    <h5><a id="d1e1428" name="d1e1428">3.6.2.2 How to do it</a></h5>

    <p>There are a few client-side solutions available to the developer:</p>

    <p style="margin-left:2em;"><strong>JavaScript:</strong> this is the most
    common solution. A script determines the device / browser properties and
    manipulates the content and behaviour of the application accordingly. This can
    be done in two ways:</p>
    <ol>
      <li style="margin-left:4em">By encapsulating the differing
      behaviors in the control logic of the application (e.g. <code>if (some_api_exists) {
      ...</code>). Typically the Delivery Context information is gathered at the
      start of the session, though dynamic information (e.g. current screen
      orientation) should be refreshed during the session.</li>
      <li style="margin-left:4em">By passing the gathered information back to the
      server and requesting alternative content (e.g. either by dynamically
      adding a new <code>&lt;script&gt;</code>
      element to the DOM or by an XHR request). </li>
    </ol>

    <p style="margin-left:2em;"><strong>CSS Media Types:</strong> CSS Media Types
    allow different stylesheets to be associated with different media types (e.g.
    print, screen, mobile) and are traditionally used to repurpose content for
    these destinations. Since the list of recognized media types is limited,
    however, and devices are notoriously idiosyncratic in their interpretation of
    types, it is in general not a helpful technology in this context. See Media
    Types [<a href="#CSSMT">CSSMT</a>] for more details.</p>

    <p style="margin-left:2em;"><strong>CSS Media Queries:</strong> Media queries
    are an extension to the "media-types" paradigm that allow developers to apply
    specific style rules based on the device display characteristics (e.g. screen
    width, orientation, or resolution). At the time of writing this specification
    is not fully supported, but can provide a useful way to modify the page layout
    (for example to re-flow sections of text) in a more maintainable, declarative
    way than is possible with script. See Media Queries [<a
    href="#CSSMQ">CSSMQ</a>] for more details. </p>

    <h4><a id="bp-devcap-classify" name="bp-devcap-classify">3.6.3 Use Device
    Classification to Simplify Content Adaptation</a></h4>

    <h5><a id="d1e1451" name="d1e1451">3.6.3.1 What it means</a></h5>

    <p>If a large number of devices are being targeted, or if the application is
    sensitive to the permutations of a large number of configuration properties,
    the number of application variants required might quickly become
    unmanageable.</p>

    <p>To combat this, classify target devices and build a single application
    variant for each class. This allows you to exploit device capabilities with a
    manageable code base.</p>

    <h5><a id="d1e1464" name="d1e1464">3.6.3.2 How to do it</a></h5>

    <p>Identify the target devices for the application and assign these to device
    classes of varying capability. Focus on application variants that work in each
    class rather than building device-specific exceptions for every variation in
    device configuration.</p>

    <p>Device classes should be defined on an application by application basis, so
    that the variants can be tailored accordingly. </p>

    <p>Example 1: Possible definition of application classes based on rendering and
    device API capabilities:</p>

    <p style="margin-left:2em;"><strong>Class 1:</strong> Basic XHTML support, no
    or very basic scripting. No XHR support. (Even if these kind of devices are not
    being explicitly supported, it is often advisable to support a non-XHR version
    in case JavaScript has been disabled on the device).</p>

    <p style="margin-left:2em;"><strong>Class 2:</strong> Full AJAX and JavaScript
    support.</p>

    <p style="margin-left:2em;"><strong>Class 3:</strong> Advanced device APIs, for
    example: access to location API, device PIM data, or application cache.</p>

    <p>Example 2: Possible definition of application classes based on supported
    user-interaction modes:</p>

    <p style="margin-left:2em;"><strong>Class 1:</strong> Pointer Based.</p>

    <p style="margin-left:2em;"><strong>Class 2:</strong> Touch Based.</p>

    <h4><a id="bp-devcap-scripting-support" name="bp-devcap-scripting-support"
           >3.6.4 Support a non-JavaScript Variant if Appropriate</a></h4>

    <h5><a id="d1e1493" name="d1e1493">3.6.4.1 What it means</a></h5>

    <p>Scripted and XHR based applications are not supported on all browsers. If
    broadest reach is a primary concern then consider providing a variant of the
    application that uses synchronous FORM posts in place of XHR requests. This
    Best Practice is related (albeit with a differing focus) to <a
    href="http://www.w3.org/TR/mobile-bp/#OBJECTS_OR_SCRIPT">BP 1 [
    OBJECTS_OR_SCRIPT]</a>.</p>

    <h5><a id="d1e1499" name="d1e1499">3.6.4.2 How to do it</a></h5>

    <p>Essentially this BP states that it is favorable to support "Class 1" devices
    as defined in the first example above if appropriate. Doing this will ensure
    that the application can be used across as broad a range of devices as
    possible. Furthermore, in some cases a non-JavaScript version can be useful for
    simple operations in low-bandwidth situations.</p>

    <p>In some cases, however, a particular application simply has no
    non-JavaScript counterpart (e.g. a Web based game, an Instant Messaging client)
    in which case the server should return a response with human readable content
    explaining the situation in more detail.</p>

    <p>Ideally, content should be adapted before transfer by checking whether or
    not the device supports JavaScript using a DDR or local index. However, in some
    cases (e.g. if the device has disabled JavaScript) JavaScript may still be sent
    to a device that can't process it. To cover this case, a <code>&lt;noscript&gt;</code>
    element should always be included and contain a suitably informative
    message.</p>

    <h4><a id="bp-devcap-user-choice" name="bp-devcap-user-choice">3.6.5 Offer
    Users a Choice of Interfaces</a></h4>

    <h5><a id="d1e15151" name="d1e15151">3.6.5.1 What it means</a></h5>

    <p>Not only is device characteristic detection imperfect, it cannot always
    account for the differing use cases of an application. Therefore automatic
    detection is not sufficient as the only mechanism for determining which version
    is appropriate.</p>

    <h5><a id="d1e15152" name="d1e15152">3.6.5.2 How to do it</a></h5>

    <p>Where multiple versions of an application exist (e.g. to support the various
    device classifications) always offer the user the opportunity to change the
    selection.</p>

    <p>Always attempt to default to the most appropriate UI on first use.</p>

    <p>Always remember the user's preference for future visits in a cookie or local
    data store.</p>

    <h3><a id="bp-further" name="bp-further">3.7 Further Considerations</a></h3>

    <p>The Mobile Web Best Practices Working Group would like to draw the attention
    of Web application developers on the following considerations. These
    considerations should not be viewed as best practices, because they are not
    prevalent in the development community at the time of writing. They are
    published as advisory notes.</p>

    <h4><a id="bp-canvas" name="bp-canvas">3.7.1 Consider Use of Canvas Element or
    SVG For Dynamic Graphics</a></h4>

    <h5><a id="bp-canvas-meaning" name="bp-canvas-meaning">3.7.1.1 What it
    means</a></h5>

    <p>Canvas and SVG provide alternative options for incorporating graphics in a
    Web application. Support for these technologies varies across devices so in
    many cases the choice of which technology to use will depend on the target
    devices for a given application.</p>

    <p>The canvas element specifies a display region where JavaScript can be used
    to draw simple graphics. In contrast, SVG is an XML language for defining
    vector graphic elements that are added to a DOM which can be modified using
    JavaScript.</p>

    <p>SVG is well-suited for graphics that must be scalable and whose components
    need to be modified (e.g. panning and zooming a map) whereas canvas is better
    suited where a static bitmap is sufficient (e.g. drawing a scatter-chart or
    creating visual effects).</p>

    <p>If speed is important, canvas may be more effective. However since Canvas
    generates a flat bitmap it is not inherently accessible and so should not be
    used as the sole means of conveying information.</p>

    <h5><a id="bp-canvas-how" name="bp-canvas-how">3.7.1.2 How to do it</a></h5>

    <p>See <a href="http://www.w3.org/TR/html5/the-canvas-element.html#the-canvas-element">the Canvas Element in the HTML5 specification</a> [<a href="#HTML5">HTML5</a>, section 4.8.10] for information on how to use the Canvas element.</p>

    <p>See <a href="http://www.w3.org/Graphics/SVG/">W3C Scalable Vector Graphics (SVG) home page</a> [<a href="#SVG">SVG</a>] for information on how to use SVG.</p>

    <h4><a id="bp-inform-automation" name="bp-inform-automation">3.7.2 Inform the
    User About Automatic Network Access</a></h4>

    <h5><a id="d1e607" name="d1e607">3.7.2.1 What it means</a></h5>

    <p>Network traffic on a mobile device depletes the battery and may incur
    expense -- so it is important to inform the user when accessing the network.
    Whenever an application makes asynchronous XHR data requests, whether in
    response to a user action or automatically, this should be indicated in an
    appropriate manner so that the user remains informed and in control.</p>

    <h5><a id="d1e613" name="d1e613">3.7.2.2 How to do it</a></h5>

    <p>Applications should disclose how they use network resources. A simple icon
    indicating background activity is usually sufficient and does not interrupt the
    flow of the application. If extensive background network activity is required
    the user should be informed when they first visit the site, when they first
    sign-in, or in associated help pages.</p>

    <p>The kinds of detailed information that could be disclosed in associated help
    pages or terms of service are:</p>
    <ul>
      <li>how often the application will interact with the Internet - e.g. every 5
      minutes, hourly, daily;</li>
      <li>for how long the automatic behavior will continue;</li>
      <li>how heavy the overall usage is expected to be or the type of service plan
      recommended.</li>
    </ul>

    <h4><a id="bp-inform-network" name="bp-inform-network">3.7.3 Provide Sufficient
    Means to Control Automatic Network Access</a></h4>

    <h5><a id="d1e6311" name="d1e6311">3.7.3.1 What it means</a></h5>

    <p>If an application makes automatic network requests (e.g. to poll the server
    for updates or to automatically store an updated client state) a means to
    control this activity should be provided.</p>

    <h5><a id="d1e6312" name="d1e6312">3.7.3.2 How to do it</a></h5>

    <p>All applications that access the network automatically should provide a
    means for the user to disable that activity. When automatic network activity is
    disabled, periodically prompt the user to make network requests.</p>

    <p>Consider allowing the user to adjust the polling schedule and to control
    which activities are allowed to initiate network requests.</p>

    <h2><a id="dependent-properties" name="dependent-properties"
           >Appendix 1: Best Practice Dependent Device Properties</a></h2>

    <p>The following device properties included in the DDR Core Vocabulary [<a
    href="#DDR-VOCAB">DDR-VOCAB</a>] are of particular value in supporting best
    practices recommended in this document. They should be available in any DDR
    supporting the W3C's DDR Core Vocabulary:</p>
    <ul>
      <li>Display Width, Display Height, Display Color Depth</li>
      <li>Input Devices</li>
      <li>Markup Support</li>
      <li>Stylesheet Support</li>
      <li>Image Format Support</li>
      <li>Input Mode Support</li>
      <li>Cookie Support</li>
      <li>Script Support</li>
    </ul>

    <h2><a id="references" name="references">Appendix 2: References</a></h2>

    <h3><a id="ref-mwi" name="ref-mwi">2.1 MWI References</a></h3>

    <p><strong><a name="MWBP" id="MWBP">MWBP</a></strong></p>

    <p style="margin-left:2em;">Mobile Web Best Practices 1.0, Jo Rabin, Editor,
    W3C Recommendation, 29 July 2008 (see <a
    href="http://www.w3.org/TR/mobile-bp/">http://www.w3.org/TR/mobile-bp/</a>) </p>

    <h3><a id="ref-dip" name="ref-dip">2.2 Device Independence</a></h3>
    <dl>
      <dt class="label"><a name="DCODI" id="DCODI">DCODI</a></dt>
      <dd>Delivery Context Overview for Device Independence, , R. Gimson, R.
      Lewis, S. Sathish, Editors, W3C Working Group Note, 20 March 2006 (See <a
      href="http://www.w3.org/TR/di-dco/">http://www.w3.org/TR/di-dco/</a>)</dd>
      <dt class="label"><a name="DIGLOSS" id="DIGLOSS">DIGLOSS</a></dt>
      <dd>Glossary of Terms for Device Independence, R. Lewis, Editor, W3C
      Working Draft (work in progress), 18 January 2005 (See <a
      href="http://www.w3.org/TR/2005/WD-di-gloss-20050118/">http://www.w3.org/TR/2005/WD-di-gloss-20050118/</a>)</dd>
      <dt class="label"><a name="DIP" id="DIP">DIP</a></dt>
      <dd>Device Independence Principles, R. Gimson, Editor, W3C Working Group
      Note, 1 September 2003 (See <a
      href="http://www.w3.org/TR/2003/NOTE-di-princ-20030901/">http://www.w3.org/TR/2003/NOTE-di-princ-20030901/</a>)</dd>
    </dl>

    <h3><a id="ref-web" name="ref-web">2.3 Web, Protocols and Languages</a></h3>
    <dl>
      <dt class="label"><a name="CSS" id="CSS">CSS</a></dt>
      <dd>Cascading Style Sheets (CSS1) Level 1 Specification, Håkon Wium Lie,
      Bert Bos, Editors, W3C Recommendation, 11 January 1999, revised 11 April
      2008 (See <a
      href="http://www.w3.org/TR/2008/REC-CSS1-20080411/">http://www.w3.org/TR/2008/REC-CSS1-20080411/</a>)</dd>
      <dt class="label"><a name="CSS2" id="CSS2">CSS2</a></dt>
      <dd>Cascading Style Sheets, level 2 CSS2 Specification, Bert Bos, Håkon
      Wium Lie, Chris Lilley, Ian Jacobs, Editors, W3C Recommendation, 12 May
      1998, revised 11 April 2008 (See <a
      href="http://www.w3.org/TR/2008/REC-CSS2-20080411/">http://www.w3.org/TR/2008/REC-CSS2-20080411/</a>)</dd>
      <dt class="label"><a name="HTTP1.0" id="HTTP1.0">HTTP1.0</a></dt>
      <dd>Hypertext Transfer Protocol -- HTTP/1.0 Request for Comments: 1945, T.
      Berners-Lee, R. Fielding, H. Frystyk, May 1996 (See <a
      href="http://www.w3.org/Protocols/rfc1945/rfc1945">http://www.w3.org/Protocols/rfc1945/rfc1945</a>)</dd>
      <dt class="label"><a name="HTTP1.1" id="HTTP1.1">HTTP1.1</a></dt>
      <dd>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 <a
      href="http://www.w3.org/Protocols/rfc2616/rfc2616.html">http://www.w3.org/Protocols/rfc2616/rfc2616.html</a>)</dd>
      <dt class="label"><a name="XML" id="XML">XML</a></dt>
      <dd>Extensible Markup Language (XML) 1.0 (Fifth Edition), Tim Bray, Jean
      Paoli, C. M. Sperberg-McQueen, Eve Maler, François Yergeau, Editors, W3C
      Recommendation, 26 November 2008 (See <a
      href="http://www.w3.org/TR/2008/REC-xml-20081126/">http://www.w3.org/TR/2008/REC-xml-20081126/</a>)</dd>
    </dl>

    <h3><a id="ref-other" name="ref-other">2.4 Other References</a></h3>
    <dl>
      <dt class="label"><a name="AJAX-UNIQUE" id="AJAX-UNIQUE">AJAX-UNIQUE</a></dt>
      <dd>Unique URLs pattern on Ajax Design Patterns Web site (See <a href="http://ajaxpatterns.org/Unique_URLs">http://ajaxpatterns.org/Unique_URLs</a>)</dd>

      <dt class="label"><a name="ARIA" id="ARIA">ARIA</a></dt>
      <dd>Accessible Rich Internet Applications (WAI-ARIA) 1.0, James Craig et
      al, W3C Working Draft, 16 September 2010 (See <a
      href="http://www.w3.org/TR/wai-aria/">http://www.w3.org/TR/wai-aria/</a>)</dd>
      <dt class="label"><a name="BONDI" id="BONDI">BONDI</a></dt>
      <dd>OMTP Reference Implementation (see <a
      href="http://bondi.omtp.org/">http://bondi.omtp.org/</a>)</dd>
      <dt class="label"><a name="CSSMQ" id="CSSMQ">CSSMQ</a></dt>
      <dd>Media Queries, Håkon Wium Lie, Tantek elik, Daniel Glazman, Anne van
      Kesteren, W3C Candidate Recommendation, 27 July 2010 (see <a
      href="http://www.w3.org/TR/css3-mediaqueries/">http://www.w3.org/TR/css3-mediaqueries/</a>)</dd>
      <dt class="label"><a name="CSSMT" id="CSSMT">CSSMT</a></dt>
      <dd>Cascading Style Sheets Level 2 Revision 1 (CSS 2.1) Specification, Bert
      Bos et al, W3C Candidate Recommendation, 08 September 2009 (see <a
      href="http://www.w3.org/TR/CSS21/media.html">http://www.w3.org/TR/CSS21/media.html</a>)</dd>
      <dt class="label"><a name="DAP" id="DAP">DAP</a></dt>
      <dd>W3C Device APIs Working Group (see <a
      href="http://www.w3.org/2009/dap/">http://www.w3.org/2009/dap/</a>)</dd>
      <dt class="label"><a name="DDR" id="DDR">DDR</a></dt>
      <dd>Device Description Repository Simple API, Jo Rabin et al, W3C
      Recommendation, 05 December 2008 (see <a
      href="http://www.w3.org/TR/DDR-Simple-API/">http://www.w3.org/TR/DDR-Simple-API/</a>)</dd>
      <dt class="label"><a name="DDR-VOCAB" id="DDR-VOCAB">DDR-VOCAB</a></dt>
      <dd>Device Description Repository Core Vocabulary, Jo Rabin et al, W3C
      Working Group Note, 14 April 2008 (see <a
      href="http://www.w3.org/TR/ddr-core-vocabulary/">http://www.w3.org/TR/ddr-core-vocabulary/</a>)</dd>
      <dt class="label"><a name="EXI" id="EXI">EXI</a></dt>
      <dd>Efficient XML Interchange, W3C Candidate Recommendation, John Schneider
      and Takuki Kamiya, 08 December 2009 (see <a
      href="http://www.w3.org/TR/exi/">http://www.w3.org/TR/exi/</a>)</dd>
      <dt class="label"><a name="HTML5" id="HTML5">HTML5</a></dt>
      <dd>HTML5, Ian Hickson and David Hyatt, W3C Working Draft, 19 October 2010
      (see <a
      href="http://www.w3.org/TR/html5/">http://www.w3.org/TR/html5/</a>)</dd>
      <dt class="label"><a name="HTML5-OFFLINE"
                           id="HTML5-OFFLINE">HTML5-OFFLINE</a></dt>
      <dd>HTML5, Ian Hickson and David Hyatt, W3C Working Draft, 19 October 2010
      (see <a
      href="http://www.w3.org/TR/html5/offline.html#offline">http://www.w3.org/TR/html5/offline.html#offline</a>)</dd>

      <dt class="label"><a name="JSCOMP" id="JSCOMP">JSCOMP</a></dt>
      <dd>The JavaScript CompressorRater (see <a href="http://compressorrater.thruhere.net">http://compressorrater.thruhere.net</a>)</dd>

      <dt class="label"><a name="JSON-PARSE" id="JSON-PARSE">JSON-PARSE</a></dt>
      <dd>Implementation of a secure JSON parser in JavaScript (see <a href="https://github.com/douglascrockford/JSON-js/raw/master/json_parse.js">https://github.com/douglascrockford/JSON-js/raw/master/json_parse.js</a>)</dd>

      <dt class="label"><a name="OFFLINE" id="OFFLINE">OFFLINE</a></dt>
      <dd>Offline Web Applications, Anne Van Kesteren and Ian Hickson, W3C
      Working Group Note, 30 May 2008 (see <a
      href="http://www.w3.org/TR/offline-webapps/">http://www.w3.org/TR/offline-webapps/</a>)</dd>

      <dt class="label"><a name="OMA-PUSH" id="OMA-PUSH">OMA-PUSH</a></dt>
      <dd>OMA Push (see <a href="http://www.openmobilealliance.org/Technical/wapindex.aspx">http://www.openmobilealliance.org/Technical/wapindex.aspx</a>)</dd>

      <dt class="label"><a name="OPERA" id="OPERA">OPERA</a></dt>
      <dd>Opera Web Widget API (see <a
      href="http://dev.opera.com/libraries/widgetobject/">http://dev.opera.com/libraries/widgetobject/</a>)</dd>
      <dt class="label"><a name="OWASP" id="OWASP">OWASP</a></dt>
      <dd>Open Web Application Security Project (see <a
      href="http://www.owasp.org/index.php/Main_Page">http://www.owasp.org/index.php/Main_Page</a>)</dd>

      <dt class="label"><a name="RFC2397" id="RFC2397">RFC2397</a></dt>
      <dd>The "data" URL scheme, L.Masinter. IETF, August 1998
      (See <a href="http://www.ietf.org/rfc/rfc2397.txt">http://www.ietf.org/rfc/rfc2397.txt</a>)</dd>

      <dt class="label"><a name="RFC3966" id="RFC3966">RFC3966</a></dt>
      <dd>The tel URI for Telephone Numbers, H. Schulzrinne. IETF, December 2004
      (See <a
      href="http://www.ietf.org/rfc/rfc3966.txt">http://www.ietf.org/rfc/rfc3966.txt</a>)</dd>

      <dt class="label"><a name="RFC4627" id="RFC4627">RFC4627</a></dt>
      <dd>The application/json Media Type for JavaScript Object Notation (JSON),
      D. Crockford, July 2006 (see <a
      href="http://www.ietf.org/rfc/rfc4627">http://www.ietf.org/rfc/rfc4627</a>)</dd>
      <dt class="label"><a name="RFC5724" id="RFC5724">RFC5724</a></dt>
      <dd>URI Scheme for Global System for Mobile Communications (GSM) Short
      Message Service (SMS), E. Wilde and A. Vaha-Sipila. IETF, January 2010
      (See <a
      href="http://www.ietf.org/rfc/rfc5724.txt">http://www.ietf.org/rfc/rfc5724.txt</a>)</dd>

      <dt class="label"><a name="SVG" id="SVG">SVG</a></dt>
      <dd>W3C Scalable Vector Graphics (SVG) home page (see <a href="http://www.w3.org/Graphics/SVG/">http://www.w3.org/Graphics/SVG/</a>)</dd>

      <dt class="label"><a name="UAPROF" id="UAPROF">UAPROF</a></dt>
      <dd>Open Mobile Alliance OMA-TS-UAProf-V2_0-20060206-A User Agent Profile
      Approved Version 2.0 06 Feb 2006 (See <a
      href="http://www.openmobilealliance.org/technical/release_program/docs/UAProf/V2_0-20060206-A/OMA-TS-UAProf-V2_0-20060206-A.pdf">http://www.openmobilealliance.org/technical/release_program/docs/UAProf/V2_0-20060206-A/OMA-TS-UAProf-V2_0-20060206-A.pdf</a>)</dd>
      <dt class="label"><a name="WCAG20" id="WCAG20">WCAG20</a></dt>
      <dd>Web Content Accessibility Guidelines 2.0, B. Caldwell, M. Cooper, L. Guarino Reid, G. Vanderheiden et al, W3C Recommendation 11 December 2008 (see <a
      href="http://www.w3.org/TR/WCAG20/">http://www.w3.org/TR/WCAG20/</a>)</dd>
      <dt class="label"><a name="WEBAPPS" id="WEBAPPS">WEBAPPS</a></dt>
      <dd>W3C WebApps Working Group (see <a
      href="http://www.w3.org/2008/webapps/">http://www.w3.org/2008/webapps/</a>)</dd>
      <dt class="label"><a name="WIDGETS" id="WIDGETS">WIDGETS</a></dt>
      <dd>Widget Packaging and Configuration, Marcos Cáceres, W3C Working Draft, 5 October 2010 (see <a href="http://www.w3.org/TR/widgets/">http://www.w3.org/TR/widgets/</a>)</dd>
      <dt class="label"><a name="WTAI" id="WTAI">WTAI</a></dt>
      <dd>WAP Forum wap-268-wtai-20010908-a Wireless Telephony Application
      Interface Specification (See <a
      href="http://www.openmobilealliance.org/tech/affiliates/LicenseAgreement.asp?DocName=/wap/wap-268-wtai-20010908-a.pdf">http://www.openmobilealliance.org/tech/affiliates/LicenseAgreement.asp?DocName=/wap/wap-268-wtai-20010908-a.pdf</a>)</dd>

      <dt class="label"><a name="XHTML-Basic" id="XHTML-Basic">XHTML-Basic</a></dt>
      <dd>XHTML Basic 1.1 - Second Edition, Shane McCarron, Masayasu Ishikawa, Editors, W3C Recommendation, 23 November 2010 (See <a
      href="http://www.w3.org/TR/2010/REC-xhtml-basic-20101123/">http://www.w3.org/TR/2010/REC-xhtml-basic-20101123/</a>)</dd>
    </dl>
  </div>

  <h2><a id="acknowledgements" name="acknowledgements">Appendix 3:
  Acknowledgments</a></h2>

  <p>The editors would like to thank members of the BPWG for contributions of
  various kinds. The editors would also like to thank contributors to the public
  list, and contributors of Last Call comments whose comments have been taken
  into account in the creation of this document.</p>

  <p>The editors acknowledge significant written contributions from:</p>

  <p>* Daniel Appelquist, Vodafone</p>

  <p>* Jo Rabin, mTLD Mobile Top Level Domain (dotMobi)</p>

  <p>* Phil Archer, W3C</p>

  <p>* Jeff Sonstein, Rochester Institute of Technology</p>

  <p>* François Daoust, W3C</p>

  <p>* Scott Hughes, Vodafone</p>
</body>
</html>