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 .
The following Best Practices are discussed in this document and
listed here for convenience.
TODO
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).
1.3.4 Delivery Context
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] .
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 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.
- The Heading
- A summary of the functional area to be addressed by these
statements
The Statements One or more Best Practice
statements identified in the following way: [EXAMPLE] This Is A
Best Practice Statement What it means- An explanation of the intention of the Best Practice
statement.
- How to do it
- A discussion of the techniques and device capabilities required
to implement this Best Practice.
- Requires
- A summary of device capabilities required
in order for this Best Practice to apply.
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:
A Service Provider (e.g. Mobile Network
Operators or Web Portal Providers) or an Identity Management
Provider may provide means to access trusted user identities
automatically. This has the advantage Each technology offers a variety of
removing the need storage
facilities that range from simple "key = value" models
appropriate for
the user to enter their
identity at all and will provide an optimal experience.
Alternatively, the simplest way to identify the user is
relatively simple, unstructured data,
to
prompt full
SQL Database APIs appropriate for
login
credentials on first access more
extensive and
store structured content. For a
Hashed identity token good
technical discussion of these facilities in
a cookie for future accesses. Recommended methods for
doing this include: HTTP Digest Authentication. HTTP Basic
Authentication (in which case it must be over a secure HTTPS
connection, the context of HTML5
see
3.2.1 Protect Personal Information Used
in Transactions ). Offline Web form (delivered
over a secure HTTPS connection). Applications .
3.2 Security and privacy
Use trusted information, and protect all
personally identifiable information. [ Client-Side Storage Icon ] Requires: Local Storage API.
3.2.1 Use HTTPS when Exchanging User
Credentials 3.1.3 Replicate Local
Data To A Server If
Necessary
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.
Insecure JSON feed: { username: "My Name",
contacts: [ {name: "Contact1", phonenumber: "xx-xxx-xxxx"}, {name:
"Contact2", phonenumber: "xx-xxx-xxxx"}] } Secure JSON feed: {
username: "My Name", contacts: [ {name: "Contact1", phonenumber:
"xx-xxx-xxxx"}, {name: "Contact2", phonenumber: "xx-xxx-xxxx"}]
}
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 ).
Ensure
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:
File system access to pictures,
Pictures, music, and video clips clips;PIM data (contacts, calendar)
Contacts, calendar (PIM data);- Call
handling history;
- System data (battery, coverage, roaming,
location) location);
- Media recording (record audio/video clip, get new
picture) picture);
- Device context (e.g. location, connectivity, profile
setting) setting).
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:
- how often the application will interact with the
internet. E.g. Internet -
e.g. every 5 minutes, hourly, daily. daily;
- how long the automatic
behaviour
behavior will continue. continue;
- how heavy the overall usage is expected to be or the type of
service plan recommended.
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:
- Most
binary data images (especially JPEGs) will do not benefit
from gzip compression. compression;
- For very small files (e.g. <1k) the negative impact of
processing
may will outweigh any small transport gains.
3.4.1.3 Maximizing Compression Efficiency
Gzipping of HTML and CSS files can be made more efficient by
ensuring consistency in the code. For example: Ensure consistent
ordering of attributes in elements (e.g. alphabetize them). Use
consistent casing (e.g. all lowercase) Use consistent quoting (e.g.
always use single-quotes)
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:
- Batching requests:
- A single request for more data is considerably more efficient
than several smaller requests. Wherever possible, batch up multiple
requests at the application level.
Backoff Back off during periods of
inactivity:- If the application polls for updates, it should monitor
user-activity 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.
3.4.5 Use Push Methods to Reduce Pull
Traffic 3.4.5.1 What it means Network-initiated content delivery
("push") methods can significantly reduce network traffic overhead,
as compared to conventional polling (scheduled "pull") methods.
3.4.5.2 How to do it Push method support may be disclosed through a
User Agent Profile document if published by the device vendor, or
through other device classification repositories. If supported by
the user agent, options for Push methods include: OMA Push: a
widely supported enabler providing methods for user-confirmed and
automatic content push, directed to mobile browsers and other
user-agents. [ REF ] Alternative vendor-specific initiatives.
3.4.6 3.4.5 Minimize External Resources
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.7 Consider Inlining Small Stylesheets and
Script Resources 3.4.7.1 What it means In some circumstances
performance is improved if the JavaScript and CSS stylesheet
resources are inlined in the HTML page, since it eliminates the
need for two additional HTTP requests required to fetch the
external files. 3.4.7.2 How to do it Investigate for a given
application the optimum configuration. Whether inlined resources
make sense or not depends on a number of factors. For example: The
cache hit rate (e.g. the number of times an average user will
successfully load script resources from the browser cache). The
size of the JavaScript and CSS files. The frequency with which the
JavaScript and CSS files change.
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:
- For PNG and GIF files,
sprite
combine images with similar sizes and
colour palettes. color palettes;
In general, avoid spites for JPEGs, but
if you do use them, Endeavour to
sprite JPEGs on 8x8 boundaries. boundaries in
order to minimize the size of the combined JPEG.Sprite Combine images that don't do not change
often -- e.g. if a single image in a sprite
changes often. If one of the
whole sprite component images changes, the entire combination
image will need to be downloaded.
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
- Set the resource caching policy to
never
expire "never expire" by setting
the Expires header to a date in the far future.
- Reference the resource using a
URL
URI that contains a Hash of the
content. If the content changes, this reference will change and the
browser will fetch the updated data.
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.12 Use Power-Efficient Methods
3.4.12.1 What it means A Web application is not guaranteed to be
suspended if it is placed in the background and may continue
running for a long period. In this case, the impact of prolonged
JavaScript operations on battery-life should be considered.
3.4.12.2 How to do it Network activity is the biggest drain on
battery power. If the application requires ongoing network activity
(e.g. to poll a server for updates) take steps to inform the user
of this activity and minimize its impact on battery-life. See 3.3.1
Inform the User About Automatic Network Access Excessive DOM
manipulation over an extended period of time can also impact device
battery life. The working group is currently investigating the
relative impacts of Web application activities on battery life in
order to make more concrete recommendations. 3.4.13 Minimize DOM
Manipulation 3.4.13.1 What it means On small devices with limited
processing capability, the cost of excessive DOM manipulation can
impact application performance. 3.4.13.2 How to do it Only use DOM
manipulation for dynamic parts of the page. The static framework of
the page is best created using HTML markup which can then be
connected to the script using the element ID attribute. 3.4.14
Reduce Cookie Size 3.4.14.1 What it means Information stored in
cookies is exchanged between the server and the client for every
request, which can negatively impact performance. 3.4.14.2 How to
do it Use cookies sparingly, and consider alternative methods (see
3.1 Personalization ) for anything other than trivial amounts of
data. 3.4.15 3.4.10 Don't
Send Cookie Information Unnecessarily
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.
3.4.16 Use JSON in favour of XML for
Datafeeds
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:
- Focus Based: The browser focus "jumps" from link to
link. link;
- Pointer Based: Key-based navigation controls a pointer that can
cover any part of the
screen.
screen;
- Touch Based: Events are related directly to a touch position on
the screen with finger or stylus.
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:
- Selectable elements (e.g. links)
can be widely spaced
as since the user can select
them easily by jumping focus area will
jump automatically from link to link. link;
- The current
location focus of the user can
be page is easily determined
as link elements because that element will be in focus. highlighted.
Pointer Based:
- Selectable elements that are associated need to be near each
other as scrolling the pointer can be
slow. slow;
The current location of the user can be
easily determined as link Selectable elements will need to be large enough
to be easily selected -- since the
pointer often moves in focus.
steps of approximately 5 - 10
pixels;- Selectable elements should have rollovers
to make it clear when the pointer has entered their active
area.
Touch Based:
- Selectable elements can be widely spaced as the user can select
them
easily. directly;
- Selectable elements must be large enough
to be easily selected (e.g. list items should have a height of at
least 30px).
- No elements are in focus until they are selected so extra
information cannot be passed to the user (e.g. rollovers will not
work).
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 .
Use asynchronous (XHR) requests
A number of techniques can be used to
get additional improve perceived and actual latency:
- Enable Incremental
Rendering :Place JavaScript
tags at the bottom of the page (since many browsers halt whilst
parsing JavaScript) and configure the page such that any
useful information
from
that might be available is viewable
while the server in response
main content of the application is still
loading.
- Keep the User Informed of
Activity: Spinners and
progress bars should be used to keep
the user
events informed during network and update device API accesses
so that they don't think the application is "stuck".
- Avoid Page
Reloads: In dynamic Web
applications page
DOM to convey
this reloads should be avoided and the
page dynamically updated to reflects
changes in state. Different views can be switched by showing and
hiding the user. relevant parts of the DOM.
- Partition Large
Scripts: In complex Web
applications, JavaScript parsing can contribute a significant
portion of start-up time. If some functionality is rarely used it
should be partitioned into separate scripts that can be loaded on
demand, lowering the amount of core code that needs to be parsed at
start-up.
- Use Client-Side
Storage: Where appropriate,
aggressively cache a snapshot of application state so it can be
displayed immediately on start-up. In many cases possibly stale
data is still more useful no data.
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.4 Group Closely Coupled Views 3.5.4.1
What it means Most applications consist of a number of views (e.g.
an email application consists of an inbox and the message detail
view). User experience is improved if switching between these views
does not require a server roundtrip. 3.5.4.2 How to do it Each view
can be rendered in a DIV element which is hidden using css.
Client-side script can be used to reveal content in response to
user events without the need for a server roundtrip. 3.5.5
3.5.4 Use Fragment IDs for to Maintain
Application Views History
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:
- Enabling deep links (e.g. to the content of a specific email)
means the user can still bookmark this view and return to it
quickly. quickly;
- Enabling the browser history provides a natural method to
navigate application views that is natively supported by the
browser.
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:
- OMA Push: a widely supported enabler
providing methods for user-confirmed and automatic content push,
directed to mobile browsers and other user-agents. See
http://www.openmobilealliance.org/Technical/wapindex.aspx
for more details.
- SMS
- QR Codes
- Alternative vendor-specific
initiatives.
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:
- The
"user-agent" "User-Agent" header can be used to identify the
device, and a Device Description Repository (DDR) can be used to
retrieve a detailed description of capabilities. capabilities;
- The
"accept" "Accept" header can be used to indicate specific
MIME types compatible-to/preferred-by the device. device;
- The
"x-wap-profile" "X-Wap-Profile" header (User Agent Profile or
UAProf) can be used both as device identification and as a source
for of
detailed device capabilities info.
capabilities.
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:
- Encapsulate the different behaviours in the control logic of
the application. E.g. simply use:
if
(some_configuration_variable) decision-points in the code
and behave accordingly. accordingly;
- Use an initial "bootstrap" script to assess device capabilities
and request the appropriate application bundle accordingly.
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.
[To include the set of minimum
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:
- Display Width, Display Height, Display
Color Depth
- Input Devices
- Markup Support
- Stylesheet Support
- Image Format Support
- Input Mode Support
- Cookie Support
- Script Support
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
- DIP
- Device Independence Principles, R. Gimson, Editor, W3C Working
Group Note, 1 September 2003 (See http://www.w3.org/TR/2003/NOTE-di-princ-20030901/
)
- DCODI
- Delivery Context Overview for Device Independence, , R. Gimson,
R. Lewis, S. Sathish, Editors, W3C Working Group Note, 20 March
2006 (See http://www.w3.org/TR/di-dco/
)
- DIGLOSS
- Glossary of Terms for Device Independence, R. Lewis, Editor,
W3C Working Draft (work in progress), 18 January 2005 (See http://www.w3.org/TR/2005/WD-di-gloss-20050118/
)
- XML
- 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 http://www.w3.org/TR/2008/REC-xml-20081126/ )
- XHTML-Basic
- XHTML Basic 1.1, Shane McCarron, Masayasu Ishikawa, Editors,
W3C Recommendation, 29 July 2008 (See http://www.w3.org/TR/2008/REC-xhtml-basic-20080729/
)
- CSS
- Cascading Style Sheets (CSS1) Level 1 Specification, Håkon Wium
Lie, Bert Bos, Editors, W3C Recommendation, 11 January 1999,
revised 11 April 2008 (See http://www.w3.org/TR/2008/REC-CSS1-20080411/ )
- CSS2
- 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 http://www.w3.org/TR/2008/REC-CSS2-20080411/)
- HTTP1.0
- Hypertext Transfer Protocol -- HTTP/1.0 Request for Comments: 1945,
T. Berners-Lee, R. Fielding, H. Frystyk, May 1996 (See http://www.w3.org/Protocols/rfc1945/rfc1945)
- HTTP1.1
- Hypertext Transfer Protocol -- HTTP/1.1 Request for Comments: 2616,
R. Fielding, J. Gettys, J. Mogul, H. Frystyk, L. Masinter, P. Leach, T.
Berners-Lee, June 1999 (See http://www.w3.org/Protocols/rfc2616/rfc2616.html)
- UAPROF
- Open Mobile Alliance OMA-TS-UAProf-V2_0-20060206-A User Agent Profile
Approved Version 2.0 06 Feb 2006 (See http://www.openmobilealliance.org/technical/release_program/docs/UAProf/V2_0-20060206-A/OMA-TS-UAProf-V2_0-20060206-A.pdf)
- WTAI
- WAP Forum wap-268-wtai-20010908-a Wireless Telephony Application
Interface Specification (See http://www.openmobilealliance.org/tech/affiliates/LicenseAgreement.asp?DocName=/wap/wap-268-wtai-20010908-a.pdf)
- RFC 3966
- The tel URI for Telephone Numbers, H. Schulzrinne. IETF, December
2004 (See http://www.ietf.org/rfc/rfc3966.txt)
- RFC 2119
- Key words for use in RFCs to Indicate Requirement Levels, S. Bradner.
IETF, March 1997 (See http://www.ietf.org/rfc/rfc2119.txt)