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-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
an
editor's
editors'
copy
that
has
no
official
standing
and
is
incomplete.
standing.
It
is
subject
to
major
changes
and
is
therefore
not
intended
for
implementation.
It
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
W3C
Membership
Working
Group
is
particularly
seeking
feedback
on:
-
techniques
for
securing
personal
data
on
mobile
devices,
and
the
relative
impacts
of
using
HTTPS
and
other
interested
parties
are
invited
techniques,
see
Use
HTTPS
when
Exchanging
User
Credentials
. -
an
example
"Safe
EVAL"
algorithm
that
can
be
included
in
the
document,
or
a
publicly
available
library
that
can
be
referenced,
see
Use
a
Safe
EVAL
for
JSON
Data
Feeds
-
best/most-commonly
used
tools
to
review
minimize
the
document
size
of
a
Web
application,
see
Minimize
application
size
. -
the
relative
impacts
of
Web
application
activities
on
battery
life,
see
Use
Power-Efficient
Methods
.
-
the
use
of
techniques
aimed
at
separating
out
JavaScript
and
send
comments
to
public-bpwg-comments@w3.org
(with
public
archive
CSS
that
are
rarely
used,
and
in
particular
the
use
of
iframe
on
devices,
see
Separate
Rarely
Used
Functionality
).
Advisory
Committee
Representatives
should
consult
their
WBS
questionnaires
-
specific
SVG
best
practices,
see
SVG
.
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
4
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
@@TODO
This
document
sets
out
a
series
of
recommendations
designed
to
facilitate
development
and
delivery
of
Web
applications
on
mobile
devices.
The
recommendations
are
offered
to
creators,
maintainers
and
operators
of
mobile
Web
sites.
Readers
of
this
document
are
expected
to
be
familiar
with
the
creation
of
Web
applications,
and
to
have
a
general
familiarity
with
the
technologies
involved,
but
are
not
expected
to
have
a
background
in
mobile-specific
mobile
technologies
or
previous
experience
with
Mobile
Web
Best
Practices
1.0
(BP1).
The
intention
is
to
make
clear
to
all
involved
what
the
Best
Practices
are,
and
hence
establish
a
common
basis
of
understanding.
As
a
result
of
wishing
to
be
clear
to
those
not
already
involved
in
the
development
of
mobile
friendly
content,
some
statements
may
appear
to
be
obvious
or
trivial
to
those
with
experience
in
this
area.
The
document
is
not
targeted
solely
at
developers;
others,
such
as
interaction
and
graphic
designers,
and
tool
developers,
are
encouraged
to
read
it.
Some
Best
Practices,
however,
clearly
have
a
more
technical
focus.
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).
(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).
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.
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
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)
working
group
and
the
Device
Independence
Principles
[DIP]
.
The
document
discusses
device
and
delivery
channel
characteristics,
which
the
DIWG
UWA
has
named
"Delivery
Context"
[DCODI]
.
In
addition,
the
document
uses
some
terminology
from
UWA's
Glossary
of
Terms
for
Device
Independence
[DIGLOSS]
.
1.5
Terminology
Note
that
the
term
"JavaScript"
is
used
in
place
of
the
(arguably
more
correct)
term
"ECMAScript"
in
order
to
provide
consistency
with
the
companion
Web
application
technologies
(JSON
and
AJAX)
which
are
in
common
use
and
both
implicitly
refer
to
JavaScript
in
their
names.
Also,
the
term
terms
"AJAX"
is
and
XMLHttpRequest
(XHR)
are
used
as
it
is
in
practice
to
refer
to
any
asynchronous
browser
request.
The
implicit
reference
to
XML
suggested
by
the
name
names
is
commonly
accepted
to
be
an
historical
anomaly.
-
The
Heading
-
A
summary
of
the
functional
area
to
be
addressed
by
these
statements
-
The
Statements
-
One
or
more
Best
Practice
statements
identified
in
the
following
way:
-
[EXAMPLE]
This
Is
A
Best
Practice
Statement
-
What
it
means
-
An
explanation
of
the
intention
of
the
Best
Practice
statement.
-
How
to
do
it
-
A
discussion
of
the
techniques
and
device
capabilities
required
to
implement
this
Best
Practice.
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
interface
should
as
far
as
possible
minimize
user
input.
To
this
end,
personalization
can
eliminate
unnecessary
user
interaction
and
hence
improve
the
user
experience
by
minimizing
the
amount
of
effort
required
to
find
relevant
information.
experience.
If
an
application
requires
information
entered
by
a
service
relies
on
user
entered
information
(e.g.
application
preferences,
personal
details)
the
user
that
information
should
not
normally
have
to
re-enter
that
information
during
be
reentered
either
in
the
normal
course
of
using
the
application
or
between
invocations
of
the
application.
This
is
important
both
within
a
usage
session
and
across
usage
sessions.
A
number
of
technologies
can
be
used
to
persist
user
entered
information.
Usually
Consider
using
a
combination
of
technologies
will
be
required,
the
choice
of
which
is
application
and
context
specific:
techniques:
-
Server
Based
Session
Management:
-
Most
servers
offer
the
facility
Session
management
is
a
feature
of
many
server
frameworks
(e.g.
).
Requests
belonging
to
store
client
state
in-memory
on
the
server.
By
default
they
will
identify
the
request
based
on
either
a
cookie
same
session
are
typically
identified
using
cookies
or
by
URI
decoration.
-
JavaScript
Variables:
-
JavaScript
object
state
can
be
used
as
a
temporary
datastore
data
store
provided
the
page
is
not
reloaded.
Note,
however,
that
the
JavaScript
runtime
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
usage
session,
state
can
be
preserved
between
pages
by
storing
extra
personalization
information
in
hidden
form
elements,
e.g:
<input
type="hidden"
name="somedata"
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.
-
Persistent
URL:
Unique
URI:
-
Where
no
alternative
exists
(e.g.
cookies
are
unsupported)
some
degree
of
personalization
is
still
possible
by
redirecting
the
Each
user
to
can
be
allocated
a
persistent
URL
(PURL).
specific
URI.
On
first-use,
first
use
of
the
application,
users
should
be
prompted
to
bookmark
this
unique
URL
URI
and
to
use
it
to
identify
them
in
future
requests.
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
is
appropriate
can
be
used
for
more
complex
extensive
and
larger
structured
data
than
would
be
possible
with
other
methods.
Cookies
and
URIs.
See
Offline
Webapps
Web
Applications
for
more
details.
-
Server
Based
Datastore:
Data
Store:
-
Extensive
personalization
data
and
state
that
is
required
across
usage
sessions
should
be
stored
in
a
server-side
datastore
whenever
possible.
data
store.
A
server
based
datastore
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.
A
Service
Provider
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
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
datafeed
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
user
data
to
malicious
Web
sites.
If
a
JSON
datafeed
data
feed
is
executable,
a
malicious
Web
site
can
reference
it
in
a
<script>
element.
This
will
execute
the
datafeed
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
datafeed
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"},
{ username: "My Name",
contacts: [
{name: "Contact1", phonenumber: "xx-xxx-xxxx"},
{name:
"Contact2",
phonenumber:
"xx-xxx-xxxx"}]
}
{ username: "My Name",
contacts: [
{name: "Contact1", 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
datafeed
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"
eval"
method
which
encodes
any
unsafe
characters
in
the
datafeed
data
feed
before
evaluating.
The
working
group
is
looking
for
feedback
on
an
example
"Safe
EVAL"
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
behaviors
that
might
affect
the
overall
application
behaviour,
actions,
and
that
the
user
is
offered
offer
options
to
control
those
behaviors.
Many
browsers
support
the
ability
to
make
background
server
requests
without
requiring
a
server
roundtrip.
This
makes
it
possible
to
make
server
requests
that
are
not
automatically
reflected
in
the
user-interface
and
which
might
surprise
the
user
or
lead
to
unexpected
data
charges.
actions.
A
number
of
standard
and
proprietary
APIs
exist
to
give
browsers
Browsers
may
have
access
to
both
personal
and
device
information,
for
example:
information
such
as:
-
File
system
access
to
pictures,
Pictures,
music,
and
video
clips
clips;
-
PIM
data
(contacts,
calendar)
Contacts,
calendar
(PIM
data);
-
Call
handling
history;
-
System
data
(battery,
coverage,
roaming,
location)
location);
-
Media
recording
(record
audio/video
clip,
get
new
picture)
picture);
-
Device
context
(e.g.
location,
connectivity,
profile
setting)
setting).
Use
of
such
personal
information
and
device
functions
can
expose
Many
browsers
support
the
user
ability
to
privacy
and
security
concerns.
The
overall
goal
is
make
background
server
requests
(i.e.
requests
that
do
not
require
action
by
the
user
user).
Unless
specific
action
is
informed
of
taken
to
provide
information
about
such
activities,
given
effective
means
activity,
users
may
be
exposed
to
control
them,
revealing
information
that
they
did
not
intend
to
reveal
and
also
the
opportunity
may
be
subject
to
opt-out
of
their
use.
unexpected
data
charges.
Whenever
an
application
makes
background
data
requests,
whether
automatic
or
user-initiated,
user-initiated
,
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,
or
in
associated
help
pages.
The
kinds
of
detailed
information
that
could
be
disclosed
in
associated
help
pages
or
terms
of
service
are:
-
how
often
the
application
will
interact
with
the
internet.
E.g.
Internet
-
e.g.
every
5
minutes,
hourly,
daily.
daily;
-
how
long
the
automatic
behaviour
behavior
will
continue.
continue;
-
how
heavy
the
overall
usage
is
expected
to
be
or
the
type
of
service
plan
recommended.
If
an
application
makes
automatic
network
requests
(e.g.
to
poll
the
server
for
updates
or
to
automatically
store
an
updated
client
state)
a
means
to
control
this
activity
should
must
be
provided.
At
a
minimum,
All
applications
that
access
the
network
automatically
must
provide
a
means
for
the
ability
user
to
switch
off
the
disable
automatic
network
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
how
that
data
will
be
exchanged
with
the
server.
Applications
should
be
defensive
and
remain
as
functional
as
possible
if
the
API
request
for
information
is
denied.
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
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
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
efficiency.When
configuring
HTTP
1.1
compression:
compression
note
that:
-
Most
binary
data
(especially
JPEGs)
will
does
not
benefit
from
gzip
compression.
compression;
-
For
very
small
files
(e.g.
<1k)
the
negative
impact
of
processing
may
will
outweigh
any
small
transport
gains.
Gzipping
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).
them);
-
Use
consistent
casing
(e.g.
all
lowercase)
lowercase);
-
Use
consistent
quoting
(e.g.
always
use
single-quotes)
single-quotes).
This
section
elaborates
on
the
Best
Practices
of
BP1
(
MINIMIZE
).
Smaller
applications
will
download
and
execute
more
quickly
and
more
reliably
than
larger
ones
on
constrained
devices.
Process
HTML
HTML,
JavaScript
and
CSS
files
at
build
time
to
remove
whitespace
and
minify.
minify
before
delivery.
A
number
of
Open
Source
open
source
whitespace
strippers
are
available.
Process
script
files
at
build
time
to
remove
whitespace
and
minify
the
script.
Several
Open
Source
javascript
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).
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
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.
redirects
for
any
request.
If
further
redirects
are
required,
use
a
landing
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
battery
life
and
application
performance.
Take
care
to
ensure
network
requests
are
as
well
optimized
as
possible.
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.
-
Backoff
Back
off
during
periods
of
inactivity:
-
If
the
application
polls
for
updates,
it
should
monitor
user-activity
user
activity
and
poll
less
frequently
during
inactive
periods.
-
Device
Context:
-
If
supported
by
the
device,
use
awareness
of
current
connectivity
(e.g.
WiFi)
to
select
an
appropriate
level
of
interaction.
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
(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
How
to
do
it
As
far
as
makes
sense
after
taking
into
account
3.5.8
Separate
Rarely
Used
Functionality
combine
all
stylesheets
style
sheets
into
a
single
resource
and
all
scripts
into
a
single
resource.
If
multiple
scripts
and
stylesheets
style
sheets
are
required
as
part
of
the
authoring
process,
then
try
to
arrange
that
they
are
merged
before
the
page
is
served.
3.4.7.1
What
it
means
In
some
circumstances
performance
is
improved
if
the
JavaScript
and
CSS
stylesheet
style
sheet
resources
are
inlined
included
in
the
HTML
page,
since
it
eliminates
eliminating
the
need
for
two
additional
HTTP
requests
required
to
fetch
the
external
files.
3.4.7.2
How
to
do
it
Investigate
for
a
given
application
the
optimum
configuration.
Whether
inlined
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
an
average
user
users
will
successfully
load
script
resources
from
the
browser
cache).
-
The
size
of
the
JavaScript
and
CSS
files.
-
The
frequency
with
which
the
JavaScript
and
CSS
files
change.
3.4.8.1
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
How
to
do
it
Using
manual
or
automatic
means,
combine
all
icons
into
a
single
image.
To
optimize
the
efficiency
of
this:
efficiency:
-
For
PNG
and
GIF
files,
sprite
combine
images
with
similar
sizes
and
colour
palettes.
color
palettes;
-
In
general,
avoid
spites
sprites
for
JPEGs,
but
if
you
do
use
them,
sprite
where
used,
align
images
on
8x8
boundaries.
boundaries;
-
Sprite
Combine
images
that
don't
do
not
change
often
--
e.g.
often,
since
if
a
single
image
in
a
sprite
changes
one
of
the
whole
sprite
component
images
changes,
the
combination
image
will
need
to
be
downloaded.
To
render
individual
icons
from
components
of
a
sprited
resource
using
css
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
inlined
included
in
the
CSS
as
base64
encoded
strings
in
order
to
avoid
an
additional
HTTP
roundtrip.
round
trip
.
3.4.9.2
How
to
do
it
Background
images
can
be
embedded
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
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
How
to
do
it
-
Set
the
resource
caching
policy
to
never
expire
"never
expire"
by
setting
the
Expires
header
to
a
date
in
the
far
future.
-
Reference
the
resource
using
a
URL
URI
that
contains
a
Hash
of
the
content.
If
the
content
changes,
this
reference
will
change
and
the
browser
will
fetch
the
updated
data.
3.4.11.1
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
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.
A
Web
application
is
may
not
guaranteed
to
be
suspended
if
it
is
placed
in
the
background
and
may
continue
running
for
a
long
period.
In
this
case,
background.
Consider
the
impact
of
prolonged
on-going
JavaScript
operations
on
battery-life
should
be
considered.
battery
life.
-
Network
activity
is
the
biggest
drain
on
battery
power.
If
the
application
requires
ongoing
network
activity
(e.g.
to
poll
a
server
for
updates)
take
steps
to
inform
the
user
of
this
activity
and
minimize
its
impact
on
battery-life.
See
3.3.1
Inform
the
User
About
Automatic
Network
Access
;
-
Excessive
DOM
manipulation
over
an
extended
period
of
time
can
also
impact
impacts
device
battery
life.
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.
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
subdomain
sub-domain
for
which
the
application
application's
cookies
are
out
of
scope.
3.4.15.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.
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
in
favour
of
rather
than
XML
if
possible.
-
It
is
more
compact.
compact;
-
It
is
quicker
to
parse
since
it
can
be
directly
parsed
using
the
eval
method.
3.4.16.2
How
to
do
it
A
JSON
datafeed
data
can
be
built
from
an
object
model
by
hand,
or
using
an
Open
Source
open
source
JSON
builder
(
REF
).
On
the
client,
JSON
is
readily
parsed
into
a
javascript
JavaScript
object
model
using
the
eval
method.
Note,
however,
that
care
should
be
taken
to
observe:
3.2.2
Secure
JSON
Datafeeds
Data
Feeds
and
3.2.3
Use
a
Safe
EVAL
eval
for
JSON
Datafeeds
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.
link;
-
Pointer
Based:
Key-based
navigation
controls
a
pointer
that
can
cover
any
part
of
the
screen.
screen;
-
Touch
Based:
Events
are
related
directly
to
a
touch
position
on
the
screen
with
finger
or
stylus.
Devices
may
implement
one
or
more
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,
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.
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.
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.
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
server
roundtrip.
request
to
the
server.
3.5.4.2
How
to
do
it
Each
view
can
be
rendered
in
a
DIV
div
element
which
is
hidden
using
css.
Client-side
script
CSS.
JavaScript
can
be
used
to
reveal
content
in
response
to
user
events
without
the
need
for
a
server
roundtrip.
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.
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
be
identified
have
a
URI
with
a
fragmentID
distinguishing
fragment
identifier
(e.g.
http://www.myapp.com/myapp#view)
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
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
RFC-3966
.
Use
this
[
RFC3966
].
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
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.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
On-demand
loading
can
be
accomplished
by:
-
Moving
that
functionality
onto
an
entirely
separate
page.
page;
-
Creating
an
embedded
frame
to
load
the
required
additional
resources
in
response
to
a
page
event.
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
stylesheet
style
sheet
(
<style>
)
elements
in
the
<head>
stanza
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
datastore).
data
store).
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.
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
preferrable
preferable
to
detect
these
capabilities
on
the
server
and
adapt
content
before
it
is
sent
to
the
client
in
order
to
avoid
transferring
unnecessary
data.
Typically
used
methods
of
device
capabilities
detection:
-
The
"user-agent"
"User-Agent"
header
can
be
used
to
identify
the
device,
and
a
Device
Description
Repository
(DDR)
can
be
used
to
retrieve
a
detailed
description
of
capabilities.
capabilities;
-
The
"accept"
"Accept"
header
can
be
used
to
indicate
specific
MIME
types
compatible-to/preferred-by
the
device.
device;
-
The
"x-wap-profile"
"X-Wap-Profile"
header
(User
Agent
Profile
or
UAProf)
can
be
used
both
as
device
identification
and
as
a
source
for
of
detailed
device
capabilities
info.
capabilities.
For
dynamic
device
state
that
might
depend
on
the
configuration
or
context
of
the
device
(e.g.
Is
scripting
enabled?
Is
the
SDCard
available?
Has
permission
been
granted
for
PIM
access?)
detection
must
be
done
on
the
device.
Use
JavaScript
reflection
to
determine
if
a
given
API
is
active
and
interrogate
the
device
configuration
using
appropriate
APIs.
Two
methods
can
then
be
used
to
adapt
on
the
client
to
differing
configurations:
-
Encapsulate
the
different
behaviours
in
the
control
logic
of
the
application.
E.g.
simply
use:
if
(some_configuration_variable)
decision-points
in
the
code
and
behave
accordingly.
accordingly;
-
Use
an
initial
"bootstrap"
script
to
assess
device
capabilities
and
request
the
appropriate
application
bundle
accordingly.
Option
(1)
is
simpler
to
implement
and
is
appropriate
provided
the
amount
of
inactive
code
downloaded
doesn't
have
a
negative
impact
on
performance.
Option
(2)
is
preferred
when
the
application
must
change
significantly
in
response
to
properties
that
can
only
be
determined
on
the
client.
If
a
large
number
of
devices
are
being
targetted,
targeted,
or
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
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
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
datastore.
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
specfic
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
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.2
Background
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
XML
-
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:
Client
Interfaces
(DCCI)
1.0,
Context
Overview
for
Device
Independence,
,
R.
Gimson,
R.
Lewis,
S.
Sathish,
Editors,
W3C
Candidate
Recommendation
21
December
2007
Working
Group
Note,
20
March
2006
(See
http://www.w3.org/TR/DPF/
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
(Third
(Fifth
Edition),
Tim
Bray,
Jean
Paoli,
C.
M.
Sperberg-McQueen,
Eve
Maler,
Fran?ois
François
Yergeau,
Editors,
W3C
Recommendation,
04
February
2004
26
November
2008
(See
http://www.w3.org/TR/2004/REC-xml-20040204/
http://www.w3.org/TR/2008/REC-xml-20081126/
)
-
XHTML-Basic
-
XHTML
Basic
1.1,
Shane
McCarron,
Masayasu
Ishikawa,
Editors,
W3C
Working
Draft,
5
Recommendation,
29
July
2006
2008
(See
http://www.w3.org/TR/xhtml-basic/
http://www.w3.org/TR/2008/REC-xhtml-basic-20080729/
)
-
CSS
-
Cascading
Style
Sheets
(CSS1)
Level
1
Specification,
H?kon
Håkon
Wium
Lie,
Bert
Bos,
Editors,
W3C
Recommendation,
11
Jan
1999
January
1999,
revised
11
April
2008
(See
http://www.w3.org/TR/REC-CSS1
http://www.w3.org/TR/2008/REC-CSS1-20080411/
)
-
CSS2
-
Cascading
Style
Sheets,
level
2
CSS2
Specification,
Bert
Bos,
H?kon
Håkon
Wium
Lie,
Chris
Lilley,
Ian
Jacobs,
Editors,
W3C
Recommendation,
12
May
1998
1998,
revised
11
April
2008
(See
http://www.w3.org/TR/REC-CSS2/
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/release_program/docs/UAProf/V2_0-20060206-A/OMA-TS-UAProf-V2_0-20060206-A.pdf
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)