This
document
specifies
Best
Practices
for
the
development
and
delivery
of
Web
applications
on
mobile
devices.
The
recommendations
expand
upon
statements
made
in
the
Mobile
Web
Best
Practices
1.0
(BP1),
especially
concerning
statements
that
relate
to
the
exploitation
of
device
capabilities
and
awareness
of
the
delivery
context.
Furthermore,
since
BP1
was
written,
networks
and
devices
have
continued
to
evolve,
with
the
result
that
a
number
of
Best
Practices
that
were
omitted
from
BP1
can
now
be
included.
The
recommendation
is
primarily
directed
at
creators,
maintainers
and
operators
of
Web
applications.
Readers
of
this
document
are
expected
to
be
familiar
with
the
creation
of
Web
sites,
and
to
have
a
general
familiarity
with
the
technologies
involved,
such
as
Web
servers,
HTTP,
and
Web
application
technologies.
Readers
are
not
expected
to
have
a
background
in
mobile
technologies
or
previous
experience
with
BP1.
This
section
describes
the
status
of
this
document
at
the
time
of
its
publication.
Other
documents
may
supersede
this
document.
A
list
of
current
W3C
publications
and
the
latest
revision
of
this
technical
report
can
be
found
in
the
W3C
technical
reports
index
at
http://www.w3.org/TR/.
Incomplete
draft
:
This
document
is
an
editors'
copy
that
has
no
official
standing.
It
is
subject
to
major
changes
and
is
therefore
not
intended
for
implementation.
In
particular,
the
list
of
Best
Practices
is
not
settled
yet.
The
document
is
provided
for
review
and
feedback
only
.
Please
send
feedback
to
public-bpwg-comments@w3.org
(
archive
).
The
Working
Group
is
particularly
seeking
feedback
on:
-
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
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
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
.
-
the
use
of
techniques
aimed
at
separating
out
JavaScript
and
CSS
that
are
rarely
used,
and
in
particular
the
use
of
iframe
on
devices,
see
Separate
Rarely
Used
Functionality
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
5
February
2004
W3C
Patent
Policy
.
This
document
is
informative
only.
W3C
maintains
a
public
list
of
any
patent
disclosures
made
in
connection
with
the
deliverables
of
the
group;
that
page
also
includes
instructions
for
disclosing
a
patent.
An
individual
who
has
actual
knowledge
of
a
patent
which
the
individual
believes
contains
Essential
Claim(s)
must
disclose
the
information
in
accordance
with
section
6
of
the
W3C
Patent
Policy
.
The
following
Best
Practices
are
discussed
in
this
document
and
listed
here
for
convenience.
@@TODO
This
document
sets
out
a
series
of
recommendations
designed
to
facilitate
development
and
delivery
of
Web
applications
on
mobile
devices.
The
recommendations
are
offered
to
creators,
maintainers
and
operators
of
mobile
Web
sites.
Readers
of
this
document
are
expected
to
be
familiar
with
the
creation
of
Web
applications,
and
to
have
a
general
familiarity
with
the
technologies
involved,
but
are
not
expected
to
have
a
background
in
mobile
technologies
or
previous
experience
with
Mobile
Web
Best
Practices
1.0
(BP1).
The
intention
is
to
make
clear
to
all
involved
what
the
Best
Practices
are,
and
hence
establish
a
common
basis
of
understanding.
As
a
result
of
wishing
to
be
clear
to
those
not
already
involved
in
the
development
of
mobile
friendly
content,
some
statements
may
appear
to
be
obvious
or
trivial
to
those
with
experience
in
this
area.
The
document
is
not
targeted
solely
at
developers;
others,
such
as
interaction
and
graphic
designers,
and
tool
developers,
are
encouraged
to
read
it.
Some
Best
Practices,
however,
clearly
have
a
more
technical
focus
Well,
since
we
are
about
to
say
that
they
can
safely
be
ignored,
perhaps
we
should
be
clear
about
which
ones,
precisely.
.
These
are
likely
to
be
of
interest
only
to
developers
interesting
in
building
highly
optimized
/
advanced
mobile
Web
applications
and
can
be
safely
ignored
by
other
disciplines.
These
recommendations
expand
on
the
recommendations
of
the
Mobile
Web
Best
Practices
(BP1)
.
Where
the
focus
of
BP1
is
primarily
the
extension
of
Web
browsing
to
mobile
devices,
this
document
considers
the
development
of
Web
applications
on
mobile
devices.
The
approach
in
writing
this
document
has
been
to
collate
and
present
the
most
relevant
engineering
practices
prevalent
in
the
development
community
today
and
identify
those
that:
a)
facilitate
the
exploitation
of
device
capabilities
to
enable
a
better
user
experience;
or
b)
are
considered
harmful
and
can
have
non-obvious
detrimental
effects
on
the
overall
quality
of
the
application.
The
goal
of
this
document
is
not
to
invent
or
endorse
future
technologies.
However,
there
are
a
number
of
cases
where
explicitly
omitting
a
Best
Practice
that
referred
to
an
emerging
technology
on
the
grounds
that
it
was
too
recent
to
have
received
wide
adoption
would
have
unnecessarily
excluded
a
valuable
recommendation.
As
such,
some
Best
Practices
have
been
included
on
the
grounds
that
the
Working
Group
believes
that
they
will
soon
become
fully
qualified
Best
Practices
(e.g.
in
prevalent
use
within
the
development
community).
For
the
purposes
of
this
document,
the
term
"Web
application"
refers
to
a
Web
page
(XHTML
or
a
variant
thereof
+
CSS)
or
collection
of
Web
pages
delivered
over
HTTP
which
use
either
server-side
or
client-side
processing
(e.g.
JavaScript)
to
provide
an
"application-like"
experience
within
a
Web
browser.
Web
applications
are
distinct
from
simple
Web
content
(the
focus
of
BP1)
in
that
they
include
some
elements
of
interactivity
and
persistent
state.
While
the
focus
of
this
document
is
to
document
Best
Practices
that
apply
to
applications
running
in
a
Web
browser,
in
many
cases
these
recommendations
are
equally
applicable
to
other
kinds
of
Web
run-time,
such
as
the
widget
frameworks
being
considered
as
part
of
the
Web
Widgets
[REF]
effort
and
also
in
a
number
of
vendor-specific
initiatives.
In
an
increasingly
mobilized
world
the
line
between
mobile
and
non-mobile
is
necessarily
blurred
and
a
document
that
restricts
its
focus
solely
to
best
practices
that
are
uniquely
mobile
would
most
likely
be
very
short.
With
this
in
mind,
the
focus
of
this
document
is
to
address
those
aspects
of
Web
application
development
for
which
there
are
additional,
non-trivial
concerns
associated
with
the
mobile
context.
This
applies
equally
both
to
the
limitations
of
the
mobile
context
(e.g.
small
screen,
poor
connectivity),
and
also
the
additional
scope
and
features
that
must
be
considered
when
developing
for
the
mobile
context
(e.g.
device
context
/
location,
presence
of
personal
data
on
the
device,
etc).
1.3.4
Delivery
Context
Requirements
on
delivery
context
have
not
been
made
explicitly,
but
most
best
practices
assume
devices
with
basic
XHTML,
JavaScript,
and
CSS
compliance.
Additionally,
some
best
practices
are
relevant
only
if
the
device
exposes
certain
capabilities
(for
example,
access
to
device
information
such
as
location).
Implied
by
this
discussion
is
that
some
level
of
device
knowledge
and
content
adaptation
is
required.
For
best
practices
specifically
related
to
this
area,
see
3.6.1
Use
Server-side
Capability
Detection
for
Device
Properties
and
3.6.2
Use
Client-side
Capability
Detection
for
Device
State
.
These
recommendations
are
complimentary
to
the
recommendations
of
Mobile
Web
Best
Practices
1.0
(BP1).
This
document
builds
on
some
of
the
concepts
described
by
the
Ubiquitous
Web
Applications
Working
Group
(UWA)
and
the
Device
Independence
Principles
[DIP]
.
The
document
discusses
device
and
delivery
channel
characteristics,
which
the
UWA
has
named
"Delivery
Context"
[DCODI]
.
In
addition,
the
document
uses
some
terminology
from
UWA's
Glossary
of
Terms
for
Device
Independence
[DIGLOSS]
.
1.5
Terminology
Note
that
the
term
"JavaScript"
is
used
in
place
of
the
(arguably
more
correct)
term
"ECMAScript"
in
order
to
provide
consistency
with
the
companion
Web
application
technologies
(JSON
and
AJAX)
which
are
in
common
use
and
both
implicitly
refer
to
JavaScript
in
their
names.
Also,
the
terms
"AJAX"
and
XMLHttpRequest
(XHR)
are
used
to
refer
to
any
asynchronous
browser
request.
The
implicit
reference
to
XML
suggested
by
the
names
is
commonly
accepted
to
be
an
historical
anomaly.
-
The
Heading
-
A
summary
of
the
functional
area
to
be
addressed
by
these
statements
-
The
Statements
One
or
more
Best
Practice
statements
identified
in
the
following
way:
[EXAMPLE]
This
Is
A
Best
Practice
Statement
What
it
means
-
An
explanation
of
the
intention
of
the
Best
Practice
statement.
-
How
to
do
it
-
A
discussion
of
the
techniques
and
device
capabilities
required
to
implement
this
Best
Practice.
-
Requires
-
A
summary
of
device
capabilities
required
in
order
for
this
Best
Practice
to
apply.
This
section
elaborates
on
Most
applications
have
the
recommendations
of
BP1
Section
5.5
which
details
ways
need
to
minimize
the
amount
store
data
of
user
input
required.
Given
various
forms,
both
intrinsic
content
(e.g.
the
typical
input
limitations
of
a
mobile
device,
input
emails
of
data
can
require
special
effort
by
an
email
application,
the
user.
Reuse
calendar
events
of
relevant
information
about
the
user
can
eliminate
unnecessary
user
interaction
a
calendar
application)
and
hence
improve
supplementary
personalization
settings
(e.g.
preferred
theme,
default
view,
etc).
These
Best
Practices
relate
to
the
user
experience.
appropriate
technologies
and
techniques
to
use
for
managing
a
Web
application's
data
model.
If
an
application
requires
information
entered
by
Cookies
are
a
user
(e.g.
application
preferences,
personal
details)
that
information
should
not
normally
have
common
and
effective
means
to
be
reentered
either
in
the
course
of
using
the
application
or
between
invocations
store
small
amounts
of
state
on
the
application.
3.1.1.2
How
to
do
it
A
number
of
technologies
can
be
client.
They
are
most
appropriate
for
simple
personalization
data
and
are
also
commonly
used
to
persist
user
entered
information.
Consider
using
a
combination
of
techniques:
Server
Based
Session
Management:
Session
management
is
store
a
feature
of
many
server
frameworks
(e.g.
need
examples
PHP,
.net
etc.
).
Requests
belonging
token
representing
user
identity
in
order
to
the
same
session
are
typically
identified
using
cookies
or
URI
decoration.
JavaScript
Variables:
JavaScript
object
state
can
be
used
as
a
temporary
data
store
provided
the
page
is
not
reloaded.
Note,
however,
enable
automatic
sign-in.
Note
however
that
the
JavaScript
run-time
is
not
guaranteed
to
remain
cookie
support
cannot
be
relied
upon
and
may
be
disabled
either
in
memory
if
the
application
is
placed
in
device
configuration
or
by
the
background,
and
so
JavaScript
state
should
be
used
only
for
short-lived
and
volatile
data.
I
think
mobile
network.
For
this
needs
a
deal
more
explanation
if
it
is
helpful.
Are
we
saying
"use
javascript
variables
reason
applications
should
endeavour
to
remain
as
variables,
but
don't
use
them
for
persistent
data
storage?"
Hidden
Form
Elements:
Within
a
session,
state
can
be
preserved
between
pages
by
storing
information
in
hidden
form
elements,
e.g:
<input
type="hidden"
name="some_data"
value="some_previously_entered_value"/>.
Cookies:
When
supported
and
active,
functional
as
possible
even
if
cookies
are
a
common
and
effective
means
to
store
state
on
the
client.
Be
aware,
however,
unavailable.
Also
note
that
cookie
data
is
exchanged
with
sent
to
the
server
on
every
with
each
request
and
so
an
excessive
volume
of
cookie
data
can
impact
performance.
degrade
performance
over
mobile
networks.
See
3.4.14
Reduce
Cookie
Size
for
more
details.
Also
see
and
BP1
[COOKIES]
Do
not
rely
on
cookies
being
available
for
more
detail.
Unique
URI:
Each
user
can
be
allocated
a
specific
URI.
On
first
use
of
the
application,
users
should
be
prompted
to
bookmark
this
unique
URI
and
to
use
it
when
subsequently
invoking
the
application.
appropriate
cookie
related
caveats.
If
supported,
the
HTML5
Local
Storage
API
is
supported,
client-side
storage
APIs
can
be
used
to
store
application
data
locally
on
the
device.
It
can
be
used
for
For
a
more
extensive
and
structured
data
than
Cookies
and
URIs.
See
detailed
technical
summary
see
Offline
Web
Applications
.
Client-side
storage
provides
a
powerful
mechanism
for
more
details.
Server
Based
Data
Store:
Extensive
personalization
data
and
state
that
is
required
across
sessions
should
be
stored
in
Web
applications
to
maintain
a
server-side
local
data
store.
model.
This
provides
two
main
advantages:
Service
Providers
(e.g.
Mobile
Network
Operators
or
Web
Portal
Providers)
or
an
Identity
Management
Provider
like
what?
may
provide
means
to
access
trusted
what
is
the
distinction
we
There
are
making
by
saying
"trusted"
need
to
spell
this
out
if
two
APIs
available
in
HTML5
that
facilitate
storage
on
the
distinction
is
material
user
identities
automatically.
device.
-
Local
Storage
API
-
This
has
the
advantage
API
provides
simple
key
=
value
persistent
storage
that
fulfills
many
of
removing
the
need
for
the
user
to
enter
their
identity
at
all
and
will
provide
an
optimal
experience.
Alternatively,
same
needs
as
cookies
but
without
the
simplest
way
overhead
of
this
information
being
transferred
to
identify
the
user
server
on
each
request.
It
is
to
prompt
appropriate
for
login
credentials
on
first
access
and
storing
relatively
simple,
unstructured
data.
-
SQL
API
-
The
SQL
Database
API
provides
the
ability
to
store
a
Hashed
identity
token
and
retrieve
data
in
a
cookie
for
future
accesses.
Recommended
methods
for
doing
this
Needs
clarification
as
to
what
local
database
.
This
is
meant?
identify
user?
simplify
invocation
of
the
application?
collect
credentials
on
application
invocation?
Also
these
sections
are
somewhat
repetitious
of
each
other.
include:
HTTP
Digest
Authentication.
HTTP
Basic
Authentication
(in
which
case
it
must
be
over
a
secure
HTTPS
connection,
see
3.2.1
Protect
Personal
Information
Used
in
Transactions
).
Web
form
(delivered
over
a
secure
HTTPS
connection).
3.2
Security
appropriate
for
more
extensive
and
privacy
structured
content.
Use
trusted
information,
[
HTML5
icon
]
Requires:
HTML5
Local
Storage
API
and
protect
all
personally
identifiable
information.
HTML5
Database
Storage.
Although
HTTPS
Local
data
storage
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
powerful
provision
that
allows
Web
applications
to
the
level
of
sensitivity
of
the
information
being
exchanged.
Personally
identifiable
information
(e.g.
user
identity
or
information
usable
as
maintain
a
key
local
data
model.
However,
changes
to
user
identity)
should
the
local
data
model
are
only
be
accepted
or
sent
securely.
Less
sensitive
information
visible
on
the
device
that
cannot
made
them
and
should
be
associated
with
an
individual
(e.g.
a
ZIP
code
by
itself
is
not
personally
identifiable)
does
not
need
replicated
to
use
HTTPS
provided
the
correlating
information
is
secure.
I
don't
think
I
understand
what
this
is
telling
me
server
in
order
to
do,
one
way
or
the
other.
What
is
correlating
information?
provide
a
consistent
view
across
devices.
See
3.5.10
Ensure
Consistency
Between
Desktop
and
Mobile
for
more
details.
HTTPS
is
HTML5
provides
a
property
on
the
most
secure
way
navigator
object
(
navigator.onLine
)
to
exchange
sensitive
information
such
as
user-identity.
To
avoid
indicate
whether
the
overhead
of
using
HTTPS
for
all
transactions,
client
is
currently
online,
and
dispatches
two
events
on
the
Window
object
to
indicate
a
related
pseudo-identity
or
secure
hash
change
of
the
actual
identity
can
be
exchanged
in
non-secure
transactions.
network
state
(
online
and
offline
).
HTTPS
Mobile
Web
applications
should
always
be
used
to
exchange
the
initial
user
credentials,
but
subsequent
requests
need
not
use
HTTPS
provided
the
user
identity
is
exchanged
in
these
events
to
control
the
form
asynchronous
replication
of
a
Hashed
Identity
Token.
data
back
to
the
server.
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
[
HTML5
icon
]
Requires:
HTML5
Local
Storage
API
and
might
pose
an
unacceptable
security
risk.
HTML5
Database
Storage.
Use
trusted
information,
and
protect
all
personally
identifiable
information.
3.2.2.1
3.2.1.1
What
it
means
A
common
paradigm
in
Web
applications
JSON
is
to
provide
a
very
commonly
used
method
to
transfer
data
feed
to
an
JavaScript
based
Web
client
in
the
form
client,
usually
as
part
of
an
executable
JavaScript
string
(e.g.
JSON).
Surely,
strictly
speaking,
JSON
(RFC
4627)
-
being
a
data
representation
format,
is
not
executable?
Should
we
not
be
clearer
about
this?
asynchronous
request.
However,
using
eval();
This
has
many
advantages
in
terms
of
speed
of
execution
and
ease
of
development,
but
it
to
directly
execute
the
incoming
datafeed
represents
a
significant
security
flaw
which
can
expose
user
data
to
malicious
Web
sites.
risk
and
should
be
avoided.
If
a
JSON
data
feed
is
executable,
a
Inadvertantly
executing
malicious
Web
site
can
reference
it
in
a
<script>
element.
This
will
execute
the
data
feed
using
the
cookies
associated
with
the
data
providing
site
and
in
most
cases
generate
a
JavaScript
object
model
in
the
client
which
can
be
accessed
by
the
malicious
site.
Perhaps
I
am
being
feeble
minded,
but
I
think
this
could
is
particularly
dangerous
on
mobile
devices
where
personal
information
(current
location,
contact
data,
etc)
may
be
spelled
out
a
bit
more
to
clarify
what
the
vulnerability
is?
exposed.
3.2.2.2
3.2.1.2
How
to
do
it
The
JavaScript
data
feed
should
be
protected
by
a
prefix
that
will
prevent
execution
directly,
but
which
can
be
stripped
off
prior
to
execution
when
accessed
by
an
XHR
request.
Insecure
JSON
feed:
{ username: "My Name",
contacts: [
{name: "Contact1", phonenumber: "xx-xxx-xxxx"},
{name:
"Contact2",
phonenumber:
"xx-xxx-xxxx"}]
}
Secure
JSON
feed:
{ username: "My Name",
contacts: [
{name: "Contact1", phonenumber: "xx-xxx-xxxx"},
{name:
"Contact2",
phonenumber:
"xx-xxx-xxxx"}]
}
3.2.3
Use
a
Safe
eval
for
JSON
Data
Feeds
The
whole
Instead
of
this
needs
a
bit
more
clarity
in
my
view
-
should
we
not
be
distinguishing
between
incorrect
data,
incorrectly
formatted
parsing
JSON
data
and
malicious
data?
Should
we
not
be
a
little
clearer
as
to
what
by
executing
it
with
the
risk
is
that
a
user
might
enter
a
code
fragment
as
data
and
what
effect
that
would
have
on
other
users?
Are
we
actually
saying
"use
browser's
eval();
command,
use
a
JSON
parser,
don't
use
eval"?
3.2.3.1
What
it
means
parser
instead
(for
example:
http://www.json.org/json_parse.js
).
If
a
In
cases
where
directly
evaluating
the
JSON
data
feed
is
being
parsed
using
the
eval();
method
it
is
vulnerable
to
script
attacks.
For
example,
if
the
feed
contains
user
entered
data
this
data
might
replicate
the
JSON
syntax
in
order
to
compromise
the
application.
3.2.3.2
How
to
do
it
There
are
a
number
of
steps
which
can
be
used
to
protect
against
this
kind
desirable
for
reasons
of
attack,
use
the
one
most
appropriate
to
the
context:
Ensure
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
data
feed
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
actions,
and
offer
options
to
control
those
actions.
Browsers
may
have
access
to
information
such
as:
-
Pictures,
music,
and
video
clips;
-
Contacts,
calendar
(PIM
data);
-
Call
history;
-
System
data
(battery,
coverage,
roaming,
location);
-
Media
recording
(record
audio/video
clip,
get
new
picture);
-
Device
context
(e.g.
location,
connectivity,
profile
setting).
Many
browsers
support
the
ability
to
make
background
server
requests
(i.e.
requests
that
do
not
require
action
by
the
user).
Unless
specific
action
is
taken
to
provide
information
about
such
activity,
users
may
be
exposed
to
revealing
information
that
they
did
not
intend
to
reveal
and
may
be
subject
to
unexpected
data
charges.
Whenever
an
application
makes
background
asynchronous
XHR
data
requests,
whether
automatic
or
user-initiated
if
it
is
(on
a
background
request
it
is
not
timer
or
in
response
to
an
external
trigger)
or
secondary
to
some
user
initiated,
surely?
,
action,
this
should
be
indicated
to
the
user
in
an
appropriate
manner.
Applications
should
disclose
how
they
use
network
resources.
A
simple
icon
indicating
background
activity
is
usually
sufficient
and
does
not
interrupt
the
flow
of
the
application.
If
extensive
background
network
activity
is
required
the
user
should
be
informed
when
they
first
visit
the
site,
when
they
first
log-in,
sign-in,
or
in
associated
help
pages.
The
kinds
of
detailed
information
that
could
be
disclosed
in
associated
help
pages
or
terms
of
service
are:
-
how
often
the
application
will
interact
with
the
Internet
-
e.g.
every
5
minutes,
hourly,
daily;
-
how
long
the
automatic
behavior
will
continue;
-
how
heavy
the
overall
usage
is
expected
to
be
or
the
type
of
service
plan
recommended.
If
an
application
makes
automatic
network
requests
(e.g.
to
poll
the
server
for
updates
or
to
automatically
store
an
updated
client
state)
a
means
to
control
this
activity
must
be
provided.
All
applications
that
access
the
network
automatically
must
provide
a
means
for
the
user
to
disable
automatic
network
that
activity.
When
automatic
network
activity
is
disabled,
periodically
prompt
the
user
to
make
network
requests.
Consider
allowing
the
user
to
adjust
the
polling
schedule
and
to
control
which
activities
are
allowed
to
initiate
network
requests.
Ensure
that
the
user
is
informed
if
the
application
needs
to
access
personal
or
device
information.
The
user
should
be
informed
of
the
types
of
information
that
will
be
used
by
the
application
and
how
that
data
will
be
exchanged
with
the
server.
In
many
cases
use
of
APIs
that
provide
access
to
personal
or
device
information
causes
a
confirmation
dialog
to
be
presented
to
the
user.
In
this
case
the
application
should
not
force
the
user
to
confirm
again
at
the
application
level,
but
should
make
clear
in
the
UI
that
displayed
data
has
been
accessed
from
the
device.
If
the
user
declines
a
prompt
to
allow
application
access
to
personal
or
device
information,
the
application
must
recover
gracefully.
For
example,
if
a
request
to
a
device
API
fails,
do
not
automatically
retry
if
this
will
lead
to
the
user
being
presented
with
repeated
native
confirmation
dialogues
by
the
underlying
API.
dialogues.
[
PIM
DATA
icon
]
Requires:
PIM
Data
APIs.
Resources,
such
as
device
memory,
processor
power,
and
network
bandwidth
are
significantly
more
limited
on
mobile
devices
than
on
the
desktop.
The
most
effective
way
to
ensure
that
applications
run
smoothly
and
with
low
latency
is
to
take
steps
to
ensure
minimal
use
of
resources.
Compress
content
for
efficient
delivery.
HTTP
1.1
compression,
which
uses
the
gzip
and
DEFLATE
algorithms
is
widely
supported.
Web
servers
should
be
configured
to
serve
appropriately
compressed
responses.
Note
however,
that
the
cost
(in
time
and
battery
usage)
of
decompressing
data
should
be
balanced
against
the
gains
in
transport
efficiency.When
efficiency.
When
configuring
HTTP
1.1
compression
note
that:
-
Most
binary
data
Do
we
actually
mean
images,
not
most
binary
data?
images
(especially
JPEGs)
does
not
benefit
from
compression;
-
For
very
small
files
(e.g.
<1k)
the
negative
impact
of
processing
will
outweigh
any
small
transport
gains.
3.4.1.3
Maximizing
Compression
Efficiency
Compression
of
HTML
and
CSS
files
can
be
made
more
efficient
by
ensuring
consistency
in
the
code.
I
remain
sceptical
about
this.
It's
all
going
to
be
in
lower
case
anyway,
if
it
is
valid
XHTML
and
ordering
of
attributes
etc
seems
a
bit
whimsical
to
me.
For
example:
Ensure
consistent
ordering
of
attributes
in
elements
(e.g.
alphabetize
them);
Use
consistent
casing
(e.g.
all
lowercase);
Use
consistent
quoting
(e.g.
always
use
single-quotes).
This
section
elaborates
on
the
Best
Practices
of
BP1
(
MINIMIZE
).
Smaller
applications
will
download
and
execute
more
quickly
and
more
reliably
than
larger
ones
on
constrained
devices.
Process
HTML,
JavaScript
and
CSS
files
to
remove
whitespace
and
minify
before
delivery.
A
number
of
open
source
whitespace
strippers
and
JavaScript
compilers
are
available.
The
working
group
is
seeking
recommendations
for
the
best
/
most-commonly
used
tools
to
reference
in
this
section.
Request
redirection
(through
HTTP
response
header
or
meta
refresh)
is
typically
used
to
exchange
information
between
servers
(e.g.
account
authentication).
The
delay
incurred
by
redirects
is
much
higher
over
mobile
networks
and
so
the
number
of
redirects
should
be
kept
to
a
minimum
to
avoid
degrading
the
user
experience.
Try
not
to
use
more
than
two
redirects
for
any
request.
If
further
redirects
are
required,
use
an
interstitial
page
to
communicate
to
the
user
that
the
application
is
still
working.
3.4.8.1
3.4.7.1
What
it
means
Web
applications
often
depend
on
a
number
of
static
images
to
provide
icons,
buttons,
etc.
If
served
as
a
separate
image
each
one
incurs
an
additional
HTTP
round-trip
which
is
detrimental
to
performance
when
compared
with
combining
them
into
a
single
image
for
transfer.
3.4.8.2
3.4.7.2
How
to
do
it
To
optimize
efficiency:
-
For
PNG
and
GIF
files,
combine
images
with
similar
sizes
and
color
palettes;
-
In
general,
avoid
sprites
for
JPEGs,
but
where
used,
align
images
Endeavour
to
sprite
JPEGs
on
8x8
boundaries;
Do
or
don't
do
it?
and
why
8x8
boundaries?
boundaries
in
order
to
minimize
the
size
of
the
combined
JPEG.
-
Combine
images
that
do
not
change
often,
since
if
often.
If
one
of
the
component
images
changes,
the
entire
combination
image
will
need
to
be
downloaded.
To
render
individual
components
of
a
resource
use
CSS
positioning
and
clipping.
[
ICON:
CSS
]
Requires:
CSS2
Clipping
and
Positioning
Support
3.4.9.1
3.4.8.1
What
it
means
Background
images
are
often
used
as
gradients
to
improve
the
look
and
feel
of
an
application.
These
can
be
included
in
the
CSS
as
base64
encoded
strings
in
order
to
avoid
an
additional
HTTP
round
trip
but
at
the
expense
of
trip.
Note
that
base64
encoding
adds
around
10%
to
the
loss
of
image
size
after
gzip
compression
that
base
64
implies,
so
what
is
and
this
additional
cost
should
be
weighed
against
the
trade-off?
.
benefits
of
less
requests.
3.4.9.2
3.4.8.2
How
to
do
it
Background
images
can
be
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.9.1.
What
it
means
Dynamic
resources
that
change
occasionally
(e.g.
a
user's
avatar)
can
still
be
cached
by
identifying
them
with
a
URI
that
includes
a
fingerprint
of
the
resource
content.
Using
this
technique
means
that
the
browser
does
not
need
to
check
the
resource
headers
in
order
to
validate
its
cache,
instead,
any
change
in
the
resource
will
lead
naturally
to
a
corresponding
change
in
the
resource
reference.
3.4.10.2
3.4.9.2
How
to
do
it
-
Set
the
resource
caching
policy
to
"never
expire"
by
setting
the
Expires
header
to
a
date
in
the
far
future.
-
Reference
the
resource
using
a
URI
that
contains
a
Hash
of
the
content.
If
the
content
changes,
this
reference
will
change
and
the
browser
will
fetch
the
updated
data.
3.4.11.1
3.4.10.1
What
it
means
Data
designed
to
be
accessed
by
AJAX
requests
from
the
client
should
be
cached
in
the
same
way
as
primary
content.
3.4.11.2
3.4.10.2
How
to
do
it
The
standard
caching
techniques
(
Expires
header
and
Cache-Control
header),
as
well
as
resource
fingerprinting
can
be
used
on
AJAX
data
as
readily
as
primary
content
pages.
A
Web
application
may
not
be
suspended
if
it
is
placed
in
background.
Consider
the
impact
of
on-going
JavaScript
operations
on
battery
life.
-
Network
activity
is
the
biggest
drain
on
power.
If
the
application
requires
ongoing
network
activity
(e.g.
to
poll
a
server
for
updates)
take
steps
to
inform
the
user
of
this
activity
and
minimize
its
impact
on
battery-life.
See
3.3.1
Inform
the
User
About
Automatic
Network
Access
;
-
DOM
manipulation
over
an
extended
period
impacts
device
battery
life
.
The
working
group
is
currently
investigating
the
relative
impacts
of
Web
application
activities
on
battery
life
in
order
to
make
more
concrete
recommendations.
[
AC:
I
propose
we
cut
this
BP
unless
we
can
say
something
more
concrete
or
empirically
supported.
I
don't
believe
this
BP
is
useful
in
its
current
form.
]
On
small
devices
with
limited
processing
capability,
the
cost
of
excessive
DOM
manipulation
can
impact
application
performance
.
Only
use
DOM
manipulation
for
dynamic
parts
of
the
page.
The
static
framework
of
the
page
is
best
created
using
HTML
markup
which
can
then
be
connected
to
the
script
using
the
element
ID
attribute.
[
AC:
I
agree
this
BP
is
currently
too
vague
to
be
useful
and
would
prefer
to
cut
it
or
come
up
with
something
more
concrete
to
say
]
3.4.14.1
3.4.13.1
What
it
means
Information
stored
in
cookies
is
exchanged
I'm
not
sure
it
is
actually
"exchanged"
...
sent,
certainly
(several
uses
of
"exchanged"
in
document)
between
sent
to
the
server
and
the
client
for
every
request,
which
request
and
can
negatively
impact
performance.
3.4.14.2
3.4.13.2
How
to
do
it
Use
cookies
sparingly,
and
consider
alternative
methods
(see
3.1
Personalization
Application
Data
)
for
anything
other
than
trivial
amounts
of
data.
).
3.4.15.1
3.4.14.1
What
it
means
Static
resources
don't
need
cookie
information
and
so
performance
can
be
improved
by
serving
these
from
a
path
or
sub-domain
for
which
the
application's
cookies
are
out
of
scope.
3.4.15.2
3.4.14.2
How
to
do
it
Use
a
different
domain,
sub-domain,
or
path
name
for
static
resources
to
the
main
application,
and
restrict
the
valid
path
of
cookies
such
that
they
will
not
be
exchanged
when
they
are
not
needed
(e.g.
??)
.
needed.
3.4.16
Use
JSON
for
Data
Feeds
3.4.16.1
What
it
means
For
example:
Asynchronous
data
can
be
delivered
to
the
client
in
response
to
an
XHR
request
in
any
form
(HTML
markup,
proprietary
format,
XML,
or
JSON
object
model).
Use
JSON
rather
than
XML
if
possible.
It
is
more
compact;
It
is
quicker
to
parse
since
it
can
be
directly
parsed
using
the
eval
method.
(but
which
we
are
saying
is
unsafe)
Set-Cookie:
somePreferenceInformation=purple;
path=/myapp/
3.4.16.2
How
to
do
it
Application
data
served
from
/myapp
will
receive
cookie
information.
JSON
Static
data
can
be
built
using
an
open
source
JSON
builder
(
REF
served
from
/static
).
On
the
client,
JSON
is
readily
parsed
into
a
JavaScript
object
model
using
the
eval
method.
Note,
however,
that
care
should
be
taken
to
observe:
3.2.2
Secure
JSON
Data
Feeds
and
3.2.3
Use
a
Safe
eval
for
JSON
Data
Feeds
.
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.
I
think
we
should
move
the
personalization
stuff
down
here
and
merge
it.
3.5.1.1
What
it
means
Interaction
methods
vary
across
different
devices.
Three
main
interaction
methods
should
be
considered:
considered
when
designing
the
UI:
-
Focus
Based:
The
browser
focus
"jumps"
from
link
to
link;
-
Pointer
Based:
Key-based
navigation
controls
a
pointer
that
can
cover
any
part
of
the
screen;
-
Touch
Based:
Events
are
related
directly
to
a
touch
position
on
the
screen
with
finger
or
stylus.
Devices
may
implement
one
or
more
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)
what
are
we
trying
to
say
here?
or
where
the
user's
interaction
with
links
is
designed
to
give
them
feedback
and
here?
,
the
following
factors
should
be
considered:
Focus
Based:
-
since
the
only
selectable
elements
are
links
...
Selectable
elements
(e.g.
links)
can
be
widely
spaced
as
since
the
user
can
select
them
easily
by
jumping
focus
area
will
jump
automatically
from
link
to
link;
-
The
current
location
focus
of
the
user
can
be
page
is
easily
determined
as
link
elements
because
that
element
will
be
in
focus.
highlighted.
Pointer
Based:
-
Selectable
elements
that
are
associated
need
to
be
near
each
other
as
scrolling
the
pointer
can
be
slow;
-
The
current
location
focus
of
the
user
can
be
page
is
easily
determined
as
link
because
that
elements
will
be
in
focus.
highlighted.
Touch
Based:
-
Selectable
elements
can
be
widely
spaced
as
the
user
can
select
them
easily;
directly;
-
Selectable
elements
must
be
large
enough
to
be
easily
selected
(e.g.
list
items
should
have
a
height
of
at
least
30px).
-
No
elements
are
in
focus
until
they
are
selected
so
extra
information
cannot
be
passed
to
the
user
(e.g.
rollovers
will
not
work).
Using
script
for
dynamic
parts
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.
AC:
My
feeling
is
that
this
BP
is
assumed
by
much
of
the
other
BPs,
is
too
obvious,
and
doesn't
provide
value.
Cut
of
change
to:
Avoid
Page
Reloads
The
JavaScript
focus
method
can
be
used
to
move
the
focus
to
the
part
of
a
page
that
has
changed.
However,
if
unexpected,
this
can
confuse
or
irritate
the
user,
especially
if
returning
to
the
previous
focus
is
not
easy.
Use
the
JavaScript
focus
method
only
if
it
is
essential
to
the
use
of
the
application,
and
does
not
inhibit
user
control/interaction.
3.5.4.1
What
it
means
Most
applications
consist
of
a
number
of
views
(e.g.
an
email
application
consists
of
an
inbox
and
the
message
detail
view).
User
experience
is
improved
if
switching
between
these
views
does
not
require
a
request
to
the
server.
3.5.4.2
How
to
do
it
Each
view
can
be
rendered
in
a
div
element
which
is
hidden
using
CSS.
JavaScript
can
be
used
to
reveal
content
in
response
to
user
events.
AC:
This
feels
like
the
wrong
level
of
detail.
Propose
merging
with
3.5.2
into
Avoid
Page
Reloads
3.5.5.1
What
it
means
Web
applications
can
show
multiple
switch
between
views
without
a
full
page
reload
by
showing
and
hiding
sections
of
content.
However,
this
means
that
the
browser
<back>
button
doesn't
work
by
default,
and
it
is
not
automatically
possible
to
link
directly
to
these
specific
views
and
the
browser
<back>
button
cannot
be
used
to
move
between
previous
views.
within
an
application.
Usability
is
enhanced
by
enabling
both
of
these
features:
-
Enabling
deep
links
(e.g.
to
the
content
of
a
specific
email)
means
the
user
can
still
bookmark
this
view
and
return
to
it
quickly;
-
Enabling
the
browser
history
provides
a
natural
method
to
navigate
application
views
that
is
natively
supported
by
the
browser.
3.5.5.2
How
to
do
it
Each
view
within
an
application
should
have
a
URI
with
a
distinguishing
fragment
identifier
(e.g.
http://myapp.example.org/myapp#view
)
and
JavaScript
used
to
interrogate
the
browser
location
in
order
to
determine
which
view
to
display.
Standardized
URI
schemes
have
been
defined
for
some
common
device
functions,
e.g.
making
phone
calls
and
managing
address
books.
These
URI
schemes,
if
supported,
can
enable
users
to
easily
use
these
functions
from
Web
applications.
The
most
broadly
supported
scheme
is
tel:
as
described
in
[
RFC3966
].
Code
such
as
the
following
can
be
used
to
enable
"Click-to-Call":
<a
href="tel:[PHONE-NUMBER]">[PHONE-NUMBER]</a>
3.5.7.1
What
it
means
On
small
screens
it
is
important
that
paragraph
text
flows
to
fill
all
the
available
space.
Fixed
paragraph
widths
(even
when
optimized
for
the
device
screen)
are
error
prone,
make
so
that
it
harder
to
support
multiple
device
formats,
and
will
not
support
multiple
orientations
(e.g.
landscape
doesn't
require
horizontal
scrolling
and
portrait
mode).
see
BP1
Measures
http://www.w3.org/TR/mobile-bp/#measures
in
fact,
in
what
way
is
this
different
to
so
that
BP?
And
btw,
ref
it
will
reflow
if
the
following,
note
that
px
view
orientation
is
not
an
absolute
measure
:-)
changed.
See
BP1
[MEASURES]
for
more
details.
3.5.7.2
How
to
do
it
Specify
widths
Use
percentage
and
measures
for
elements
containing
paragraph
containers
so
that
text
as
a
percentage
(
style="width:100%"
)
in
favour
of
using
an
absolute
size
(
style="width:660px"
)
since
use
of
the
style
attribute
is
"deprecated"
perhaps
these
examples
should
be
re-written
.
can
reflow
automatically.
3.5.8.1
What
it
means
Perceived
performance
can
be
improved
by
separating
out
JavaScript
functions
and
CSS
styles
that
are
not
required
by
the
initial
page.
JavaScript
functions
and
CSS
styles
associated
with
rarely
used
features
should
be
bundled
separately
and
downloaded
only
if
those
features
are
accessed.
3.5.8.2
How
to
do
it
Consider
what
functionality
is
being
downloaded
in
a
given
script
resource
and
how
likely
that
functionality
is
to
be
used
in
the
majority
of
requests.
If
some
functionality
is
rarely
used,
it
may
make
sense
to
partition
this
into
a
separate
script
to
be
loaded
on
demand.
On-demand
loading
can
be
accomplished
by:
-
Moving
that
functionality
onto
an
entirely
separate
page;
-
Creating
an
embedded
frame
to
load
the
required
additional
resources
in
response
to
a
page
event;
-
Using
<link
rel="prefetch">
.
The
working
group
is
seeking
feedback
on
this
Best
Practice.
Whilst
it
contains
value
for
very
large
/
complex
applications,
the
implementation
of
this
technique
and
its
support
across
even
high-end
devices
is
not
clear.
Specifically,
IFRAMEs
are
known
to
have
significant
issues
on
many
devices
and
so
we
are
looking
for
validation
that
their
use
in
this
context
is
a
good
idea.
3.5.9.1
What
it
means
Progressive
rendering
means
that
the
page
will
be
displayed
incrementally
as
it
loads.
In
most
cases
this
results
in
an
improved
perceived
latency
since
content
is
available
earlier.
3.5.9.2
How
to
do
it
Place
CSS
style
sheet
(
<style>
)
elements
in
the
<head>
head
element
at
the
top
of
the
document
and
JavaScript
(
<script>
)
elements
at
the
bottom
of
the
document.
Browsers
will
not
progressively
render
a
page
until
the
stylesheet
has
been
loaded
and
will
block
while
JavaScript
content
is
parsed.
3.5.10.1
What
it
means
This
recommendation
builds
on
the
recommendation
in
BP1
(
5.5.1
Thematic
Consistency
)
and
expands
it
to
consider
the
application
preferences
and
personalization
data
that
form
part
of
the
overall
experience
on
a
mobile
Web
application.
User
credentials
valid
on
one
device
should
be
valid
on
other
devices.
User
preferences
captured
on
one
device
should
be
accessible
on
other
devices.
The
most
valuable
example
of
this
would
be
in
offering
a
consistent
experience
where
information
entered
during
a
desktop
session
is
accessible
in
a
mobile
session
and
vice-versa.
3.5.10.2
How
to
do
it
For
application
data
to
be
shared
between
devices
it
must
be
stored
on
a
server
and
cannot
be
stored
locally
on
a
device
(e.g.
using
cookies
or
a
local
data
store).
For
any
application
data
that
is
not
exclusively
relevant
to
the
current
device,
favor
storing
it
on
the
server
so
it
can
be
shared
by
other
devices.
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:
TODO:
Pending
Jeff's
research
:)
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.
"As
well
as
possible?"
Optimum
is
an
absolute.
I
think
the
headline
message
here
is
something
like
"take
account
of
device
variation"
For
static
device
capabilities
that
won't
change
(e.g.
SVG
support,
screen-dimensions)
it
is
preferable
to
detect
these
capabilities
on
the
server
and
adapt
content
before
it
is
sent
to
the
client
in
order
to
avoid
transferring
unnecessary
data.
Typically
used
methods
of
device
capabilities
detection:
-
The
"User-Agent"
header
can
be
used
to
identify
the
device,
and
a
Device
Description
Repository
(DDR)
can
be
used
to
retrieve
a
detailed
description
of
capabilities;
-
The
"Accept"
header
can
be
used
to
indicate
specific
MIME
types
compatible-to/preferred-by
the
device;
-
The
"X-Wap-Profile"
header
(User
Agent
Profile
or
UAProf)
can
be
used
both
as
device
identification
and
as
a
source
of
detailed
device
capabilities.
For
dynamic
device
state
that
might
depend
on
the
configuration
or
context
of
the
device
(e.g.
Is
scripting
enabled?
Is
the
SDCard
available?
Has
permission
been
granted
for
PIM
access?)
detection
must
be
done
on
the
device.
Use
JavaScript
reflection
to
determine
if
a
given
API
is
active
and
interrogate
the
device
configuration
using
appropriate
APIs.
Two
methods
can
then
be
used
to
adapt
on
the
client
to
differing
configurations:
-
Encapsulate
the
different
behaviours
in
the
control
logic
of
the
application.
E.g.
simply
use:
if
(some_configuration_variable)
decision-points
in
the
code
and
behave
accordingly;
-
Use
an
initial
"bootstrap"
script
to
assess
device
capabilities
and
request
the
appropriate
application
bundle
accordingly.
Option
(1)
is
simpler
to
implement
and
is
appropriate
provided
the
amount
of
inactive
code
downloaded
doesn't
have
a
negative
impact
on
performance.
Option
(2)
is
preferred
when
the
application
must
change
significantly
in
response
to
properties
that
can
only
be
determined
on
the
client.
If
a
large
number
of
devices
are
being
targeted,
or
the
application
is
sensitive
to
the
permutations
of
a
large
number
of
configuration
properties,
the
number
of
application
variants
required
might
quickly
become
unmanageable.
To
combat
this,
classify
target
devices
into
different
"buckets"
device
classes
and
build
a
single
application
variant
for
each
device
bucket.
I
wonder
if
we
can
use
a
differnt
term
to
"bucket"
and
wonder
how
comprehensible
it
is
to
international
audiences
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
configuration
of
application
buckets:
classes:
Bucket
Class
1:
Basic
XHTML
support,
no
or
very
basic
scripting.
No
AJAX
support.
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
browsers.
If
possible,
provide
a
variant
of
the
application
that
does
not
rely
on
script
by
using
synchronous
FORM
posts
instead.
might
be
worth
having
This
Best
Pratice
is
related
(albeit
with
a
note
here
on
mobileOK
Basic
Tests
and
its
relationship
differing
focus)
to
this
best
practice
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.
Doing
this
will
ensure
that
the
application
can
be
used
across
as
broad
a
range
of
devices
as
possible.
Furthermore,
in
some
cases
a
non-JavaScript
version
can
sometimes
be
useful
for
simple
operations
in
low-bandwidth
situations.
In
some
cases,
however,
the
type
of
application
simply
has
no
non-JavaScript
counterpart
(e.g.
a
Web
based
game,
an
Instant
Messaging
client)
in
which
case
it
should
return
a
406
Not
Acceptable
response.
Do
this
by
detecting
the
device
User-Agent
and
checking
its
JavaScript
support
against
a
DDR
or
local
index.
surely
it's
usually
the
case
that
allowing
the
user
to
select
among
available
interfaces
is
the
right
thing
to
do?
The
emphasis
on
the
imperfactions
of
device
detection
is
mis-stated
I
think
compared
with
the
importance
of
meeting
the
user's
contextual
needs
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
data
store.
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
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.
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.
[To
include
the
set
of
minimum
The
following
device
properties
included
in
the
DDR
Core
Vocabulary
[REF]
are
of
particular
value
in
supporting
specific
best
practices.]
practices
recommended
in
this
document.
They
should
be
available
in
any
DDR
supporting
the
W3C's
DDR
Core
Vocabulary:
-
Display
Width,
Display
Height,
Display
Color
Depth
-
Input
Devices
-
Markup
Support
-
Stylesheet
Support
-
Image
Format
Support
-
Input
Mode
Support
-
Cookie
Support
-
Script
Support
TODO:
Include
more
detailed
examples
on
the
following
BPs...
Use
Fragment
IDs
The
Best
Practice
statements
have
been
assembled
by
the
BPWG
from
a
number
of
sources.
Primary
among
those
are:
While
the
Best
Practice
statements
have
mainly
been
assembled
by
secondary
research,
the
sources
for
that
research
have
in
many
cases
been
assembled
from
primary
research.
In
addition,
group
members'
contributions
are
to
some
extent
informed
by
primary
research
carried
out
by
their
company.
Readers
interested
in
the
topic
of
this
document
will
find
a
variety
of
other
publications
of
interest.
As
noted
in
the
Scope
paragraph
above,
topics
such
as
internationalization
and
accessibility
have
been
addressed
separately
by
the
W3C
and
have
not
been
covered
here.
The
Character
Model
for
the
World
Wide
Web
and
other
materials
prepared
by
the
W3C
Internationalization
(i18n)
Activity
cover
important
interoperability
drivers
for
content
prepared
for
the
One
Web
and
the
mobile-services
arena.
The
Web
Accessibility
Initiative
has
prepared
a
variety
of
Guidelines
and
Techniques
that
likewise
bear
on
the
preparation
and
processing
of
content
in
and
for
the
Web.
Section
3.6.3
Use
Device
Classification
to
Simplify
Content
Adaptation
above
introduced
the
idea
of
content
adaptation.
Readers
who
contemplate
implementing
server-side
adaptation
will
be
interested
in
the
ongoing
work
of
the
Device
Independence
Activity
.
to
be
added
to
be
added
-
DIP
-
Device
Independence
Principles,
R.
Gimson,
Editor,
W3C
Working
Group
Note,
1
September
2003
(See
http://www.w3.org/TR/2003/NOTE-di-princ-20030901/
)
-
DCODI
-
Delivery
Context
Overview
for
Device
Independence,
,
R.
Gimson,
R.
Lewis,
S.
Sathish,
Editors,
W3C
Working
Group
Note,
20
March
2006
(See
http://www.w3.org/TR/di-dco/
)
-
DIGLOSS
-
Glossary
of
Terms
for
Device
Independence,
R.
Lewis,
Editor,
W3C
Working
Draft
(work
in
progress),
18
January
2005
(See
http://www.w3.org/TR/2005/WD-di-gloss-20050118/
)
-
XML
-
Extensible
Markup
Language
(XML)
1.0
(Fifth
Edition),
Tim
Bray,
Jean
Paoli,
C.
M.
Sperberg-McQueen,
Eve
Maler,
François
Yergeau,
Editors,
W3C
Recommendation,
26
November
2008
(See
http://www.w3.org/TR/2008/REC-xml-20081126/
)
XHTML-Basic
XHTML
Basic
1.1,
Shane
McCarron,
Masayasu
Ishikawa,
Editors,
W3C
Recommendation,
29
July
2008
(See
http://www.w3.org/TR/2008/REC-xhtml-basic-20080729/
)
CSS
Cascading
Style
Sheets
(CSS1)
Level
1
Specification,
Håkon
Wium
Lie,
Bert
Bos,
Editors,
W3C
Recommendation,
11
January
1999,
revised
11
April
2008
(See
http://www.w3.org/TR/2008/REC-CSS1-20080411/
)
CSS2
Cascading
Style
Sheets,
level
2
CSS2
Specification,
Bert
Bos,
Håkon
Wium
Lie,
Chris
Lilley,
Ian
Jacobs,
Editors,
W3C
Recommendation,
12
May
1998,
revised
11
April
2008
(See
http://www.w3.org/TR/2008/REC-CSS2-20080411/
)
HTTP1.0
Hypertext
Transfer
Protocol
--
HTTP/1.0
Request
for
Comments:
1945,
T.
Berners-Lee,
R.
Fielding,
H.
Frystyk,
May
1996
(See
http://www.w3.org/Protocols/rfc1945/rfc1945
)
HTTP1.1
Hypertext
Transfer
Protocol
--
HTTP/1.1
Request
for
Comments:
2616,
R.
Fielding,
J.
Gettys,
J.
Mogul,
H.
Frystyk,
L.
Masinter,
P.
Leach,
T.
Berners-Lee,
June
1999
(See
http://www.w3.org/Protocols/rfc2616/rfc2616.html
)
D.5
Other
References
UAPROF
Open
Mobile
Alliance
OMA-TS-UAProf-V2_0-20060206-A
User
Agent
Profile
Approved
Version
2.0
06
Feb
2006
(See
http://www.openmobilealliance.org/technical/release_program/docs/UAProf/V2_0-20060206-A/OMA-TS-UAProf-V2_0-20060206-A.pdf
)
WTAI
WAP
Forum
wap-268-wtai-20010908-a
Wireless
Telephony
Application
Interface
Specification
(See
http://www.openmobilealliance.org/tech/affiliates/LicenseAgreement.asp?DocName=/wap/wap-268-wtai-20010908-a.pdf
)
RFC
3966
The
tel
URI
for
Telephone
Numbers,
H.
Schulzrinne.
IETF,
December
2004
(See
http://www.ietf.org/rfc/rfc3966.txt)
RFC
2119
Key
words
for
use
in
RFCs
to
Indicate
Requirement
Levels,
S.
Bradner.
IETF,
March
1997
(See
http://ietf.org/rfc/rfc2119)
Fran