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 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 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 an editors' copy that has no official
standing. 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:
This document was developed by the Mobile Web Best Practices Working Group as part of the Mobile Web Initiative. Most of the best
practices statements were changed since the publication of the First Public Working Draft on
29 July 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 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 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, and tool 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 (BP1)
. Where the focus of BP1 is primarily the extension of
Web browsing to mobile devices, this document considers the development of Web
applications on mobile devices.
The approach in writing this document has been to collate and present the most relevant
engineering practices prevalent in the development community today and identify those that:
a) facilitate the exploitation of device capabilities to enable a better user experience; or
b) are considered harmful and can have non-obvious detrimental effects on the overall
quality of 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 the Working Group believes that they will soon become
fully qualified Best Practices (e.g. in prevalent use within the development community).
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 elements of interactivity and persistent state.
While the focus of this document is 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 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 that restricts its focus solely to best practices that are
uniquely mobile would most likely be very short. With this in mind, the focus of
this document is to address those aspects of Web application development for which there are
additional, non-trivial concerns associated with the mobile context. This applies equally
both to the limitations of the mobile context (e.g. small screen, poor 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 XHTML, JavaScript, and CSS compliance. Additionally, some 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 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 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) and the Device Independence Principles [DIP]. The document discusses device and delivery channel characteristics, which the
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 terms "AJAX" and XMLHttpRequest (XHR) are used to refer to any asynchronous
browser request. The implicit reference to XML suggested by the 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.
This section elaborates on the recommendations of BP1 Section 5.5
which details ways to minimize the amount of user input required.
Given the typical input limitations of a mobile device, input of data can require special
effort by the user. Reuse of relevant information about the user can eliminate unnecessary
user interaction and hence improve the user experience.
If an application requires information entered by a user (e.g. application preferences,
personal details) that information should not normally have to be reentered either in the
course of using the application or between invocations of the application.
A number of technologies can be used to persist user entered information. Consider using a
combination of techniques:
- Server Based Session Management:
- Session management is a feature of many server frameworks (e.g. ). Requests belonging to the same session are
typically identified using cookies or URI decoration.
- JavaScript Variables:
- JavaScript object state can be used as a temporary data store provided the page is not
reloaded. Note, however, that the JavaScript run-time is not guaranteed to remain in
memory if the application is placed in the background, and so JavaScript state should be
used only for short-lived and volatile data.
- Hidden Form Elements:
- Within a session, state can be preserved between pages by storing information in hidden
form elements, e.g:
<input type="hidden" name="some_data"
value="some_previously_entered_value"/>.
- Cookies:
- When supported and active, cookies are a common and effective means to store state on
the client. Be aware, however, that cookie data is exchanged with the server on every
request and can impact performance. See 3.4.14 Reduce
Cookie Size for more details. Also see BP1 [COOKIES] Do not rely on cookies
being available for more detail.
- Unique URI:
- Each user can be allocated a specific URI. On first use of the application, users should
be prompted to bookmark this unique URI and to use it when subsequently invoking the
application.
- HTML5 Local Storage API:
- If supported, the HTML5 Local Storage API can be used to store application data on the
device. It can be used for more extensive and structured data than Cookies and URIs. See
Offline Web
Applications for more details.
- Server Based Data Store:
- Extensive personalization data and state that is required across sessions should be
stored in a server-side data store. A server based data store is the only way to
facilitate the sharing of state across multiple devices. See 3.5.10 Ensure Consistency Between
Desktop and Mobile for more details.
Ensure that personalization information is available to the user with minimal effort by
using their identity to automatically restore application preferences.
Service Providers (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 of removing the need for the user to enter their identity at all and will
provide an optimal experience.
Alternatively, the simplest way to identify the user is to prompt for login credentials on
first access and store a Hashed identity token in a cookie for future accesses. Recommended
methods for doing this include:
Use trusted information, and protect all personally identifiable information.
Although HTTPS is the most common means to secure personally identifiable information, the
overhead of using it can be significant over a mobile network. As such, HTTPS should not be
used unnecessarily, and the level of security should be matched to the level of sensitivity
of the information being exchanged.
Personally identifiable information (e.g. user identity or information usable as a key to
user identity) should only be accepted or sent securely. Less sensitive information that
cannot be associated with an individual (e.g. a ZIP code by itself is not personally
identifiable) does not need to use HTTPS provided the correlating information is secure.
HTTPS is the most secure way to exchange sensitive information such as user-identity. To
avoid the overhead of using HTTPS for all transactions, a related pseudo-identity or secure
hash of the actual identity can be exchanged in non-secure transactions.
HTTPS should always be used to exchange the initial user credentials, but subsequent
requests need not use HTTPS provided the user identity is exchanged in the form of a Hashed
Identity Token.
The working group is looking for feedback on the validity of this Best
Practice. Whilst it is a true reflection of techniques commonly in use, it risks exposing
the Hashed credentials in the network proxies and might pose an unacceptable security
risk.
3.2.2.1 What it means
A common paradigm in Web applications is to provide a data feed to an JavaScript based Web
client in the form of an executable JavaScript string (e.g. JSON). This has many advantages in terms
of speed of execution and ease of development, but it represents a significant security flaw
which can expose user data to malicious Web sites.
If a JSON data feed is executable, a malicious Web site can reference it in a
<script> element. This will execute the data feed using the cookies
associated with the data providing site and in most cases generate a JavaScript object model
in the client which can be accessed by the malicious site.
3.2.2.2 How to do it
The JavaScript data feed 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.
{ username: "My Name",
contacts: [
{name: "Contact1", phonenumber: "xx-xxx-xxxx"},
{name: "Contact2", phonenumber: "xx-xxx-xxxx"}] }
while(1); { username: "My Name",
contacts: [
{name: "Contact1", phonenumber: "xx-xxx-xxxx"},
{name: "Contact2", phonenumber: "xx-xxx-xxxx"}] }
3.2.3.1 What it means
If a JSON data feed is being parsed using the eval(); method it is vulnerable
to script attacks. For example, if the feed contains user entered data this data might
replicate the JSON syntax in order to compromise the application.
3.2.3.2 How to do it
There are a number of steps which can be used to protect against this kind of attack, use
the one most appropriate to the context:
- Ensure that the data comes from a trusted source (e.g. contains no user-generated data).
- Use a "Safe eval" method which encodes any unsafe characters in the data feed before
evaluating.
The working group is looking for feedback on an example "Safe eval"
algorithm that can be shared here, or a publicly available library that can be
referenced.
Ensure that the user is aware of otherwise invisible application actions, and offer options
to control those actions.
Browsers may have access to information such as:
- Pictures, music, and video clips;
- Contacts, calendar (PIM data);
- Call history;
- System data (battery, coverage, roaming, location);
- Media recording (record audio/video clip, get new picture);
- Device context (e.g. location, connectivity, profile setting).
Many browsers support the ability to make background server requests (i.e. requests that do
not require action by the user). Unless specific action is taken to provide information
about such activity, users may be exposed to revealing information that they did not intend
to reveal and may be subject to unexpected data charges.
Whenever an application makes background data requests, whether automatic or user-initiated
, this should be indicated to the user in an appropriate manner.
Applications should disclose how they use network resources. A simple icon indicating
background activity is usually sufficient and does not interrupt the flow of the
application. If extensive background network activity is required the user should be
informed when they first visit the site, when they first log-in, or in associated help
pages.
The kinds of detailed information that could be disclosed in associated help pages or terms
of service are:
- how often the application will interact with the Internet - e.g. every 5 minutes,
hourly, daily;
- how long the automatic behavior will 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 must be
provided.
All applications that access the network automatically must provide a means for the user to
disable automatic network activity. When automatic network activity is disabled,
periodically prompt the user to make network requests.
Consider allowing the user to adjust the polling schedule and to control which activities
are allowed to initiate network requests.
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 how that data will be exchanged with the server.
In many cases use of APIs that provide access to personal or device information causes a
confirmation dialog to be presented to the user. In this case the application should not
force the user to confirm again at the application level, but should make clear in the UI
that displayed data has been accessed from the device.
If the user declines a prompt to allow application access to personal or device
information, the application must recover gracefully. For example, if a request to a device
API fails, do not automatically retry if this will lead to the user being presented with
repeated confirmation dialogues by the underlying API.
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 uses the gzip and DEFLATE algorithms is widely supported. Web
servers should be configured to serve appropriately compressed responses.
Note however, that the cost (in time and battery usage) of decompressing data should be
balanced against the gains in transport efficiency.When configuring HTTP 1.1 compression
note that:
- Most binary data (especially JPEGs) does not benefit from compression;
- For very small files (e.g. <1k) the negative impact of processing will outweigh any
small transport gains.
Compression 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, JavaScript and CSS files to remove whitespace and minify before delivery. A
number of open source whitespace strippers and JavaScript compilers are available.
The working group is seeking recommendations for the best /
most-commonly used tools to reference in this section.
Request redirection (through HTTP response header or meta refresh) is typically used to
exchange information between servers (e.g. account authentication). The delay incurred by
redirects is much higher over mobile networks and so the number of redirects should be kept to
a minimum to avoid degrading the user experience.
Try not to use more than two redirects for any request. If further redirects are required,
use an interstitial page to communicate to the user that the application is still working.
Applications that automatically issue network requests should provide "value" for those
requests so as not to unnecessarily impact battery life and application performance. Take
care to ensure network requests are as well optimized as possible .
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.
- Back off during periods of inactivity:
- If the application polls for updates, it should monitor user activity and poll less
frequently during inactive periods.
- Device Context:
- If supported by the device, use awareness of current connectivity (e.g. WiFi) to select
an appropriate level of interaction.
Network-initiated content delivery ("push") methods can significantly reduce network
traffic overhead, as compared to conventional polling (scheduled "pull") methods.
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.1 What it means
A Web application typically requires a number of resources (style sheets, scripts, image,
etc) each of which may incur an additional HTTP Request. HTTP 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 How to do it
As far as makes sense after taking into account 3.5.8 Separate Rarely
Used Functionality combine all style sheets into a single resource and all scripts
into a single resource. If multiple scripts and style sheets are required as part of the
authoring process, then try to arrange that they are merged before the page is served.
3.4.7.1 What it means
In some circumstances performance is improved if JavaScript and CSS style sheet resources
are included in the HTML page, eliminating the need for additional HTTP requests to fetch
the external files.
3.4.7.2 How to do it
Whether in-line resources make sense or not depends on a number of factors. For example:
- The cache hit rate (e.g. the number of times users will successfully load 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 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 round-trip which is
detrimental to performance when compared with combining them into a single image for
transfer.
3.4.8.2 How to do it
To optimize efficiency:
- For PNG and GIF files, combine images with similar sizes and color palettes;
- In general, avoid sprites for JPEGs, but where used, align images on 8x8
boundaries;
- Combine images that do not change often, since if one of the component images changes,
the combination image will need to be downloaded.
To render individual components of a resource use CSS positioning and clipping.
3.4.9.1 What it means
Background images are often used as gradients to improve the look and feel of an
application. These can be included in the CSS as base64 encoded strings in order to avoid an
additional HTTP round trip .
3.4.9.2 How to do it
Background images can be encoded using the data URI scheme:
url('data:image/png;base64, [data])
3.4.10.1. What it means
Dynamic resources that change occasionally (e.g. a user's avatar) can still be cached by
identifying them with a URI that includes a fingerprint of the resource content. Using this
technique means that the browser does not need to check the resource headers in order to
validate its cache, instead, any change in the resource will lead naturally to a
corresponding change in the resource reference.
3.4.10.2 How to do it
- Set the resource caching policy to "never expire" by setting the
Expires
header to a date in the far future.
- Reference the resource using a URI that contains a Hash of the content. If the content
changes, this reference will change and the browser will fetch the updated data.
3.4.11.1 What it means
Data designed to be accessed by AJAX requests from the client should be cached in the same
way as primary content.
3.4.11.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 data as readily as primary
content pages.
A Web application may not be suspended if it is placed in background. Consider the impact
of on-going JavaScript operations on battery life.
- Network activity is the biggest drain on 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 ;
- DOM manipulation over an extended period impacts 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.
On small devices with limited processing capability, the cost of excessive DOM manipulation
can impact application performance .
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.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.1 What it means
Static resources don't need cookie information and so performance can be improved by
serving these from a path or sub-domain for which the application's cookies are out of
scope.
3.4.15.2 How to do it
Use a different domain, sub-domain, or path name for static resources to the main
application, and restrict the valid path of cookies such that they will not be exchanged
when they are not needed .
3.4.16.1 What it means
Asynchronous 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 rather than XML if
possible.
- It is more compact;
- It is quicker to parse since it can be directly parsed using the
eval
method.
3.4.16.2 How to do it
JSON data can be built using an open source JSON builder (REF).
On the client, JSON is readily parsed into a JavaScript object model using the
eval method. Note, however, that care should be taken to observe: 3.2.2 Secure JSON Data Feeds and 3.2.3 Use a Safe
eval for JSON Data Feeds.
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:
- Focus Based: The browser focus "jumps" from link to link;
- Pointer Based: Key-based navigation controls a pointer that can cover any part of the
screen;
- Touch Based: Events are related directly to a touch position on the screen with finger
or stylus.
Devices may implement one or more of these approaches and it is important for an
application to remain usable in all cases.
3.5.1.2 How to do it
Particularly where content requires multiple links (ie back/forward in 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 can be widely spaced as the user can select them easily by jumping from link to
link;
- The current location of the user can be easily determined as link elements will be in
focus.
Pointer Based:
- Selectable elements that are associated need to be near each other as scrolling the
pointer can be slow;
- The current location of the user can be easily determined as link elements will be in
focus.
Touch Based:
- Selectable elements can be widely spaced as the user can select them easily;
- 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 of the page means that the view can be updated without a
full page reload. Since reloading the entire page can be slow this can greatly improve
application usability.
Use asynchronous (XHR) requests to get additional information from the server in response
to user events and update the page DOM to convey this to the user.
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.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 request to the server.
3.5.4.2 How to do it
Each view can be rendered in a div element which is hidden using CSS.
JavaScript can be used to reveal content in response to user events.
3.5.5.1 What it means
Web applications can show multiple views by showing and hiding content. However, this means
it is not automatically possible to link directly to these views and the browser
<back> button cannot be used to move between previous views. 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;
- Enabling the browser history provides a natural method to navigate application views
that is natively supported by the browser.
3.5.5.2 How to do it
Each view within an application should have a URI with a 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.
Standardized URI schemes have been defined for some common device functions, e.g. making
phone calls and managing 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].
Code such as the following can be used to enable "Click-to-Call":
<a
href="tel:[PHONE-NUMBER]">[PHONE-NUMBER]</a>
3.5.7.1 What it means
On small screens 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.1 What it means
Perceived performance can be improved by separating out JavaScript functions and CSS styles
that are not required by the initial page. JavaScript functions 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
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 and so we are looking for validation that their
use in this context is a good idea.
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 is available earlier.
3.5.9.2 How to do it
Place CSS style sheet (<style>) elements in the <head>
head element 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 and will block while JavaScript content is parsed.
3.5.10.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 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. 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 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 data store). For any
application data that is not exclusively relevant to the current device, favor storing it on
the server so it can be shared by other devices.
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 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 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" header can be used to identify the device, and a Device Description
Repository (DDR) can be used to retrieve a detailed description of capabilities;
- The "Accept" header can be used to indicate specific MIME types
compatible-to/preferred-by the device;
- The "X-Wap-Profile" header (User Agent Profile or UAProf) can be used both as device
identification and as a source of detailed device 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;
- 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 targeted, or 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" and build a single
application variant for each device bucket.
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" of varying
capability. Focus on application variants that work in each bucket rather than building
device-specific exceptions for every variation in device configuration.
Device buckets should be defined on an application-specific basis, so that the variants can
be tailored accordingly. For example, the following is a typical configuration of
application buckets:
Bucket 1: Basic XHTML support, no or very basic scripting. No AJAX
support.
Bucket 2: Full AJAX and JavaScript support.
Bucket 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 browsers. If
possible, provide a variant of the application that does not rely on script by using
synchronous FORM posts instead.
Essentially this BP states that it is favourable to support "Bucket 1" devices as defined
above if at all possible. 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 application simply has no non-JavaScript counterpart
(e.g. a Web based game, an 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 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) it might make 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 data store.
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 specific 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.
SVG Tiny 1.1 is the most broadly supported.
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.
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.
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.
[To include the set of minimum device properties supporting specific best
practices.]
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://ietf.org/rfc/rfc2119)