Copyright
©
2012
2013
W3C
®
(
MIT
,
ERCIM
,
Keio
,
Beihang
),
All
Rights
Reserved.
W3C
liability
,
trademark
and
document
use
rules
apply.
This specification defines an API that provides access to the vibration mechanism of the hosting device. Vibration is a form of tactile feedback.
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/.
The changes made since the 08 May 2012 W3C Candidate Recommendation ( diff ):
vibrate()
method's
return
type
from
void
to
boolean,
use
sequence
type
for
the
pattern
attribute,
make
the
interface
partial
This
document
represents
the
consensus
of
the
group
on
the
scope
and
features
of
the
Vibration
API.
It
should
be
noted
that
the
group
is
aware
of
more
advanced
use
cases
that
cannot
be
realised
realized
using
this
simpler
first
version.
The
intent
is
to
address
them
in
a
future
revision.
This
document
was
published
by
the
Device
APIs
Working
Group
as
a
Candidate
Recommendation.
Last
Call
Working
Draft.
This
document
is
intended
to
become
a
W3C
Recommendation.
If
you
wish
to
make
comments
regarding
this
document,
please
send
them
to
public-device-apis@w3.org
(
subscribe
,
archives
).
W3C
publishes
a
Candidate
Recommendation
to
indicate
that
the
document
is
believed
to
be
stable
and
to
encourage
implementation
by
the
developer
community.
This
Candidate
Recommendation
is
expected
to
advance
to
Proposed
Recommendation
no
earlier
than
01
July
2012.
The
Last
Call
period
ends
13
June
2013.
All
feedback
is
comments
are
welcome.
Publication
as
a
Candidate
Recommendation
Last
Call
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 is a Last Call Working Draft and thus the Working Group has determined that this document has satisfied the relevant technical requirements and is sufficiently stable to advance through the Technical Recommendation process.
This document was produced by a group operating under the 5 February 2004 W3C Patent Policy . 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 .
This section is non-normative.
The
Vibration
API
defines
a
means
for
web
developers
to
programmatically
provide
tactile
feedback
in
the
form
of
vibration.
The
API
is
specifically
designed
to
tackle
high-value
address
use
cases
related
to
gaming,
and
that
require
simple
tactile
feedback
only.
Use
cases
requiring
more
fine-grained
control
are
out
of
scope
for
this
specification.
In
addition,
the
API
is
not
meant
to
be
used
as
a
generic
notification
mechanism.
As well as sections marked as non-normative, all authoring guidelines, diagrams, examples, and notes in this specification are non-normative. Everything else in this specification is normative.
The
key
words
must
MUST
,
must
not
MUST
NOT
,
required
REQUIRED
,
should
SHOULD
,
should
not
SHOULD
NOT
,
recommended
RECOMMENDED
,
may
MAY
,
and
optional
OPTIONAL
in
this
specification
are
to
be
interpreted
as
described
in
[
RFC2119
].
This specification defines conformance criteria that apply to a single product: the user agent that implements the interfaces that it contains.
Implementations that use ECMAScript to implement the APIs defined in this specification must implement them in a manner consistent with the ECMAScript Bindings defined in the Web IDL specification [ WEBIDL ], as this specification uses that specification and terminology.
The
concepts
browsing
context
;
and
All
instances
of
spin
the
Navigator
event
loop
type
are
defined
to
also
implement
the
Vibration
in
[
HTML5
interface.
{
};
].
The
vibrate()
method,
when
invoked,
must
MUST
run
the
algorithm
for
processing
vibration
patterns
.
The rules for processing vibration patterns are as given in the following algorithm:
NotSupportedError
hidden
When
the
visibilitychange
event
[
PAGE-VISIBILITY
]
is
dispatched
at
the
Document
,
the
user
agent
must
run
the
following
steps:
If
the
hidden
attribute
[
PAGE-VISIBILITY
]
is
set
to
true,
the
user
agent
must
suppress
the
vibration
produced
by
running
the
pre-existing
instance
of
the
processing
vibration
patterns
algorithm,
if
any.
If
the
hidden
attribute
[
PAGE-VISIBILITY
]
is
set
to
false,
in
a
browsing
context
,
the
user
agent
must
MUST
restore
the
vibration
produced
by
running
cancel
the
pre-existing
instance
of
the
processing
vibration
patterns
algorithm,
if
any.
If
the
device
does
not
provide
a
vibration
mechanism,
or
it
is
disabled,
the
user
agent
must
silently
ignore
any
invocations
of
the
vibrate()
method.
This section is non-normative.
In
the
following
example
the
device
vibrates
will
vibrate
for
1
second:
1000
milliseconds
(ms):
// vibrate for 1000 ms navigator.vibrate(1000); // or alternatively navigator.vibrate([1000]);
In
the
following
example
the
pattern
will
cause
the
device
vibrates
to
vibrate
for
1
second,
is
50
ms,
be
still
for
0.5
seconds,
100
ms,
and
vibrates
again
then
vibrate
for
2
seconds:
150
ms:
navigator.vibrate([50, 100, 150]);
The following example cancels any existing vibrations:
// cancel any existing vibrations navigator.vibrate(0); // or alternatively navigator.vibrate([]);
The
group
is
deeply
indebted
to
Justin
Lebar,
Mounir
Lamouri,
Jonas
Sicking,
and
the
Mozilla
WebAPI
team
in
general
for
their
contributions,
and
for
providing
the
WebVibrator
prototype
as
an
initial
input.