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.

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

The W3C Membership and other interested
parties are invited to review the document and send comments to
public-bpwg-comments@w3.org (with public archive ) through 19
NovemberSince publication as a
Proposed Recommendation on21 October 2010 .
Advisory Committee Representatives should consult their WBS
questionnaires . Note that substantive technical comments were
expected during , the second Last
Call review periodWorking Group
clarified that ended 6 August 2010.
Changesalternative compression formats
(such as EXI) referred to in this
version were introduced based on feedback received during the
review periodsection3.4.1 Use Transfer
Compressionmay not share
some of the second Last Call working
draft .impediments of common
compression formats. A
diff version is available. No substantive change has been made.
Changes are: Clarified that the 3.2 Security
and privacy section does not attempt to provide an exhaustive
survey of security issues and added reference to OWASP for a good
summary of common Web security Best Practices. Clarified that
informational images are not good candidates for spriting in 3.4.6
Aggregate Static Images into a Single Composite Resource (Sprites)
. Added a note that new interaction methods are likely to emerge in
the future in 3.5.3 Design for Multiple Interaction Methods and
added reference to the Web Content Accessibility Guidelines 2.0 as
available guidelines for assistive technology. Added another
example to the 3.5.6 Make Telephone Numbers "Click-to-Call" section
that uses the SMS scheme defined in RFC5724. An implementation
report is available. This document advanced directly from Last Call
to Proposed Recommendation as the Working Group gathered sufficient
implementation feedback during the previous Candidate
Recommendation phase and the following Last Call .

The document contains statements that may be regarded as
forward-looking when this document is published (12 October(14
December 2010). Examples provided in the How to do
it 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
implementation reportis
available.

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 Membership. ThisRecommendation. It is a draftstable document
and may be updated, replacedused as reference material or
obsoleted by other documents at any time.
Itcited from another document. W3C's
role in making the Recommendation is inappropriate to cite this
document as other than work in progress.draw attention to the specification and to promote its
widespread deployment. This enhances the functionality and
interoperability of the Web.

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.

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) [MWBP] .

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.

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

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.

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 will soon become
fully qualified Best Practices (e.g. in prevalent use within the
development community).

In building a Web application, it is not necessary to implement
all 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.

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.

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 [ WIDGETS ] and also in a number of vendor-specific
initiatives.

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 uniquely mobile would most
likely be very short. With this in mind, the focus of this document
is to address those aspects of Web application development for
which there are additional, non-trivial concerns associated with
the mobile context. This applies equally both to the limitations of
the mobile context (e.g. small screen, 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).

1.3.4 Delivery Context

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

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.

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.

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 3.6 Handling
Variations in Delivery Context .

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.

1.5 Terminology

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.

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

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

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

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.

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.

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
BP1 [COOKIES] Do
not rely on cookies being available for more cookie related
caveats.

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 [
WEBAPPS ] and Device APIs working group [
DAP ] for more information. Additionally, some
examples of existing technologies that support client-side storage
APIs are BONDI [ BONDI ], HTML5 [ HTML5 ], and Opera Widgets [ OPERA ].

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:

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.

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.

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 [ OFFLINE ].

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
3.5.8 Ensure Consistency Of State Between
Devices for further discussion on these topics.

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.

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 (
navigator.onLine ) to indicate whether the client is
currently online, and dispatches two events on the Window object to
indicate a change of network state ( online and
offline ).

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.

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 [ OWASP ] 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.

A common technique is to use JSON to transfer data to a client
and then use JavaScript's eval() function to parse it.
This is a powerful technique, since on constrained devices
eval() 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.

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.

See RFC4627 [ RFC4627 ] for details on
how to ensure a JSON datafeed is suitably escaped and can be safely
passed into JavaScript's eval() function.

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:

Pictures, music, and video clips;

Contacts, calendar (PIM data);

Call history;

System data (battery, coverage, roaming, location);

Media recording (record audio/video clip, get new
picture);

Device context (e.g. location, connectivity, profile
setting).

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 application behaviour in situations where
the native functionality of the browser may not be sufficient.

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.

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.

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.

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.

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.

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

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.

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.

Process HTML, JavaScript and CSS files to remove whitespace and
minify before delivery.

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

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.

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.

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.

Throttle low-priority requests:

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.

Back off during periods of inactivity:

If the application polls for updates, it should monitor user
activity and poll less frequently during inactive periods.

Device Context:

If supported by the device, use awareness of current
connectivity (e.g. WiFi) to select an appropriate level of
interaction.

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.

3.4.5.2 How to do it

As far as makes sense after taking into account 3.5.2 Minimize Perceived Latency
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.

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.

3.4.6.2 How to do it

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.

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

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

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.

3.4.7.2 How to do it

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

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.

For example,

<img
src="http://www.example.com/userimages/joeblogs-67f90da089da">

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

3.4.8.2 How to do it

Set the resource caching policy to "never expire" by setting
the Expires header to a date in the far future.

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.

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.

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

Offline Web application technologies like HTML5 AppCache [
HTML5-OFFLINE ] 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.

Consider the following techniques to help minimize application
start time:

Use Offline Technology: 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.

Consider Partitioning Large Scripts: 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.

Use Local Storage: Where appropriate, store a
snapshot of the last application state so it can be displayed
immediately on start-up without requiring a server roundtrip.

Minimize Number of Local Storage Queries: 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.

Enable Incremental Rendering : 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.

Keep the User Informed of Activity: 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.

Avoid Page Reloads: To reflect changes in
state or show different views within an application, update pages
dynamically (by manipulating the DOM) rather than reloading
them.

Preload Probable Next Views: Preload data for
frequently traversed paths in the application so it can be
displayed more quickly when the user requests it.

Interaction methods vary across devices. Three main interaction
methods should be considered when designing the UI:

Focus Based: The browser focus "jumps" from element to
element;

Pointer Based: Key-based navigation controls a pointer that can
cover any part of the screen;

Touch Based: Events are related directly to a finger or stylus
touch position on the screen.

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.

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 [
WCAG20 ].

The JavaScript focus method can be used to move the
focus to the part of a page that has changed. However, if
unexpected, this can confuse or irritate the user, especially if
returning to the previous focus is not easy.

Web applications can switch views without a full page reload by
showing and hiding sections of content. However, this means that
the browser <back> 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:

Enabling deep links (e.g. to the content of a specific email)
means the user can bookmark this view and return to it
quickly;

Enabling the browser history provides a natural method to
navigate application views that is natively supported by the
browser.

3.5.5.2 How to do it

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

Note that showing and hiding content in this way can have adverse
affects on accessibility if not carefully handled. See WAI-ARIA [
ARIA ] for more information on writing
accessible rich Web applications.

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.

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 BP1 [MEASURES] for
more details.

3.5.7.2 How to do it

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

This recommendation builds on the recommendation in BP1 (
5.5.1 Thematic
Consistency ) and expands it to consider the application
preferences , personalization data , and
state that form part of the overall experience on a mobile
Web application.

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.

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

3.5.8.2 How to do it

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 3.1 Application
Data for more details.

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.

and is inserted into the <head> 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.

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.

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.

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:

Accept: 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.

User-Agent: as a generally unique (albeit
opaque) string it can be used as a key into a device description
repository [ DDR ]. 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.

X-Wap-Profile: this is a reference to the User
Agent Profile [ UAPROF ] 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
X-Wap-Profile-Diff advertising temporary or
permanent variations of a specific device with respect to its
standard profile.

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.

JavaScript: 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:

By encapsulating the differing
behaviors in the control logic of the application (e.g. if
(some_api_exists) { ... ). 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.

By passing the gathered information
back to the server and requesting alternative content (e.g. either
by dynamically adding a new <script> element to
the DOM or by an XHR request).

CSS Media Types: 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 [ CSSMT ] for more
details.

CSS Media Queries:
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 [
CSSMQ ] for more details.

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.

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.

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.

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

Class 1: 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).

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 BP 1 [
OBJECTS_OR_SCRIPT] .

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.

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.

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 <noscript>
element should always be included and contain a suitably
informative message.

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.

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.

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.

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.

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

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.

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.

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.

The kinds of detailed information that could be disclosed in
associated help pages or terms of service are:

how often the application will interact with the Internet -
e.g. every 5 minutes, hourly, daily;

for how long the automatic behavior will continue;

how heavy the overall usage is expected to be or the type of
service plan recommended.

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.

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

The following device properties included in the DDR Core
Vocabulary [ DDR-VOCAB ] 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:

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.