Copyright
© 2008 2009
W3C ® (
MIT ,
ERCIM
, Keio ), All Rights Reserved.
W3C liability
, trademark
and document
use rules apply.
This document specifies Best Practices for the development and
delivery of Web applications on mobile devices. The recommendations
expand upon statements made in the Mobile Web Best Practices 1.0
(BP1), especially concerning statements
those that relate to the exploitation
of device capabilities and awareness of the delivery context.
Furthermore, since BP1 was written, networks and devices have
continued to evolve, with the result that a number of Best
Practices that were omitted from BP1 can now be included.
The recommendation is primarily directed at creators,
maintainers and operators of Web applications. Readers of this
document are expected to be familiar with the creation of Web
sites, and to have a general familiarity with the technologies
involved, such as Web servers, HTTP, and Web application
technologies. Readers are not expected to have a background in
mobile-specific mobile technologies or previous experience with
BP1.
This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index at http://www.w3.org/TR/.
Incomplete draft : This document is a
Second Third Public Working Draft and is not complete. It
is subject to major changes and is therefore not intended for
implementation. In particular, the list of Best Practices is not
settled yet. The document is provided for review and
feedback only . Please send feedback to public-bpwg-comments@w3.org
( archive
).
The Working Group is particularly seeking
feedback on: techniques for securing personal data on mobile
devices, and the relative impacts of using HTTPS and other
techniques, see Use HTTPS when Exchanging User Credentials . an
example "Safe EVAL" algorithm that can be included in
invites the document, or a publicly available library that can be
referenced, see Use a Safe EVAL for JSON Datafeeds
best/most-commonly used tools developer
community to minimize the size of a Web
application, see Minimize application size . the relative impacts
of Web application activities on battery life, see Use
Power-Efficient Methods . review
the use set
of techniques aimed at separating out
Javascript Best Practices and
CSS that provide
feedback. Examples and techniques are rarely used, particularly
welcome. Some Best Practices are still being investigated and
appear as placeholders in particular the use of
iframe document:
This document was developed by the Mobile Web Best Practices
Working Group as part of the Mobile Web Initiative
. Most of the best practices
sections and Best Practices statements
were changed since the publication of the First Second Public
Working Draft on 29 July 22 December 2008 . A complete list of changes is available.
Publication as a Working Draft does not imply endorsement by the W3C Membership. This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress.
This document is a Second
Third Public Working Draft intended to
progress along the Recommendation track and be eventually published
as a Recommendation.
This document was produced by a group operating under the 5 February 2004 W3C Patent Policy . This document is informative only. W3C maintains a public list of any patent disclosures made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s) must disclose the information in accordance with section 6 of the W3C Patent Policy .
1 Introduction
1.1 Purpose of the
Document
1.2 Audience
1.3 Scope
1.3.1 Best Practices
1.3.2 Web Application
1.3.3 Mobile Context
1.3.4 Delivery Context
1.4 Relationship to
other Best Practices and recommendations
1.5 Terminology
2 Structure of Best Practice
Statements
3 Best Practice Statements
3.1 Personalization Application
Data
3.1.1 Retain Information For Personalization Use Cookies
Sparingly
3.1.2 Automatically Identify the User Use Appropriate Client-Side
Storage Technologies for Local Data
3.1.3
Replicate Local
Data
3.2 Security and
privacy
3.2.1 Use HTTPS when Exchanging User Credentials
3.2.2 Secure JSON
Datafeeds
3.2.3
Use a Safe EVAL for JSON
Datafeeds Do not Execute Untrusted
JavaScript
3.3 User
awareness Awareness and control
Control
3.3.1 Inform the User About Automatic Network
Access
3.3.2 Provide Sufficient Means to Control Automatic Network
Access
3.3.3 Ensure the User is Informed About Use of
Personal and Device Information
3.3.4
Enable
Automatic Login
3.4 Conservative use
of resources
3.4.1 Use Transfer Compression
3.4.2 Minimize Application and Data Size
3.4.3 Avoid Redirects
3.4.4 Minimize
Automatically Issued Optimize
Network Requests
3.4.5 Use Push Methods to Reduce Pull Traffic
3.4.6
Minimize External Resources
3.4.7
Consider Inlining Small Stylesheets and Script Resources
3.4.8
3.4.6
Sprite Aggregate Static Images ("Sprites") into a Single Composite Resource 3.4.9
3.4.7
Inline Include Background Images Inline in CSS Stylesheet Style
Sheets 3.4.10
3.4.8
Use Fingerprinting to Cache Dynamic Resources
3.4.11
3.4.9
Make Cache AJAX Datafeeds
Cachable 3.4.12 Use
Power-Efficient Methods
3.4.13 Minimize DOM
Manipulation 3.4.14
Reduce Cookie Size Data
3.4.15
3.4.10
Don't Send Cookie Information Unnecessarily
3.4.16
Use JSON in favour of XML for Datafeeds
3.5 User
Experience
3.5.1 Design for Multiple Interaction Methods
3.5.2 Use Scripting to Improve Minimize
Perceived Performance Latency
3.5.3 Preserve Focus on Dynamic Page
Updates
3.5.4 Group Closely Coupled Views
3.5.5
Use Fragment IDs for
to Maintain Application Views History
3.5.6
3.5.5
Make Telephone Numbers
Clickable "Click-to-Call" 3.5.7
3.5.6
Ensure Paragraph Text Flows
3.5.7
Ensure Consistency
Of State Between Devices
3.5.8 Separate Rarely Used Functionality Consider Mobile
Specific Technologies for Initiating Web
Applications
3.5.9 Enable Progressive Rendering Use Canvas Tag For Dynamic
Graphics
3.5.10 Ensure Consistency Between Desktop and Mobile
Use viewport Meta Tag
To Identify Desired Screen Size
3.6 Handling Device
Capability Variation
3.6.1 Use Server-side Capability
Detection
3.6.2 Use Client-side Capability Detection for
Dynamic Device State
3.6.3 Use Device Classification to Simplify Content
Adaptation
3.6.4 Support a non-JavaScript Variant if
Possible Appropriate
3.6.5 Offer Users a Choice of Interfaces 3.7 SVG
3.7.1 Use SVG Tiny
1.1 Compatible Content
3.7.2 Minimize Size
and Complexity of Content
3.7.3 Test on
Target Devices
3.7.4 Make Use of
Language Features to Write Compact Code
Appendix: Best Practice
Dependent Device Properties
Appendix: Examples
A Sources (Non-Normative)
B Related Reading (Non-Normative)
C Acknowledgements (Non-Normative)
D References (Non-Normative)
D.1 MWI
References
D.2 Sources
D.3 Device
Independence
D.4 Web, Protocols and
Languages
D.5 Other
References
The following Best Practices are discussed in this document and listed here for convenience.
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-specific
mobile technologies or previous
experience with Mobile Web Best Practices 1.0 (BP1).
The intention is to make clear to all involved what the Best Practices are, and hence establish a common basis of understanding. As a result of wishing to be clear to those not already involved in the development of mobile friendly content, some statements may appear to be obvious or trivial to those with experience in this area.
The document is not targeted solely at developers; others, such
as interaction and graphic designers, site
administrators, and tool developers, developers
are encouraged to read it. Some Best
Practices, however, clearly have a more technical focus. These are
likely to be of interest only to developers interesting in building
highly optimized / advanced mobile Web applications and can be
safely ignored by other disciplines.
These recommendations expand on the recommendations of the
Mobile Web Best Practices
1.0 (BP1). Where the focus of BP1 focussed is primarily
on 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 the application.
The goal of this document is not to invent or endorse future
technologies. However, there are a number of cases where explicitly
omitting a Best Practice that referred to an emerging technology on
the grounds that it 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
we believe 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's not necessary to implement all Best Practices in order to avoid pathological behaviour. 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 either server-side or client-side processing (e.g.
JavaScript) to provide an "application-like" experience within a
Web browser. Web applications are distinct from simple Web content
(the focus of BP1) in that they include some locally
executable elements of interactivity and persistent
state.
Whilst While the focus of this document is on producing to
document Best Practices that apply to applications running in
a Web browser, in many cases these recommendations are equally
applicable to other kinds of Web runtime, run-time,
such as the widget frameworks being considered as part of the
Web
Widgets [REF] effort and also in a
number of vendor-specific initiatives.
In an increasingly mobilized world the line between mobile and
non-mobile is necessarily blurred and a document focussing that restricts its
focus solely on 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,
poor intermittent connectivity), and also the
additional scope and features that must be considered when
developing for the mobile context (e.g. device context / location,
presence of personal data on the device, etc).
Requirements on delivery context have not been made explicitly,
but most best practices assume devices with basic standard XHTML,
JavaScript, and CSS compliance.
capability. Additionally, some
best practices Best Practices are relevant only if the device
exposes certain capabilities (for example, access to device
information such as location).
Implied by this discussion is that some level of device
knowledge and content adaptation is required. For best practices Best
Practices specifically related to this area, see 3.6.1 Use Server-side Capability Detection
for Device Properties and 3.6.2
Use Client-side Capability Detection for Device State .
These recommendations are complimentary complementary to the recommendations of Mobile Web
Best Practices 1.0 (BP1).
This document builds on some of the concepts described by the
Ubiquitous Web Applications Working
Group (UWA) working group and the
Device Independence Principles [DIP] . The
document discusses device and delivery channel characteristics,
which the DIWG UWA has named "Delivery Context" [DCODI] . In addition, the document uses some
terminology from UWA's Glossary of Terms for Device Independence
[DIGLOSS] .
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 term terms "AJAX" is
and XMLHttpRequest (XHR) are used
as it is in practice to refer to any
asynchronous browser request. The implicit reference to XML
suggested by the name names is commonly accepted to be an historical
anomaly.
This section elaborates on
Most applications have the recommendations of BP1 Section 5.5 which details
ways need to minimize store data of
various forms, both intrinsic content (e.g. the amount emails of
user input required. Given an email application, the limitations calendar
events of a mobile device, the
interface should as far as possible minimize user input. To this
end, calendar application) and
supplementary personalization can
improve the user experience by minimizing settings (e.g. preferred theme, default view,
etc).
These Best Practices relate to the
amount of effort required appropriate technologies and techniques to
find relevant information. use for managing a Web application's data.
If a service relies on user entered
information (e.g. application preferences, personal details) the
user should not have to re-enter that information during the normal
course of the application. This is important both within a usage
session and across usage sessions. 3.1.1.2 How to do it A number of
technologies can be used to persist user entered information.
Usually Cookies are a combination of technologies will be required, the choice
of which is application common
and context specific: Server Based Session
Management: Most servers offer the facility effective means to store client small amounts
of state in-memory on the server. By
default they will identify the request based on either a cookie or by URI decoration. JavaScript
Variables: JavaScript object state can be used as a temporary
datastore provided the page is not reloaded. Note, however, that
the JavaScript runtime is not guaranteed to remain in memory if the
application is placed in the background, and so JavaScript state should be used
only client. They are appropriate
for short-lived and volatile data. Hidden
Form Elements: Within a usage session, state can be preserved
between pages by storing extra simple personalization information in hidden form elements, e.g: <input
type="hidden" name="somedata"
value="some_previously_entered_value"/>. Cookies: When
supported data and active, cookies are a common
and effective means commonly used
to store state on the client. Be aware,
a token representing user identity in order
to enable automatic sign-in.
Note, however, that cookie data information
stored in cookies is exchanged
with sent to the server
on for
every request and so using them for excessive
amounts of data can negatively
impact performance.
Also, cookie support cannot be relied upon
and may be disabled either in the device configuration or by the
mobile network. For this reason, applications should endeavour to
remain functional even if cookies are unavailable. See
3.4.14 Reduce Cookie Size for more details.
Also see BP1 [COOKIES] Do not rely
on cookies being available for more
detail. Persistent URL: Where no alternative exists (e.g. cookies
are unsupported) some degree of personalization is still possible
by redirecting the user to a persistent URL (PURL). On first-use,
users should be prompted to bookmark this unique URL and use it to
identify them in future requests. appropriate cookie related caveats.
If supported, supported by the HTML5 Local
Storage API can be used device,
client-side storage APIs provide a mechanism to store
application data on the device. It is
appropriate for more complex and
larger extensive amounts of data
than would be possible appropriate with other
methods. See Offline Webapps for more details. Server Based
Datastore: Extensive personalization data and state
cookies. Some examples of technologies
that is required across usage sessions should
be stored support client-side storage
APIs are BONDI ,HTML5 ,and
Opera Widgets .
Making use of client-side storage in
a server-side datastore whenever possible. A
server based datastore Web
applications is the only way to
facilitate the sharing a powerful
technique that brings Web applications into parity with native
applications in terms of state across
multiple devices. See 3.5.10 Ensure Consistency Between
Desktop start-up time and
Mobile responsiveness. Two key advantages are worth noting
explicitly:
3.1.2 Automatically Identify
3.2 Security and privacy
Use trusted information, and protect all
personally identifiable information. [ Client-Side Storage Icon ] Requires: Local Storage API.
Although HTTPS If a client-side storage API is the most common means being
used, it's important to secure
personally identifiable information, the overhead remember that this data is not visible to other devices.
Whilst this is adequate for some forms of using data (e.g. preferences
and state relevant only to a given device), it can be significant over is
often necessary to replicate this data back to a mobile network. As such, HTTPS should not be used
unnecessarily, server in order to
provide a consistent view across devices and the level of security should be matched
make it possible to recover data if the level of
sensitivity of the information being exchanged. device is lost or damaged. See 3.5.10 Ensure Consistency
Of State Between Devices for
further discussion on this topic.
Personally identifiable information (e.g.
user identity or information usable as As a key to user identity)
should only be accepted or sent securely. Less sensitive
information rule of thumb, data
that cannot needs
to be associated shared with an individual
(e.g. other devices or recovered in the
case of a zip code by itself is not
personally identifiable) does not need lost or damaged device, should be replicated back
to use HTTPS provided the correlating information is secure. server as soon as possible.
HTTPS is the most secure way
The technologies that provide client-side
storage APIs should provide facilities to exchange sensitive information such as user-identity. To
avoid detect the overhead of using HTTPS for all transactions,
current network connectivity. For example,
HTML5 provides a related
pseudo-identity or secure hash of property on the actual
identity can be exchanged in non-secure transactions. HTTPS should
always be used navigator object (
navigator.onLine
) to exchange the
initial user credentials, but subsequent requests need not use
HTTPS provided the user identity is exchanged in indicate whether the form of
a Hashed Identity Token. The working group client is looking for
feedback currently online, and
dispatches two events on the validity
of this Best Practice. Whilst it is Window object to indicate a true reflection change
of techniques commonly in use, it risks
exposing the Hashed credentials in the network proxies state (
online
and might pose an unacceptable security
risk. offline 3.2.2 Secure
JSON Datafeeds 3.2.2.1 What it means ).
A common paradigm in Mobile Web applications is
to provide a datafeed should use these
events to an JavaScript based Web
client in control the form of an executable JavaScript string (e.g. JSON).
This has many advantages in terms of speed of execution and
ease flow of development, but it represents a significant security
flaw which can expose user-data data
back to malicious Web sites. If a JSON
datafeed is executable, a malicious Web site can reference it in a
<script> element. This will execute the datafeed using
the cookies associated with the data
providing site server and
in most cases generate to build up a JavaScript
object model in the client which can be accessed by
local queue of changes if the
malicious site. application is offline.
3.2.2.2 How to do it
[ Client-Side Storage Icon
] Requires: Local Storage
API.
The JavaScript datafeed should be
protected by a prefix that will prevent execution directly, but
which can be stripped off prior to execution when accessed by an
XHR request. Use trusted information,
and protect all personally identifiable information.
3.2.3.1 3.2.1.1 What it means
If a JSON datafeed is being parsed
using the eval(); a very commonly
used method it is vulnerable to
script attacks. For example, if the feed
contains user entered data this transfer data might
replicate to the JSON syntax in order client,
usually as part of an asynchronous request. However, using
eval();
to compromise directly execute the application. incoming
datafeed represents a security risk and should be
avoided.
Inadvertantly executing malicious JavaScript is particularly dangerous on mobile devices where personal information (current location, contact data, etc) may be exposed.
3.2.3.2 3.2.1.2 How to do it
There are a number of steps which can be
used to protect against this kind Instead of attack, use the
one most appropriate to parsing JSON
data by executing it with the context: browser's
eval();
command, use a JSON parser (for
example: http://www.json.org/json_parse.js ).
In cases where directly evaluating the
JSON data is desirable for reasons of efficiency, ensure that
the data comes from a trusted source
(e.g. either contains no
user-generated data). Use a "Safe EVAL"
method which encodes any unsafe characters in content (e.g. the datafeed
before evaluating. The working group server is looking
responsible for feedback on an example "Safe EVAL" algorithm that can be
shared here, all fields in the
datafeed) or a publicly available
library that can be referenced.
any user-generated content is correctly
escaped.
Ensure that the user is aware of otherwise
invisible application behaviors that
might affect the overall application behaviour, actions, and that the user
is offered offer options to
control those behaviors. Many browsers
support the ability to make background server requests without
requiring a server roundtrip. This makes it possible to make server
requests that are not automatically reflected in the user-interface
and which might surprise the user or lead to unexpected data
charges. actions.
A number of standard and proprietary APIs
exist to give browsers Browsers may
have access to both personal and device
information, for example: information
such as:
Use of such personal information and
device functions can expose Many
browsers support the user
ability to privacy and security concerns. The overall goal is
make background server requests (i.e.
requests that do not require action
by the user user). Unless specific action is informed of taken to provide
information about such activities,
given effective means activity, users
may be exposed to control them,
revealing information that they did not
intend to reveal and also the
opportunity may be subject to
opt-out of their use. unexpected data charges.
Whenever an application makes background asynchronous
XHR data requests, whether automatic (on a timer or user-initiated, in response
to an external trigger) or secondary to some user action,
this should be indicated to the user in an appropriate manner.
Applications should disclose, in a clear
and useful way, the basic nature of their disclose how they use of the
network. network resources. A
simple icon indicating background activity is usually sufficient
and will does not interrupt the main
application flow. 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 log-in,
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:
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 must be
provided.
At a minimum, All applications that access the network automatically
must provide a means for the
ability user to switch off the
automatic network disable that
activity. Endeavor to keep the application as
functional as possible if When
automatic network activity is disabled by
prompting disabled, periodically
prompt the user before making
to make network requests.
If appropriate, it might be desirable to
enable Consider allowing the user
to adjust the level of network activity. For
example, by adjusting the polling-schedule, or controlling
polling schedule and to control which
activities are allowed to initiate network requests.
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. Applications
These notices should be defensive and remain as functional as possible if
provided when the API request for user first
accesses the Web application, on first access to user information,
or in help pages. It should provide the user with enough
information is denied. to reasonably 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 deliver causes a
native confirmation dialogue
dialog to the
user before providing access be
presented to the data.
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
dialogues by dialogues.
[ DEVICE DATA icon ] Requires: Device Data APIs.
The Mobile Web Best
Practices Working Group is investigating best practices to make
login as easy as possible on mobile devices with limited input
capabilities. Feedback from the underlying API. community is
welcome! (see the Status of This Document section for details on how to provide
feedback)
Resources, Battery lifetime and cost of network traffic are
significant considerations of most users of mobile devices. Since
all activities that use either processor or wireless connectivity
will incur some cost to battery life or network data costs,
applications should consider this factor and be conservative in
their use of resources.
Additionally, resources, such as device memory, processor power, and network bandwidth are significantly more limited on mobile devices than on the desktop. The most effective way to ensure that applications run smoothly and with low latency is to take steps to ensure minimal use of resources.
Compress content for efficient delivery.
HTTP 1.1 compression, which typically uses the
gzip or deflate as algorithms,
and DEFLATE algorithms is a widely (though not
universally) supported method of compression. In general,
supported. Web servers should be
configured to serve Web pages using HTTP 1.1
compression, according to the coding supported by the device as
indicated by the HTTP Accept-Encoding header. appropriately compressed responses.
Note however, that the processor
cost (in time and battery usage) of
decompressing data should be balanced against the gains in
transport efficiency. As a rule of thumb the
following should be considered when When configuring HTTP 1.1 compression: compression
note that:
This section elaborates on the Best Practices of BP1 ( MINIMIZE ). Smaller applications will download and execute more quickly and more reliably than larger ones on constrained devices.
Process HTML HTML, JavaScript and CSS files at build time to remove whitespace and minify. minify before
delivery. A number of Open Source
freely available whitespace strippers
and JavaScript / CSS optimizers are
available. Process script files at build time
to remove available online.
Note that "minification" / "optimization"
can take a number of forms from simple removal of whitespace
and minify comments, to the script.
Several Open Source javascript compilers are available.
global substitution of tokens (variables,
method names, selector names) with shorter alternatives, to
alternative binary and compressed representations of the underlying
data.
The working group is seeking
recommendations for In general,
minification that parses the best
source file and makes substitutions based on
a lexical / most-commonly used
tools grammatical understanding of that
source are less fragile and should be preferred to
reference in this section. simple regular-expression based tools.
For a good comparison of JavaScript minification tools try: http://compressorrater.thruhere.net
Request redirection (through HTTP response header or meta
refresh) is typically used to exchange information between servers
(e.g. account authentication). Whilst
invaluable, the cost of The delay
incurred by redirects is much higher over limited bandwidth mobile networks and so the number of redirects
should be kept to a minimum to avoid degrading the user
experience.
A typical redirect sequence should require
no Try not to use redirects. If
more than two automated redirects, e.g. one
to redirect to the information-providing server, and another to
redirect back to the service-providing server. If further
redirects are required, required use a landing
an interstitial page to communicate to
the user that the application is still working.
Applications that automatically
issue Network operations are costly in
terms of battery usage, application latency, and potential
network requests traffic expenses, and should provide "value" for those requests so as not
to unnecessarily impact battery-life and
application performance. Take care to ensure be made unnecessarily. The latency cost of setting up a
HTTP request is much higher than the bandwidth limitations on a
mobile network and so fewer,
larger requests are as well optimized
as possible. preferred.
Consider the following possibilities when designing an application:
3.4.6.1 3.4.5.1 What it means
A Web application typically requires a number of resources
(stylesheets, (style sheets, scripts, image, etc) each of which
may incur an additional HTTP Request. HTTP roundtrips round trips
are particularly expensive on a mobile network and so fewer, larger
requests should be favoured over a larger number of smaller
requests.
3.4.6.2 3.4.5.2 How to do it
As far as makes sense after taking into account 3.5.8 Separate Rarely Used Functionality 3.5.2 Minimize Perceived Latency combine all
stylesheets style
sheets into a single resource and all scripts into a single
resource. If multiple scripts and stylesheets style
sheets are required as part of the authoring process, then
try to arrange that they are merged before the page is served.
3.4.8.1 3.4.6.1 What it means
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 roundtrip
round-trip which is detrimental to
performance. To avoid this, all static images
should be sprited together performance
when compared with combining them into a single image. image for
transfer.
3.4.8.2 3.4.6.2 How to do it
Using manual or automatic means, combine
all icons into a single image. To optimize the efficiency of this: efficiency:
To render individual icons from
components of a sprited resource using
css use CSS positioning and
clipping.
[ ICON: CSS ] Requires: CSS2 Clipping and Positioning Support
3.4.9.1 3.4.7.1 What it means
Background images are often used as gradients to improve the
look and feel of an application. These can be inlined included in
the CSS as base64 encoded strings in order to avoid an additional
HTTP roundtrip. round trip.
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 less requests.
3.4.9.2 3.4.7.2 How to do it
Background images can be embedded
encoded using the data URI scheme:
url('data:image/png;base64, [data])
[ ICON: CSS ] Requires: RCF2397 data uri support.
3.4.10.1. 3.4.8.1. What it means
Dynamic resources that change occasionally (e.g. a user's
avatar) can still be cached by identifying them with a URL URI that includes
a fingerprint of the resource content. Using this technique means
that the browser doesn't 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.
3.4.10.2 3.4.8.2 How to do it
Expires
header to a date in the far future.3.4.11.1 3.4.9.1 What it means
Datafeeds Data designed to be accessed by AJAX requests from
the client should be cached in the same way as the primary content.
3.4.11.2 3.4.9.2 How to do it
The standard caching techniques ( Expires
header
and Cache-Control
header), as well as resource
fingerprinting can be used on AJAX datafeeds data as
readily as primary content pages.
3.4.15.1 3.4.10.1 What it means
Static resources don't need cookie information and so
performance can be improved by serving these from a path or
subdomain sub-domain for which the application application's cookies are out of scope.
3.4.15.2 3.4.10.2 How to do it
Use a different domain, subdomain,
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.
For example:
3.4.16.1 What it means Set-Cookie: somePreferenceInformation=purple;
path=/myapp/
Asynchronous Application data can be
delivered to the client in response to an XHR request in any form
(HTML markup, proprietary format, XML, or JSON object model). Use
JSON in favour of XML if possible. It is more compact. It is
quicker to parse since it can be directly parsed using the
served from eval /myapp
method. 3.4.16.2 How to do it
will receive cookie information.
A JSON datafeed can be built
Static data served from an object model by hand, or an Open Source JSON builder
( REF ). On the client, JSON is readily parsed into a javascript
object model using the eval /static
method. Note, however, that care should be
taken to observe: 3.2.2 Secure JSON Datafeeds and 3.2.3 Use a Safe
EVAL for JSON Datafeeds . will not
receive unneeded cookie information.
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: perceived latency, interaction method, and data consistency.
3.5.1.1 What it means
Interaction methods vary across different devices. Three main interaction methods
should be considered: considered when designing the UI:
Devices may implement one or more
The optimum configuration of
these approaches and it 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 important for an
application not possible, then the UI
should be carefully designed in order to remain usable provide a good
experience in all cases.
each of these different interaction
methods.
3.5.1.2 How to do it
Particularly where navigation of
content requires multiple links (ie back/forward in a carousel) or where the
user's interaction with links is designed to give them
feedback, the following factors should be considered:
Focus Based:
Pointer Based:
Touch Based:
Using script for dynamic parts
The Best Practices covered in section
3.4 Conservative
use of resources will help to minimize the page means that the view can be updated without
actual latency of a full page reload. Since reloading the entire page
Web application, but a number of
measures can also be slow this can greatly improve application
usability. used to further minimize
the perceived
latency. Lowering perceived latency is an
important factor in improving the overall usability of a Web
application, improving user's perception of Web site credibility
and decreasing bail-out rates [REFS] .
Use asynchronous (XHR) requests
A number of techniques can be used to
get additional improve perceived and actual latency:
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.
Use the JavaScript focus
method only if it is
essential to the use of the application, and does not inhibit user
control/interaction.
3.5.5.1 3.5.4.1 What it means
Web applications can show multiple
switch between 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 automatically possible
to link directly to these specific views and the
browser <back> button cannot be used to move between previous
views. within an application.
Usability is enhanced by enabling both of these features:
3.5.5.2 3.5.4.2 How to do it
Each view within an application should be
identified have a URI with a
fragmentID distinguishing fragment identifier (e.g.
http://myapp.example.org/myapp#view
) and JavaScript
used to interrogate the browser location in order to determine
which view to display.
For further discussion on this topic see: http://ajaxpatterns.org/Unique_URLs
Standardized URI schemes have been defined for some common
device functions, e.g. making phone calls and managing phone address books. These URI schemes, if
supported, can enable users to easily use these functions from Web
applications.
The most broadly supported scheme is tel: as described in [
RFC3966 ]. Use
this Code such as follows to make phone numbers easily diallable
from the Web application:
following can be used to enable
"Click-to-Call":
<a
href="tel:[PHONE-NUMBER]">[PHONE-NUMBER]</a>
3.5.7.1 3.5.6.1 What it means
On small screens it's it is important that paragraph text flows
to fill all the available space. Fixed
paragraph widths (even when optimized for the device screen) are
error prone, make it harder to support multiple device formats, and
will not support multiple orientations (e.g. landscape and portrait
mode). 3.5.7.2 How to do it Specify widths for elements containing
paragraph text as a percentage ( style="width:100%" ) in favour of
using an absolute size ( style="width:660px" ). 3.5.8 Separate
Rarely Used Functionality 3.5.8.1 What it means Perceived
performance can be improved by separating out JavaScript and CSS
styles that are not required by the initial page. JavaScript and
CSS styles associated with rarely used features should be bundled
separately and downloaded only if those features are accessed.
3.5.8.2 How to do it Consider what functionality is being
downloaded in a given script resource and how likely
so that functionality is to be used in the majority of requests.
If some functionality is rarely used, it may make sense to partition this into a separate script
to be loaded on demand. On demand loading can be accomplished by:
Moving that functionality onto an entirely separate page. Creating
an embedded frame to load the required additional resources in
response to a page event. Using <link rel="prefetch"> The
working group is seeking feedback on this Best Practice. Whilst it
contains value for very large / complex applications, the
implementation of this technique and its support across even
high-end devices is not clear. Specifically, IFRAMEs are known to
have significant issues on many devices doesn't require horizontal scrolling and so
we are looking for validation that
their use in this context is a good idea.
3.5.9 Enable Progressive Rendering 3.5.9.1 What it
means Progressive rendering means that the
page will be displayed incrementally as
it loads. In most cases this results in an improved perceived
latency since content reflow if the
view orientation is available
earlier. changed. See BP1 [MEASURES] for more
details.
3.5.9.2 3.5.6.2 How to do it
Place CSS stylesheet ( <style> )
elements in the <head> stanza at the top of the document and
JavaScript ( <script> ) elements at the bottom of the
document. Browsers will not progressively render a page until the
stylesheet has been loaded Use
percentage and will block while
JavaScript content is parsed. measures
for containers so that text can reflow automatically.
3.5.10.1 3.5.7.1 What it means
This recommendation builds on the recommendation in BP1 (
5.5.1 Thematic
Consistency ) and expands it to consider the application
preferences and ,
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 devices should be viewable consistently on other devices.
The most valuable example of this would be in offering a consistent experience where information entered during a desktop session is accessible in a mobile session and vice-versa.
3.5.10.2 3.5.7.2 How to do it
For application data to be shared between
devices it must be stored on a server and cannot be stored locally
on a device (e.g. using cookies or a local datastore). For
any application data that is not exclusively relevant to the
current device, favour favor storing it on the server so it can be shared
by other devices. See 3.1 Application
Data for more details.
Network-initiated content delivery ("push") methods allow notifications and updates to be pushed to user even when they are outside of the application context.
Push method support may be disclosed through a User Agent Profile document if published by the device vendor, or through other device classification repositories.
If supported by the user agent, options for Push methods include:
The Mobile Web Best Practices Working Group is investigating best practices around the use of canvas and welcomes feedback from the community (see the Status of This Document section for details on how to provide feedback).
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.
A typical viewport setting looks like this:
<meta name="viewport" content="width=320; initial-scale=1.0; maximum-scale=1.0; user-scalable=0" /> ,
and should be inserted into the <head> of the HTML document. This setting informs the browser to always render the page at 100% (e.g. no browser based scaling) and explicitly disallows scaling of the page. Explicitly disallowing scaling is required to prevent the page being scaled when an input box is clicked on.
The setting above is appropriate for pages specifically designed for the target screen-size.
Device capability variation is a basic characteristic of the
mobile Web environment. Web applications should adapt their content
such that they render in an optimum way
as well as possible on as broad a range
of target devices as possible.
For static device capabilities that won't change (e.g. SVG
support, screen-dimensions) it is preferrable preferable
to detect these capabilities on the server and adapt content before
it is sent to the client in order to avoid transferring unnecessary
data.
Typically used methods of device capabilities detection:
For dynamic device state that might depend on the configuration or context of the device (e.g. Is scripting enabled? Is the SDCard available? Has permission been granted for PIM access?) detection must be done on the device.
Use JavaScript reflection to determine if a given API is active and interrogate the device configuration using appropriate APIs. Two methods can then be used to adapt on the client to differing configurations:
if
(some_configuration_variable)
decision-points in the code
and behave Option (1) is simpler to implement and is appropriate provided the amount of inactive code downloaded doesn't have a negative impact on performance. Option (2) is preferred when the application must change significantly in response to properties that can only be determined on the client.
If a large number of devices are being targetted, 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 into different
"buckets" device
classes and build a single application variant for
each device bucket. each.
This will keep the amount of device-specific code to a minimum without unduly encouraging a "lowest common denominator" solution.
Identify the target devices for the application and assign these
to "buckets" device classes of varying capability. Focus on
application variants that work in each bucket class rather
than building device-specific exceptions for every variation in
device configuration.
Device buckets classes should be defined on an
application-specific basis, so that the variants can be tailored
accordingly. For example, the following is a typical possible
configuration of application buckets:
classes:
Bucket Class 1: Basic XHTML support, no or very
basic scripting. No AJAX 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).
Bucket Class 2: Full AJAX and JavaScript
support.
Bucket Class 3: Advanced device APIs, for
example: access to location API, device PIM data, or application
cache.
Scripted and XHR based applications are not yet well supported on many all browsers. If
possible, provide broadest reach is a primary concern then consider
providing a variant of the application that does not rely on script by using uses synchronous FORM posts instead. in place of XHR
requests. This Best Pratice is related (albeit with a differing
focus) to BP 1 [ OBJECTS_OR_SCRIPT] .
Essentially this BP states that it is favourable to support
"Bucket "Class 1" devices as defined above if at all possible. 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
sometimes be useful for simple
operations in low-bandwidth situations.
In some cases, however, the type of
a particular application simply has no
non-JavaScript counterpart (e.g. a Web based game, an IM Instant Messaging
client) in which case it should return a 406 Not
Acceptable
response.
Do this by detecting the device User-Agent and checking its JavaScript support against a DDR or local index.
Not only is device characteristics
characteristic detection imperfect, it
cannot always account for the differing use-cases of an
application. If multiple flavours of the application exist (e.g. to
support the various device buckets)
classifications) it might make sometimes
makes sense to offer the user the choice of which flavour
they wish to use.
Only if it makes sense in the specific context of a given application, allow the user to switch to a different flavour (for example, upgrading their experience if their device is more capable than the server believes, or degrading if connectivity is poor and they wish to accomplish a very simple task that can be done more easily with the minimal UI).
Always attempt to default to the most appropriate UI on first use.
Always remember the user's preference for future visits in a
cookie or local datastore. 3.7 SVG Note: This
section is still under review. The working group is keen to receive
further suggestions for best practices specifically related to the
use of SVG on mobile Web sites. This section covers some specfic
Best Practices related to the use of SVG in mobile Web
applications. SVG is a vector graphics format designed for use in
the Web. It is useful when there is a need to convey large amounts
of information. 3.7.1 Use SVG Tiny 1.1 Compatible Content SVG Tiny
1.1 is the most broadly supported. 3.7.2 Minimize Size and
Complexity of Content Take steps to ensure that the SVG content is
not overly complex since constrained devices will have difficulty
rendering it. Ensure that the browser is configured to enable GZip
compression as per 3.4.1 Use Transfer Compression . 3.7.3 Test on
Target Devices Even if SVG Tiny 1.1 is supported on target devices,
it is necessary to test on-device since some implementations are
not entirely compliant. 3.7.4 Make Use of Language Features to
Write Compact Code Certain features (e.g. defs and use elements)
enable geometric shapes to be re-used. Appropriate use of these
elements is encouraged in order to create compact code.
data store.
The following device properties
included in the DDR Core Vocabulary [REF] are
of particular value in supporting specific best practices.] practices
recommended in this document. They should be available in any DDR
supporting the W3C's DDR Core Vocabulary:
TODO: Include more detailed examples on the following BPs... Use Fragment IDs
The Best Practice statements have been assembled by the BPWG from a number of sources. Primary among those are:
While the Best Practice statements have mainly been assembled by secondary research, the sources for that research have in many cases been assembled from primary research. In addition, group members' contributions are to some extent informed by primary research carried out by their company.
Readers interested in the topic of this document will find a variety of other publications of interest. As noted in the Scope paragraph above, topics such as internationalization and accessibility have been addressed separately by the W3C and have not been covered here.
The Character Model for the World Wide Web and other materials prepared by the W3C Internationalization (i18n) Activity cover important interoperability drivers for content prepared for the One Web and the mobile-services arena.
The Web Accessibility Initiative has prepared a variety of Guidelines and Techniques that likewise bear on the preparation and processing of content in and for the Web.
Section 3.6.3 Use Device Classification to Simplify Content Adaptation above introduced the idea of content adaptation. Readers who contemplate implementing server-side adaptation will be interested in the ongoing work of the Device Independence Activity .
to be added
to be added