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