- Latest version
- http://www.w3.org/Mobile/mobile-web-app-state/
- This version
-
http://www.w3.org/2011/05/mobile-web-app-statehttp://www.w3.org/2011/08/mobile-web-app-state - Previous version
-
http://www.w3.org/2011/02/mobile-web-app-statehttp://www.w3.org/2011/05/mobile-web-app-state
Web technologies have become powerful enough that they are used to build full-featured applications; this has been true for many years in the desktop and laptop computer realm, but is increasingly so on mobile devices as well.
This
document
summarizes
the
various
technologies
developed
in
W3C
that
increases
increase
the
power
of
Web
applications,
and
how
they
apply
more
specifically
to
the
mobile
context,
as
of
May
2011.
context.
Status and changes
This
document
is
the
second
third
version
of
this
overview
of
mobile
Web
applications
technologies.
A
previous
version
was
Previous
versions
were
released
in
February
2011
and
May
2011
,
and
a
live
version
of
this
document
accepts
contributions
in
the
W3C
Wiki
.
Feedback
on
every
aspect
of
this
document
should
be
sent
to
the
author
(dom@w3.org)
(
dom@w3.org
)
and
will
serve
as
input
for
the
next
iteration
of
the
document.
Since the previous release of this document, the following evolution of the Web platform occurred and have been reflected in this document :
-
The Web Audio Working GroupAddition of a new section on technologies useful for device adaptationand -
Addition
of
the
Web Real-Time Communications Working Groupnew W3C Community Groupswere charteredas a way to start standardization workrespectively on improving audio processing capabilities (seein W3C -
Four
new
APIs
from
the
multimedia sectionWeb Performance Working Group : Performance Timeline , User Timing , Efficient Script Yielding) and on enabling peer-to-peer audioandvideo communications (see the multimediaTiming control for script-based animationsand communication section .) - The first editor draft of Web Real-Time Communication
-
A
number
of
other
documents
made
progress
on
the
Recommendation
track, includingtrack ( WOFF , Contacts API , DeviceOrientation Event , Network Information API , theHTML5 specification which has reached Last Call Working Draft status .family of Widgets specifications) -
The proposed new charterAddition of theDevice APIs Working Group includes newproposed workitems around vibration, system beeps (see theon model-based userinteractions sectioninterfaces), and audio volume reading (see multimedia section .) -
Two new draft specifications fromUpdates based on theDevice APIs Working Group replaces partadoption ofwhat the likely abandoned Systems Information API covered:theBattery Status Event specification (see hardware integration ) and the Network Information API (see network section .) anewAPI from the Web PerformanceDevice APIs Working Group, Resource Timingcharterallows to get more data on time required to load included resources in a Web page; proposed work around a page visibility API aims also to optimize the usage of resources depending on the current visibility of a Web application (see performance & optimization .)
Document structure
The features that these technologies add to the Web platform are organized under the following categories:
- Graphics
- Multimedia
- Device Adaptation
- Forms
- User interactions
- Data storage
- Personal Information Management
- Sensors and hardware integration
- Network
- Communication
- Packaging
- Performance & Optimization
The
Web
as
an
application
development
platform
In each category, a table summarizes for each feature:
- which W3C specification defines the feature,
- which W3C group is responsible of the said specification,
-
the
level of maturitystage of the specification in the W3C Recommendation track (see below), - the estimated stability of the document, i.e. how widely the document is expected to change, as estimated by the author of this report, with three levels: low (the document is mostly stable), medium (some parts are stable, others are expected to change significantly), high (the document is expected to evolve significantly),
-
some
rough
qualitative
indication
on
availability
of
implementations
on
mobile
devices — a more thorough analysis will be include in a new version of this document,devices, - a link to the latest editors draft of the document,
- a link to the test suite for the said feature.
As a reminder, W3C creates Web standards by progressing documents through its Recommendation track , with the following stages:
-
Editors drafts“Editors drafts” represent the current view of the editors of the specification but have no standing in terms of standardization. -
Working Drafts“Working Drafts” are early milestones of the Working Group progress. -
Last“Last Call WorkingDraftsDrafts” signal that the Working Group has determined that the specification fulfills its requirements and all the known issues have been resolved, and thus requests feedback from the larger community. -
Candidate Recommendations“Candidate Recommendations” trigger a call for implementations where implementers are invited to implement the specification and send feedback; Working Groups are expected to show the specification gets implemented by running test suites they have developed. -
Proposed Recommendations“Proposed Recommendations” manifests that the group has gathered sufficient implementation experience, and triggers the final review by W3C Members -
W3C Recommendations“W3C Recommendations” are stable and completed Web standards; these documents only get updated rarely, through theEdited Recommendation“Edited Recommendation” process, as a results from errata collected by Working Groups.
Prior
to
starting
this
standardization,
a
Working
Group
needs
to
be
chartered,
based
on
input
from
W3C
Members,
often
through
the
organization
of
a
workshop
,
or
after
the
reception
of
a
W3C
Member
Submission
.
W3C
has
recently
set
up
Community
Groups
,
or
as
a
follow-up
new
mechanism
that
allows
anyone
to
do
experimental
work
within
the
W3C
infrastructure,
under
IPR
rules
that
are
compatible
to
transition
the
work
of
a
to
the
W3C
Incubator
Group
.
standardization
process.
Graphics
SVG
,
Scalable
Vector
Graphics,
provides
an
XML-based
markup
language
to
describe
two-dimensions
vectorial
vector
graphics.
Since
these
graphics
are
described
as
a
set
of
geometric
shapes,
they
can
be
zoomed
at
the
user
request,
which
makes
them
well-suited
to
create
graphics
on
mobile
devices
where
screen
space
is
limited.
They
can
also
be
easily
animated,
enabling
the
creation
of
very
advanced
and
slick
user
interfaces.
The integration of SVG in HTML5 opens up new possibilities, for instance applying advanced graphic filters (through SVG filters) to multimedia content, including videos.
In
complement
to
the
declarative
approach
provided
by
SVG,
the
<canvas>
element
added
in
HTML5
enables
a
2D
programmatic
API
that
is
well-suited
for
processing
graphics
in
a
less
memory
intensive
way.
That
API
not
only
allows
to
render
graphics,
but
can
also
serve
as
a
way
be
used
to
make
do
image
processing
and
analysis.
Both SVG and HTML can be styled using CSS (Cascading Style Sheets); in particular, CSS3 (the third level of the specification) is built as a collection of specifications set to offer a large number of new features that make it simple to create graphical effects, such as rounded corners, complex background images, shadow effects ( CSS Backgrounds and Borders ), rotated content ( CSS 2D Transforms ), animations ( CSS Animations , CSS Transitions ), and even 3D effects ( CSS 3D Transforms ).
The
cascading
model
of
CSS
is
completed
with
Animations
can
be
resource
intensive
—
the
possibility
of
customizing
the
applied
rules
to
the
characteristics
of
offered
by
the
device
through
CSS
Media
Queries
Timing
control
for
script-based
animations
API
,
a
mechanism
particularly
useful
on
mobile
devices
to
cater
for
manage
the
variation
among
screen
sizes.
rate
of
updates
to
animations
can
help
keep
them
under
control.
Fonts play also an important role in building appealing graphical interfaces, but mobile devices are in general distributed with only a limited set of fonts. WOFF ( Web Open Font Format ) addresses that limitation by making it easy to use fonts that are automatically downloaded through style sheets, while keeping the size of the downloaded fonts limited to what is actually needed to render the interface.
NB: work on defining a 3D graphic API called WebGL has started outside of W3C, as part of the Khronos Group ; this API has been built to be compatible with OpenGL ES , i.e. for embedded systems, and is intended to work on mobile devices.
Feature | Specification | Working Group | Maturity | Stability | Latest editors draft | Current implementations | Test suite |
---|---|---|---|---|---|---|---|
2D Vector Graphics | SVG Tiny 1.2 | SVG Working Group | Standard | Finished | New version of SVG (SVG 2.0) in preparation | Widely deployed (iOS, BlackBerry, WebKit on Nokia, webOS, Opera, Firefox, announced for Android, announced for Windows Phone) | High coverage |
2D Programmatic API | HTML Canvas 2D Context | HTML Working Group | Last Call Working Draft | Mostly stable | Updated regularly | Widely deployed (iOS, BlackBerry, Android, webOS, Opera, Firefox, announced for Windows Phone) | Good coverage |
Rounded Corners | CSS Backgrounds and Borders | CSS Working Group | Candidate Recommendation | Mostly finished | Updated regularly | Deployed as an extension in many mobile browsers | None |
Complex background images | Limited (?) | ||||||
Box shadow effects | Limited (?) | ||||||
CSS 2D Transforms | CSS 2D Transforms Module Level 3 | Working Draft | Stabilizing | Last update May 2010 | Limited (?) | None | |
3D Effects |
CSS
|
Working Draft | First draft |
|
|
None | |
Animations |
CSS
|
Working Draft |
|
|
Limited (?) | None | |
CSS
|
Working Draft |
|
Last
update
|
|
None | ||
|
Web Performance Working Group | Working Draft | Early |
|
None | None | |
Downloadable fonts | WOFF File Format 1.0 | WebFonts Working Group | Candidate Recommendation |
|
Last
update
|
Good deployment | Good coverage |
Multimedia
HTML5
adds
two
tags
that
improves
dramatically
improve
the
integration
of
multimedia
content
on
the
Web:
the
<video>
and
<audio>
tags.
These
Respectively,
these
tags
allows
to
embed
respectively
video
and
audio
content,
and
make
it
possible
for
Web
developers
to
interact
much
more
freely
with
that
content
than
they
would
through
plug-ins.
They
make
multimedia
content
first-class
citizens
of
the
Web,
the
same
way
images
have
been
for
the
past
15
years.
While
these
tags
allow
to
play
multimedia
content,
the
HTML
Media
Capture
and
the
Media
Capture
API
define
mechanisms
to
capture
and
record
multimedia
content
using
attached
camera
and
microphones,
a
very
common
feature
on
mobile
devices.
The
newly
chartered
Web
Real-Time
Communications
Working
Group
will
also
provide
an
API
to
manipulate
directly
manipulate
streams
from
camera
and
microphones
.
Beyond recording, two additional APIs add multimedia manipulation capabilities to the Web platform. We have already mentioned the Canvas 2D Context API: it enables modifying images, which in turn opens up the possibility of video editing . In a similar vein, a W3C Incubator Group has been working on an Audio API ( Mozilla’s proposal draft ) that makes it possible to modify audio content, as well as analyze and synthesize sounds — this work serves as a basis to the newly chartered Audio Working Group .
Finally,
a
proposed
addition
to
the
draft
new
charter
of
the
Device
APIs
Working
Group
offers
to
provide
includes
an
API
for
reading
the
current
audio
volume
of
a
device,
allowing
to
adapt
the
type
of
interactions
with
the
user
depending
on
that
setting.
The combination of all these features mark the starting point of the Web as a comprehensive platform for multimedia, both for consuming and producing. The rising interest around bridging the Web and TV worlds (manifested through the W3C Web and TV Interest Group ) should strengthen that trend in the coming months. Mobile devices are expected to take a growing role in many users TV experience, providing a “second screen” experience, where users can find more information on or interact with a TV program they're watching via their mobile devices.
Feature | Specification | Working Group | Maturity | Stability | Latest editors draft | Current implementations | Test suite |
---|---|---|---|---|---|---|---|
Video
|
HTML5
video
element
|
HTML Working Group | Last Call Working Draft | Stabilizing | Updated regularly |
|
Just started |
Audio
|
HTML5
audio
element
|
Barely started | |||||
Capturing audio/video | HTML Media Capture |
Device
APIs
|
Working Draft | Early draft | Last update Apr 2011 | Very limited | None |
The Media Capture API | Working Draft | Early Draft | Last update Dec 2010 | None (?) | None | ||
|
|
N/A | None |
|
A few experimental ones | None | |
Image & Video analysis, modification | HTML Canvas 2D Context | HTML Working Group | Last Call Working Draft | Mostly stable | Updated regularly | Widely deployed (iOS, BlackBerry, Android, webOS, Opera, Firefox, announced for Windows Phone) | Good coverage |
Audio analysis, modification | None | Audio Working Group | N/A | Not started | Mozilla Data Audio API , Google Web Audio API | None | None |
Audio volume reading | N/A |
|
N/A | Not started | N/A | None | None |
Device Adaptation
Mobile devices not only differ widely from traditional computers, but they also have a lot of variations among themselves, in term of screen size, resolution, type of keyboard, media recording capabilities, etc.
The Device Description Repository API is a unified server-side API that allows Web developers to retrieve data on the devices that are accessing their pages on a variety of device information database.
A client-side equivalent has been proposed as part of the Systems Information API ; while that specification is being vastly revisited, the Device APIs Working Group expects to do further work on a device information API.
To take advantage of the large variety of media capturing devices provided on mobile phones, the The Media Capture API offers some detailed indication on the features and capabilities these devices.
CSS Media Queries offer a mechanism that allows to adapt the layout and behavior of a Web page based on some of the characteristics of the device, including the screen resolution.
Feature | Specification | Working Group | Maturity | Stability | Latest editors draft | Current implementations | Test suite |
---|---|---|---|---|---|---|---|
Device information | Device Description Repository Simple API | Device Description Working Group (now closed) | Recommendation | finished | N/A | Limited | Good Coverage |
Systems Information API | Device APIs Working Group | Working Draft | Likely to be vastly reworked | Last update March 2011 | N/A | N/A | |
Media Capture API | Device APIs Working Group | Working Draft | Likely to be vastly reworked | Last update December 2010 | N/A | N/A | |
CSS-based adaptation | Media Queries | CSS Working Group | Candidate Recommendation | Mostly finished | Last update August 2010 | Widely deployed | Good coverage |
Forms
The
ability
to
build
rich
forms
with
HTML
is
the
basis
for
user
input
in
most
Web-based
applications.
Due
to
their
limited
keyboards,
text
input
on
mobile
devices
remains
a
difficult
task
for
most
users;
HTML5
address
parts
of
this
problem
with
by
offering
new
type
of
form
controls
that
optimizes
optimize
the
way
users
will
enter
data:
-
date
and
time
entries
can
take
advantage
of
a
number
of
dedicated
form
controls
(e.g.
<input type="date">
) where the user can use a native calendar control; -
the
<input type=" email ">
,<input type=" tel ">
and<input type=" url ">
can be used to optimize the ways user enter these often-difficult to type data, e.g. through dedicated virtual keyboards, or by accessing on-device records for these data (from theaddressbook,address book, bookmarks, etc.); -
the
pattern
attribute allows both to guide user input as well as to avoid server-side validation (which requires a network round-trip) or JavaScript-based validation (which takes up more resources); -
the
placeholder
attribute allows to guide user input by inserting hints as to what type of content is expected in a text-entry control; -
the
new
<datalist>
element allows to create free-text input controls coming with pre-defined values the user can select from.
Feature | Specification | Working Group | Maturity | Stability | Latest editors draft | Current implementations | Test suite |
---|---|---|---|---|---|---|---|
Date and time entries |
HTML5
Date
and
Time
state
of
input
element
|
HTML Working Group | Last Call Working Draft | Stabilizing | Updated regularly | Limited | None |
Customized
text
entries
(
tel
,
email
,
url
)
|
HTML5
telephone,
email
and
URL
state
of
input
element
|
Stabilizing | Updated regularly | Limited (?) | None | ||
Input pattern |
HTML5
pattern
attribute
|
Stabilizing | Updated regularly | Very limited (?) | None | ||
Input hint |
HTML5
placeholder
attribute
|
Stabilizing | Updated regularly | Limited (?) | None | ||
Pre-defined values for text entries |
HTML5
datalist
element
|
Stabilizing | Updated regularly | Very limited (?) | None |
User interactions
An
increasing
share
of
mobile
devices
rely
relies
on
touch-based
interactions.
While
the
traditional
interactions
recognized
in
the
Web
platform
(keyboard,
mouse
input)
can
still
be
applied
in
this
context,
a
more
specific
handling
of
touch-based
input
is
a
critical
aspect
of
creating
well-adapted
user
experiences.
As
a
result,
work
has
started
on
defining
Touch
Events
in
the
DOM
(Document
Object
Model).
Conversely,
many
mobile
devices
use
haptic
feedback
(such
as
vibration)
to
create
new
form
of
interactions
(e.g.
in
games);
work
on
a
vibration
API
is
under
consideration
in
the
Device
APIs
&
Policy
Working
Group
(proposed
(a
recent
addition
to
in
the
draft
new
charter
of
the
group
.)
But
as
the
Web
reaches
new
devices,
and
as
devices
gain
new
user
interactions
mechanisms,
it
also
becomes
important
to
allow
Web
developers
to
react
to
a
more
abstract
set
of
user
interactions:
instead
of
having
to
work
in
terms
of
“click”,
“key
press”,
or
“touch
event”,
being
able
to
react
to
an
“undo”
command,
or
a
“next
page”
command
however
independently
of
how
the
user
communicated
instructed
it
to
the
device
will
prove
beneficial
to
the
development
of
device-independent
Web
applications.
Work
on
abstract
DOM
events
that
would
address
this
need
is
planned
as
part
of
the
Web
Events
Working
Group
.
Mobile
devices
follow
their
users
everywhere,
and
many
mobile
users
rely
on
them
to
remind
them
or
notify
them:
them
of
events,
such
as
messages:
the
Web
Notifications
specification
proposes
to
add
that
feature
to
the
Web
environment.
Similarly,
the
proposed
addition
to
in
the
draft
new
charter
of
the
Device
APIs
&
Policy
Working
Group
of
an
API
to
generate
system
beeps
(rather
than
app-provided
sounds)
would
facilitate
the
integration
of
the
underlying
system
mechanisms
to
notify
the
user.
Mobile devices, and mobile phones in particular, are also in many cases well-suited to be used through voice-interactions; the HTML Speech Incubator Group is exploring the opportunity of starting standardization work around a framework that would make it possible for users to interact with a Web page through spoken commands (see their use cases and requirements .)
Feature | Specification | Working Group | Maturity | Stability | Latest editors draft | Current implementations | Test suite |
---|---|---|---|---|---|---|---|
Touch-based interactions | Touch Events Specification | Web Events Working Group | Working Draft | Early draft | Updated regularly | Growing deployment | None |
Vibration | N/A |
Device
API
|
N/A | Not started | Not started | None | None |
Intent-based events | N/A | Web Events Working Group | N/A | Not started | Not started | None | None |
Notification | Web Notifications | Web Notifications Working Group | Working Draft | Early draft | Regularly updated | None | None |
System beeps | N/A |
Device
API
|
N/A | Not started | Not started | None | None |
Speech-based interactions | N/A | HTML Speech Incubator Group , planning to request creation of standards-track work | N/A | N/A | Use cases and requirements | N/A | N/A |
Model-based user interfaces | N/A | Proposed Model-Based User Interfaces Working Group | N/A | N/A | Model-based UI Incubator Group report | N/A | N/A |
Data storage
A
critical
component
of
many
applications
reside
in
is
the
ability
to
save
state,
export
content,
as
well
as
integrate
data
from
other
files
and
services
on
the
system.
For
simple
data
storage,
the
Web
Storage
specification
offers
two
basic
mechanisms,
localStorage
and
sessionStorage
,
that
can
preserve
data
respectively
indefinitely,
or
on
a
browser-session
basis.
For richer interactions, the Web platform has a growing number of APIs to interact with a device filesystem: the File Reader API makes it possible to load the content of a file, the File Writer API allows to save or modify a file, while the nascent FileSystems API give access to more general file operations, including directory management.
On
top
of
this
file-based
access,
the
Indexed
Database
API
defines
a
database
of
values
and
hierarchical
objects
that
integrates
naturally
with
JavaScript,
and
can
be
queried
and
updated
very
efficiently.
Note
that
the
work
around
a
client-side
SQL-based
database
database,
which
had
been
started
in
2009
2009,
has
been
abandoned
in
favor
of
this
new
system.
Feature | Specification | Working Group | Maturity | Stability | Latest editors draft | Current implementations | Test suite |
---|---|---|---|---|---|---|---|
Simple data storage | Web Storage | Web Applications Working Group | Working Draft | Stabilizing | Updated regularly | Well deployed | None |
File reading | File API | Web Applications Working Group | Working Draft | Stabilizing toward LC | Regular updates | Limited (?) | None |
File writing | File API: Writer | Web Applications Working Group | Working Draft | Early draft (but starting to stabilize) |
Last
update
|
Limited (?) | None |
Filesystems operations | File API: Directories and System | Web Applications Working Group | Working Draft | Early draft |
Last
update
|
None | None |
Database query/update | Indexed Database API | Web Applications Working Group | Working Draft | Still changing, but starting to stabilize |
|
Very limited (?) | None |
Web SQL API | Working Group Note | Abandoned | N/A | Limited | N/A |
Personal Information Management
Applications
can
benefit
from
integrating
with
existing
data
records;
on
mobile
devices,
the
addressbook
address
book
and
calendar
are
particularly
useful
source
of
information,
which
the
Contacts
API
and
the
Calendar
API
bring
access
to.
Feature | Specification | Working Group | Maturity | Stability | Latest editors draft | Current implementations | Test suite |
---|---|---|---|---|---|---|---|
|
Contacts API |
Device
APIs
|
Last Call Working Draft | Stabilizing | Regularly updated | Very limited | early draft |
Calendar data | Calendar API |
Device
APIs
|
Working Draft | Still changing | Regularly updated | Very limited | None |
Sensors and hardware integration
Mobile devices are packed with sensors, making them a great bridge between the real and virtual worlds: GPS, accelerometer, ambient light detector, microphone, camera, thermometer, etc.
To take full advantage of these sensors in mobile Web applications, Web developers need to be provided with hooks to interact with them.
The Geolocation API provides a common interface for locating the device, independently of the underlying technology (GPS, WIFI networks identification, triangulation in cellular networks, etc.)
Work has also started on providing access to orientation and acceleration data via the DeviceOrientation Event Specification .
The System Information API proposes a generic API to get and monitor data from sensors, although the Working Group producing it is evaluating whether that generic approach is the most practical way forward.
As
already
mentioned
in
the
section
on
multimedia
Multimedia
,
there
is
ongoing
work
on
APIs
to
open
up
access
to
camera
and
microphone
streams.
Feature | Specification | Working Group | Maturity | Stability | Latest editors draft | Current implementations | Test suite |
---|---|---|---|---|---|---|---|
Geolocation | Geolocation API | Geolocation Working Group | Candidate Recommendation | Mostly finished | Regularly updated | Widely deployed | Good coverage |
Accelerometer / Orientation |
DeviceOrientation
Event
Specification
|
Geolocation Working Group |
|
|
Regularly updated |
|
None |
Battery Status | Battery Status Event |
Device
APIs
|
Working Draft | Stabilizing | Updated regularly | None | None |
Generic sensors | The System Information API |
Device
APIs
|
Working Draft |
|
Last update Jan 2011 | None | None |
Camera & Microphone streams |
|
|
N/A | None |
|
A few experimental ones | None |
Network
Network connectivity represents a major asset for mobile devices: the Web is an immense store of content, as well as an almost endless source of processing power, overcoming two of the limitations of mobile devices.
The Web platform is growing a number of APIs that facilitate establishing network connectivity in different contexts.
XMLHttpRequest (the “X” in AJAX) is a widely deployed API to load content from Web servers using the HTTP and HTTPs protocol.
A second version of that specification, XMLHttpRequest Level 2 completes the existing API with the ability to make requests on servers in a different domain, programmatic feedback on the progress of the network operations, and more efficient handling of binary content.
By
default,
browsers
prevent
from
making
do
not
allow
to
make
request
across
different
domains
(or
more
specifically,
across
different
origins
,
a
combination
of
the
protocol,
domain
and
port);
port)
from
a
single
Web
page;
this
rule
protects
the
user
from
having
a
Web
site
abusing
from
the
user
their
credentials
and
stealing
their
data
on
another
Web
site.
Sites
can
opt-out
of
that
rule
by
making
use
of
the
Cross-Origin
Resource
Sharing
mechanism,
opening
up
much
wider
cooperation
across
Web
applications
and
services.
XMLHttpRequest is useful for client-initiated network requests, but mobile devices with their limited network capabilities and the cost that network requests induce on their battery (and sometimes on their users bill) can often make better use of server-initiated requests. The Server-Sent Events API allows to trigger DOM events based on push notifications (via HTTP and other protocols.)
The
WebSocket
API
,
built
on
top
of
the
IETF
WebSocket
protocol
,
offers
a
bidirectional,
more
flexible,
and
less
resource
intensive
network
connectivity.
connectivity
than
XMLHttpRequest.
Of
course,
an
important
part
of
using
network
connectivity
relies
on
being
able
to
determine
if
such
connectivity
exists,
and
the
type
of
network
available.
The
HTML5
onLine
DOM
flag
(and
its
associated
change
event,
ononline
)
signals
when
network
connectivity
is
available
to
the
Web
environment.
Part
of
the
System
Information
The
network-information
API
addresses
discovery
of
the
network
characteristics
(e.g.
characteristics,
allowing
to
determine
for
instance
if
the
user
is
on
a
WIFI
vs
3G,
or
available
bandwidth),
but
this
proposal
is
now
being
recast
into
a
more
simple
network-centric
API
.
3G
connection.
Feature | Specification | Working Group | Maturity | Stability | Latest editors draft | Current implementations | Test suite |
---|---|---|---|---|---|---|---|
HTTP(s) network API | XMLHttpRequest | Web Applications Working Group | Candidate Recommendation | Mostly finished | Regularly updated | Widely deployed | Good coverage |
XHR2 | XMLHttpRequest Level 2 | Web Applications Working Group | Working Draft | Still changing, but starting to stabilize | Updated regularly | Very limited (?) | None (?) |
Cross-domain requests | Cross-Origin Resource Sharing | Web Applications Working Group | Working Draft | Close to stabilizing | Last update November 2010 | Growing deployment Implementation data | None (?) |
Server-pushed requests | Server-Sent Events | Web Applications Working Group | Last Call | Still changing but stabilizing | Regularly updated | Growing | None (?) |
Bidirectional connections | The WebSocket API | Web Applications Working Group | Working Draft | Still changing but stabilizing | Regularly updated |
|
None |
on-line state | HTML5 onLine DOM state | HTML Working Group | Last Call Working Draft | Mostly stable | regularly updated | Getting deployed | None |
Network characteristics | The Network Information API |
Device
APIs
|
|
Early draft | Regularly updated | Very limited | N/A |
Communication
Mobile
devices
are
often
communications
devices;
beyond
Beyond
connection
to
on-line
services,
allowing
communications
between
users,
but
also
between
devices
and
between
applications
is
an
important
aspect
of
a
good
mobile
development
platform.
The
Messaging
API
completes
the
existing
ability
to
create
and
send
message
through
links
(with
sms:
,
mms:
and
mailto:
URI
schemes)
with
more
control
on
adding
attachments
and
the
success
of
the
message
sending.
The
postMessage
API
of
HTML5
Web
Messaging
allows
for
Web
Applications
to
communicate
between
each
other.
Exploratory
work
in
the
Device
APIs
&
Policy
Working
Group,
inspired
by
the
Web
Introducer
and
similar
works,
would
also
open
up
possibilities
of
closer
integration
of
Web
applications.
The recent launch of the Web Real-Time Communications Working Group is the starting point of a much wider set of communication opportunity:
- Peer-to-peer connection across devices,
-
P2P
Audio
and
video
streams
allowing
for
real-time
communications
acrossbetween users.
Feature | Specification | Working Group | Maturity | Stability | Latest editors draft | Current implementations | Test suite |
---|---|---|---|---|---|---|---|
Emails, SMS and MMS with generated attachments | The Messaging API |
Device
APIs
|
Working Draft | Still subject to large changes |
Last
update
|
None | None |
Inter-app communications | HTML5 Web Messaging | Web Applications Working Group | Last Call |
|
Regularly updated | Limited (?) | None |
Inter-app triggers | None |
Possibly
Device
APIs
|
N/A | Not started | Possible inspiration from Web Introducer | None | None |
P2P
connections
| WebRTC 1.0: Real-time Communication Between Browsers | Web Real-Time Communications Working Group | N/A |
None
| Last updated Aug 23 | None | None |
P2P
Video/Audio
streams
|
Packaging
An
important
aspect
of
the
user
experience
of
applications
is
linked
to
how
the
user
perceives
the
said
application
is
available
permanently
(even
when
off-line,
which
is
particularly
important
on
mobile
devices),
as
well
as
how
it
can
shared
and
distributed
distributed,
typically
through
purchases
via
applications
stores
—
this
is
adequately
addressed
by
packaging
the
application
adequately.
application.
The Web platform offers two complementary approaches to packaging Web applications:
-
HTML5’s
ApplicationCache
enables access to Web applications off-line through the definition of a manifest of files that the browser is expected to keep in its cache; - the W3C Widgets family of specifications define a framework for distributing Web applications as Zip files completed by a configuration file (see Widget Packaging and Configuration ); this configuration file is the basis for additional features such as signature of applications , controlled access to advanced APIs, restricted network usage , etc.
Feature | Specification | Working Group | Maturity | Stability | Latest editors draft | Current implementations | Test suite |
---|---|---|---|---|---|---|---|
Application Cache | HTML5 Application Cache | HTML Working Group | Last Call Working Draft | Still changing but stabilizing | Regularly updated | Getting deployed | None |
Widgets | Widgets Packaging & Configuration | Web Applications Working Group | Proposed Recommendation | Mostly finished |
|
Getting deployed | Full coverage |
Digital Signatures for Widgets |
|
Mostly finished |
|
Getting deployed | Full coverage | ||
Widget Access Request Policy |
|
Mostly finished |
Last
update
|
Getting deployed | Full coverage |
Performance & Optimization
Due to their limited CPU, and more importantly to their limited battery, mobile devices require a lot of attention in terms of performance.
The
work
started
by
the
Web
Performance
Working
Group
on
Navigation
Timing
,
Resource
Timing
,
and
more
recently
Resource
Performance
Timeline
and
User
Timing
,
gives
tools
to
Web
developers
for
optimizing
their
Web
applications.
The proposed work on Efficient Script Yielding offers the opportunity to Web developers to use more efficiently asynchronous programming.
The API to determine whether a Web page is being displayed ( Page Visibility API ) can also be used to adapt the usage of resources to the need of the Web application, for instance by reducing network activity when the page is minimized. Likewise, the Timing control for script-based animations API can help reduce the usage of resources needed for playing animations.
Beyond
optimization
of
resources,
the
perceived
reactivity
of
an
application
is
also
a
critical
aspect
of
the
mobile
user
experience;
as
such,
the
experience.
The
thread-like
mechanism
made
possible
via
Web
Workers
allows
to
keep
keeping
the
user
interface
responsive
by
offloading
the
most
resource-intensive
operations
into
a
background
process.
The
Mobile
Web
Application
Best
Practices
provide
general
advices
advice
on
how
to
build
Web
applications
that
work
well
on
mobile
devices,
taking
into
account
in
particular
the
needs
for
optimization.
Feature | Specification | Working Group | Maturity | Stability | Latest editors draft | Current implementations | Test suite |
---|---|---|---|---|---|---|---|
Timing hooks | Navigation Timing | Web Performance Working Group | Candidate Recommendation | Mostly finished | Regularly updated | Getting deployed | Started |
Resource timing | Last Call Working Draft | Stabilizing | Regularly updated | None | N/A | ||
Performance Timeline | Working Draft |
|
Regularly updated | None | N/A | ||
User timing | Working Draft | Early draft | Regularly updated | None | N/A | ||
Priority handling | Efficient Script Yielding | N/A | Early draft | Regulary updated | None | N/A | |
Page Visibility detection | Page visibility API | Last Call Working Draft | Stabilizing | Regularly updated | None | N/A | |
Animation optimization | Timing control for script-based animations | Working Draft | Early draft | Regularly updated | None | N/A | |
Threading | Web Workers | Web Applications Working Group | Last Call | Stabilizing | Regularly updated | Limited (?) | None |
Optimization Best Practices | Mobile Web Application Best Practices | Mobile Web Best Practices Working Group (now closed) | Standard | Finished | N/A | N/A | N/A |