The
Gamepad
specification
defines
a
low-level
interface
that
represents
gamepad
devices.
Status
of
This
Document
This
is
a
preview
Do
not
attempt
to
implement
this
version
of
the
specification.
Do
not
reference
this
version
as
authoritative
in
any
way.
Instead,
see
https://w3c.github.io/gamepad/
for
the
Editor's
draft.
This
section
describes
the
status
of
this
document
at
the
time
of
its
publication.
A
list
of
current
W3C
publications
and
the
latest
revision
of
this
technical
report
can
be
found
in
the
W3C
standards
and
drafts
index
at
https://www.w3.org/TR/.
Publication
as
an
Editor's
Draft
does
not
imply
endorsement
by
W3C
and
its
Members.
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.
Some
user
agent
agents
s
have
connected
gamepad
devices.
These
devices
are
desirable
and
suited
to
input
for
gaming
applications,
and
for
"10
foot"
user
interfaces
(presentations,
media
viewers).
Currently,
the
only
way
for
a
gamepad
to
be
used
as
input
would
be
to
emulate
mouse
or
keyboard
events,
however
this
would
lose
information
and
require
additional
software
outside
of
the
user
agent
to
accomplish
emulation.
Meanwhile,
native
applications
are
capable
of
accessing
these
devices
via
system
APIs.
The
Gamepad
API
provides
a
solution
to
this
problem
by
specifying
interfaces
that
allow
web
applications
to
directly
act
on
gamepad
data.
2.
Scope
Interfacing
with
external
devices
designed
to
control
games
has
the
potential
to
become
large
and
intractable
if
approached
in
full
generality.
In
this
specification
we
explicitly
choose
to
narrow
scope
to
provide
a
useful
subset
of
functionality
that
can
be
widely
implemented
and
broadly
useful.
Specifically,
we
choose
to
only
support
the
functionality
required
to
support
gamepads.
Support
for
gamepads
requires
two
input
types:
buttons
and
axes.
Both
buttons
and
axes
are
reported
as
analog
values,
buttons
ranging
from
[0..1],
[0
..
1],
and
axes
ranging
from
[-1..1].
[-1
..
1].
While
the
primary
goal
is
support
for
gamepad
devices,
supporting
these
two
types
of
analog
inputs
allows
support
for
other
similar
devices
common
to
current
gaming
systems
including
joysticks,
driving
wheels,
pedals,
and
accelerometers.
As
such,
the
name
"gamepad"
is
exemplary
rather
than
trying
to
be
a
generic
name
for
the
entire
set
of
devices
addressed
by
this
specification.
We
specifically
exclude
support
for
more
complex
devices
that
may
also
be
used
in
some
gaming
contexts,
including
those
that
that
do
motion
sensing,
depth
sensing,
video
analysis,
gesture
recognition,
and
so
on.
3.
Model
A
gamepad
is
a
collection
of
input
controls
and
output
controls.
An
input
control
has
a
collection
of
input
values
that
may
update
over
time.
Input
controls
include
the
buttons,
triggers,
joysticks,
thumbsticks,
and
touch
surfaces
of
the
gamepad
.
An
output
control
is
a
feature
that
changes
the
behavior
of
the
gamepad
to
provide
feedback
to
the
user
interacting
with
the
gamepad
.
Output
controls
include
the
haptic
actuators
of
the
gamepad
.
A
gamepad
is
available
if
the
user
agent
can
read
the
current
state
of
its
input
controls
.
A
gamepad
that
is
not
available
is
unavailable
.
The
input
controls
and
output
controls
for
a
gamepad
cannot
change
while
the
gamepad
is
available
.
A
gamepad
has
a
gamepad
identifier
string
,
a
human-readable
string
that
identifies
the
brand
or
style
of
gamepad
.
The
content
is
decided
by
the
user
agent
.
3.1
Input
control
layout
A
gamepad
may
have
an
input
control
layout
that
describes
the
position,
orientation
and
type
of
each
input
control
on
the
gamepad
.
The
user
agent
is
responsible
for
recognizing
when
a
gamepad
corresponds
with
a
standard
layout
,
meaning
the
gamepad
has
an
input
control
layout
that
enables
it
to
be
used
interchangeably
with
other
gamepads
that
correspond
with
the
same
standard
layout.
The
user
agent
SHOULD
consider
a
layout
to
correspond
with
a
standard
layout
if
its
input
controls
have
approximately
the
same
relative
positions
and
orientations
as
input
controls
described
in
the
standard
layout.
An
accessible
gamepad
model
is
a
gamepad
where
the
manufacturer's
intent
is
to
provide
a
swap-in
replacement
for
a
gamepad
with
a
standard
layout.
For
example,
Xbox
Adaptive
Controller
and
PlayStation
Access
Controller
are
accessible
gamepad
models.
Xbox
Wireless
Controller
and
DualSense
are
the
corresponding
standard
models.
3.2
Input
values
Each
input
control
has
one
or
more
associated
input
values
,
which
are
numerical
values
that
represent
the
current
state
of
the
control.
Input
values
can
update
at
any
time.
The
user
agent
is
responsible
for
detecting
when
input
values
have
updated
and
SHOULD
try
to
minimize
the
delay
between
the
update
and
when
the
updated
values
are
read.
Reading
an
input
value
returns
its
logical
value
,
an
unscaled
numerical
representation
of
the
current
state.
An
input
value
also
has
a
logical
minimum
and
logical
maximum
which
define
the
minimum
and
maximum
in-bounds
logical
values
.
An
input
control
may
be
designed
to
automatically
return
a
button
to
an
unpressed
state
when
the
user
stops
interacting
with
the
input
control
.
If
so,
the
button
has
a
preferred
button
state
.
A
button
may
have
a
digital
switch
to
indicate
when
the
button
is
activated.
If
so,
the
button
has
an
additional
input
value
,
the
digital
button
value
,
that
is
true
when
the
button
is
activated
and
false
otherwise.
A
button
may
have
an
analog
sensor
enabling
the
button
to
report
the
degree
to
which
the
button
is
activated.
If
so,
the
button
has:
An
analog
button
value
,
a
logical
value
that
represents
the
degree
of
activation,
A
button
may
be
capable
of
detecting
touch.
If
so,
the
button
has
an
additional
input
value
,
the
button
touch
value
,
that
is
true
when
the
button
is
touched
and
false
otherwise.
A
touch
surface
has
an
active
touch
point
list
input
value
,
a
list
of
zero
or
more
touch
points
representing
the
points
of
contact
currently
detected
by
the
sensor.
A
touch
point
represents
a
single
point
of
contact
at
a
single
point
in
time.
A
touch
point
has
a
touch
x
coordinate
and
a
touch
y
coordinate
representing
the
position
in
the
touch
surface
's
coordinate
system.
If
a
touch
surface
is
on
the
top,
bottom,
front,
or
back
side
of
the
gamepad
then
the
touch
x
coordinate
is
measured
along
the
left-right
axis,
otherwise
it
is
measured
along
the
top-bottom
axis.
The
touch
y
coordinate
is
measured
along
the
perpendicular
axis.
If
a
touch
surface
is
on
the
left
or
right
side
of
a
gamepad
then
neither
of
its
dimensions
will
align
with
the
horizontal
axis.
Mapping
from
unmapped
indices
in
the
axis
index
list
to
an
index
indices
in
the
Gamepad
.
axes
array
[[axisMinimums]]
An
empty
list
A
list
containing
the
minimum
logical
value
for
each
axis
[[axisMaximums]]
An
empty
list
A
list
containing
the
maximum
logical
value
for
each
axis
A
list
containing
Holds
the
minimum
logical
value
for
each
button.
[[buttonMaximums]]
An
empty
list
A
list
containing
the
maximum
logical
value
for
each
button
[[touches]]
Initialize
to
an
is
empty
of
GamepadTouch
list
objects
representing
all
active
touch
points
Holds
for
the
list
of
user-generated
touches,
if
any.
gamepad
.
If
the
gamepad
does
not
support
has
no
touch
surfaces,
surfaces
,
then
the
list
will
remain
empty.
The
exact
format
of
the
id
string
is
left
unspecified.
It
is
RECOMMENDED
that
the
user
agent
select
a
string
that
identifies
the
product
without
uniquely
identifying
the
device.
For
example,
a
USB
gamepad
may
be
identified
by
its
idVendor
and
idProduct
values.
Unique
identifiers
like
serial
numbers
or
Bluetooth
device
addresses
MUST
NOT
be
included
in
the
id
string.
index
attribute
The
index
of
the
gamepad
Gamepad
object
in
the
Navigator
.
When
multiple
gamepads
are
connected
to
a
user
agent
,
indices
MUST
be
assigned
on
a
first-come,
first-serve
basis,
starting
at
zero.
If
a
gamepad
is
disconnected,
previously
assigned
indices
MUST
NOT
be
reassigned
to
gamepads
that
continue
to
be
connected.
However,
if
a
gamepad
is
disconnected,
and
subsequently
the
same
or
a
different
gamepad
is
then
connected,
the
lowest
previously
used
index
MUST
be
reused.
[[gamepads]]
.
The
timestamp
allows
the
author
to
determine
when
the
last
time
the
axes
or
buttons
attribute
for
this
gamepad
was
updated.
The
value
MUST
be
set
to
the
current
high
resolution
time
each
time
the
system
receives
new
button
or
axis
input
values
from
the
device.
If
no
data
has
been
received
from
the
hardware,
timestamp
MUST
be
the
current
high
resolution
time
at
the
time
when
the
for
this
Gamepad
was
first
made
available
to
script.
updated.
Warning
User
agent
agents
s
SHOULD
set
a
minimum
resolution
of
gamepad
's
the
timestamp
attribute
to
5
microseconds,
following
[
HR-TIME
]'s
clock
resolution
recommendation.
Array
of
values
for
all
axes
axis
inputs
of
the
gamepad.
All
axis
values
MUST
be
linearly
gamepad
normalized
to
the
range
[-1.0
[-1
..
1.0].
1].
If
the
controller
gamepad
is
perpendicular
to
the
ground
with
the
directional
stick
thumbsticks
pointing
up,
-1.0
-1
SHOULD
correspond
to
"forward"
or
"left",
and
1.0
1
SHOULD
correspond
to
"backward"
or
"right".
Axes
that
are
drawn
Axis
inputs
with
input
values
from
a
2D
thumbstick,
joystick,
or
another
input
device
control
that
reports
X
and
Y
values
SHOULD
appear
next
to
each
other
in
the
axes
array,
X
then
Y.
It
is
RECOMMENDED
that
axes
axis
inputs
appear
in
decreasing
order
of
importance,
such
that
element
0
and
1
typically
represent
the
X
and
Y
axis
axes
of
a
directional
stick.
thumbstick
or
joystick.
The
same
object
MUST
be
returned
until
the
user
agent
needs
to
return
different
values
(or
values
in
a
different
order).
Array
of
button
states
for
all
buttons
of
the
gamepad.
gamepad
.
It
is
RECOMMENDED
that
buttons
appear
in
decreasing
importance
such
that
the
primary
button,
secondary
button,
tertiary
button,
and
so
on
appear
as
elements
0,
1,
2,
...
in
the
buttons
array.
The
same
object
MUST
be
returned
until
the
user
agent
needs
to
return
different
values
(or
values
in
a
different
order).
To
map
and
normalize
axes
for
gamepad
,
run
the
following
steps:
Let
axisValues
rawGamepad
be
a
list
of
unsigned
long
values
representing
the
most
recent
logical
axis
input
values
for
each
axis
input
of
the
device
gamepad
represented
by
gamepad
.
Let
maxRawAxisIndex
be
the
size
of
axisValues
−
1.
For
each
rawAxisIndex
of
the
range
indices
from
0
to
maxRawAxisIndex
of
the
axis
list
of
rawGamepad
:
Set
gamepad
.
[[axes]]
[
axisIndex
]
to
be
normalizedValue
.
To
map
and
normalize
buttons
for
gamepad
,
run
the
following
steps:
Let
buttonValues
rawGamepad
be
a
list
of
unsigned
long
values
representing
the
most
recent
logical
button
input
values
for
each
button
input
of
the
device
gamepad
represented
by
gamepad
.
Let
maxRawButtonIndex
be
the
size
of
buttonValues
−
1.
For
each
rawButtonIndex
of
the
range
indices
from
0
to
maxRawButtonIndex
:
of
the
rawGamepad
's
button
list
:
Let
mappedIndex
rawButton
be
gamepad
.
[[buttonMapping]]
the
button
[
at
index
rawButtonIndex
].
Let
logicalValue
be
buttonValues
[
rawButtonIndex
of
rawGamepad
].
's
button
list
.
Let
logicalMinimum
be
gamepad
.
[[buttonMinimums]]
[
rawButtonIndex
].
Let
logicalMaximum
mappedIndex
be
gamepad
.
[[buttonMaximums]]
[[buttonMapping]]
[
rawButtonIndex
].
Let
normalizedValue
be
(
logicalValue
−
logicalMinimum
)
/
(
logicalMaximum
−
logicalMinimum
).
Let
button
be
Set
gamepad
.
[[buttons]]
[
mappedIndex
].
Set
button
.
[[value]]
to
normalizedValue
the
current
normalized
button
value
for
rawButton
.
Set
touch
.
position
to
a
new
DOMPointReadOnly
with
x
initialized
to
device
X
coordinate
relative
to
the
device
touch
surface
and
x
coordinate
normalized
to
[-1.0,1.0]
[-1
..
1]
where
-1.0
-1
is
the
leftmost
coordinate
and
1.0
1
is
the
rightmost
coordinate
and
y
initialized
to
the
device
touch
surface
and
y
coordinate
normalized
to
[-1.0,1.0]
[-1
..
1]
where
-1.0
-1
is
the
leftmost
topmost
coordinate
and
1.0
1
is
the
rightmost
bottommost
coordinate.
Note
:
Possible
implementation
(if
surfaceDimensions
are
available)
x
=
(2.0
*
touchData.x
/
surfaceDimensions.width)
-
1
Note
:
Possible
implementation
(if
surfaceDimensions
are
available)
y
=
(2.0
*
touchData.y
/
surfaceDimensions.height)
-
1
Initialize
axesSize
to
be
0.
For
each
rawInputIndex
of
the
range
from
0
to
inputCount
−
1:
If
the
the
gamepad
axis
at
index
rawInputIndex
rawAxis
represents
a
Standard
Gamepad
axis
:
Initialize
mappedIndexList
to
be
an
empty
list
.
Initialize
buttonsSize
to
be
0.
For
each
rawInputIndex
of
the
range
from
0
to
inputCount
−
1:
If
the
the
gamepad
button
at
index
rawInputIndex
rawButton
represents
a
Standard
Gamepad
button
:
Let
canonicalIndex
be
the
canonical
index
for
the
button.
rawButton
.
If
mappedIndexList
contain
s
canonicalIndex
,
then
append
rawInputIndex
to
unmappedInputList
.
A
double
in
the
range
[0
..
1]
representing
the
button
value
scaled
degree
to
which
the
range
[0.0
..
1.0]
button
is
activated
pressed
attribute
The
pressed
state
of
Indicates
whether
the
button.
button
is
pressed.
This
property
MUST
be
true
if
the
button
is
currently
pressed,
and
false
if
it
is
not
pressed.
For
buttons
which
do
not
have
a
digital
switch
to
indicate
a
pure
pressed
or
released
state,
the
user
agent
MUST
choose
a
button
press
threshold
to
indicate
the
button
as
pressed
when
its
value
is
above
a
certain
amount.
If
the
platform
API
gives
a
recommended
value,
the
user
agent
SHOULD
use
that.
In
other
cases,
the
user
agent
SHOULD
choose
some
other
reasonable
value.
A
DOMPointReadOnly
which
holds
the
normalized
touch
x
coordinate
and
touch
y
coordinate
of
the
touch
point
as
x
,
and
y
coordinates
of
the
touch.
.
The
z
and
w
value
values
are
currently
unused.
The
range
of
each
coordinate
is
normalized
to
[-1.0,
1.0].
[-1
..
1].
Along
the
x-axis,
-1.0
-1
references
the
leftmost
coordinate
and
1.0
1
references
the
rightmost
coordinate.
Along
the
y-axis,
-1.0
-1
references
the
topmost
coordinate
and
1.0
1
references
the
bottommost
coordinate.
A
GamepadHapticActuator
corresponds
to
This
interface
represents
a
configuration
haptic
actuator
capable
of
motors
or
other
actuators
playing
haptic
effects
that
can
apply
move
the
gamepad
in
a
force
for
way
that
can
be
felt
by
the
purposes
of
haptic
feedback.
user.
To
issue
play
a
haptic
effect
on
an
actuator,
a
haptic
actuator
,
the
user
agent
MUST
send
a
command
to
the
device
haptic
actuator
to
render
an
a
haptic
effect
of
type
and
try
to
make
it
use
the
provided
params
.
The
user
agent
SHOULD
use
the
provided
playEffectTimestamp
for
more
precise
playback
timing
when
params
.
startDelay
is
not
0.0
.
0.
The
user
agent
MAY
modify
the
effect
to
increase
compatibility.
For
example,
an
effect
intended
for
a
rumble
motor
may
be
transformed
into
a
waveform-based
effect
for
a
device
that
supports
waveform
haptics
but
lacks
rumble
motors.
To
stop
haptic
effects
on
an
actuator,
a
haptic
actuator
,
the
user
agent
MUST
send
a
command
to
the
device
haptic
actuator
to
abort
any
effects
currently
being
played.
played
on
that
actuator.
If
a
haptic
effect
was
interrupted,
the
actuator
SHOULD
return
to
a
motionless
state
as
quickly
as
possible.
8.1
Handling
visibility
change
When
the
document
's
visibility
state
becomes
"hidden"
,
run
these
steps
for
steps:
Let
supportedEffectsList
be
an
empty
list.
For
each
enum
value
type
of
GamepadHapticEffectType
,
if
the
user
agent
can
send
a
command
to
initiate
effects
of
that
type
on
that
actuator,
append
type
to
supportedEffectsList
.
Set
gamepadHapticActuator
.
[[effects]]
to
supportedEffectsList
.
the
supported
effect
types
for
the
vibration
actuator
.
"
dual-rumble
"
describes
a
haptic
configuration
with
an
eccentric
rotating
mass
(ERM)
vibration
motor
in
each
handle
of
a
standard
gamepad.
gamepad
.
In
this
configuration,
either
motor
is
capable
of
vibrating
the
whole
gamepad.
gamepad
.
The
vibration
effects
created
by
each
motor
are
unequal
so
that
the
effects
of
each
can
be
combined
to
create
more
complex
haptic
effects.
effects
.
strongMagnitude
and
weakMagnitude
set
the
intensity
levels
for
the
low-frequency
and
high-frequency
vibrations,
normalized
to
the
range
[0,1]
,
[0
..
1],
defaulting
to
0.
"
trigger-rumble
"
describes
a
haptics
configuration
with
a
vibration
motor
in
each
of
the
bottom
front
buttons
of
a
Standard
Gamepad
(buttons
with
canonical
indices
6
and
7)
in
addition
to
the
two
handle
motors
used
for
"
dual-rumble
".
These
buttons
most
commonly
take
the
form
of
spring-loaded
triggers.
In
this
configuration,
either
motor
is
capable
of
providing
localized
haptic
feedback
on
the
button's
surface.
A
GamepadEffectParameters
dictionary
contains
keys
for
parameters
used
by
haptic
effects.
effects
.
The
meaning
of
each
key
is
defined
by
the
haptic
effect,
effect
type,
and
some
keys
may
be
unused.
To
mitigate
unwanted
long-running
effects,
the
user
agent
MAY
limit
the
total
effect
duration
for
a
valid
effect
to
some
maximum
duration.
It
is
RECOMMENDED
that
the
user
agent
use
a
maximum
of
5
seconds.
duration
sets
the
duration
of
the
vibration
effect
in
milliseconds.
startDelay
member
startDelay
sets
the
duration
of
the
delay
after
playEffect
()
is
called
until
vibration
is
started,
in
milliseconds.
During
the
delay
interval,
the
actuator
SHOULD
NOT
vibrate.
A
gamepad
contains
a
gamepad
user
gesture
if
the
current
input
state
indicates
that
the
user
is
currently
interacting
with
the
gamepad.
gamepad
.
The
user
agent
MUST
provide
an
algorithm
to
check
if
the
input
state
contains
a
gamepad
user
gesture.
For
buttons
that
support
have
a
neutral
default
value
preferred
button
state
and
have
reported
a
pressed
value
of
false
at
least
once,
a
pressed
value
of
true
SHOULD
be
considered
interaction.
If
a
button
does
not
support
have
a
neutral
default
value
preferred
button
state
(for
example,
a
toggle
switch),
then
a
pressed
value
of
true
SHOULD
NOT
be
considered
interaction.
If
a
button
has
never
reported
a
pressed
value
of
false
then
it
SHOULD
NOT
be
considered
interaction.
Axis
movements
SHOULD
be
considered
interaction
if
the
axis
supports
has
a
neutral
default
value,
preferred
axis
state
,
the
current
displacement
from
neutral
the
center
position
is
greater
than
a
threshold
chosen
by
the
user
agent
,
and
the
axis
has
reported
a
value
below
the
threshold
at
least
once.
If
an
axis
does
not
support
have
a
neutral
default
value
preferred
axis
state
(for
example,
an
axis
for
a
joystick
that
does
not
self-center),
or
an
axis
has
never
reported
a
value
below
the
axis
gesture
threshold,
then
the
axis
SHOULD
NOT
be
considered
when
checking
for
interaction.
The
axis
gesture
threshold
SHOULD
be
large
enough
that
random
jitter
is
not
considered
interaction.
Additionally
there
are
de
facto
standard
layouts
that
have
been
made
popular
by
game
consoles.
When
the
user
agent
recognizes
the
attached
device,
it
is
RECOMMENDED
that
it
be
remapped
to
a
canonical
ordering
when
possible.
Devices
that
are
not
recognized
should
still
be
exposed
in
their
raw
form.
There
is
currently
one
canonical
layout,
the
Standard
Gamepad
.
When
remapping,
the
indices
in
axes
and
buttons
should
correspond
as
closely
as
possible
to
the
physical
locations
in
the
diagram
below.
Additionally,
mapping
SHOULD
be
set
to
"
standard
".
The
Standard
Gamepad
buttons
are
laid
out
in
a
left
cluster
of
four
buttons,
buttons
,
a
right
cluster
of
four
buttons,
buttons
,
a
center
cluster
of
three
buttons,
buttons
,
and
a
pair
of
front
facing
buttons
on
the
left
and
right
side
of
the
gamepad.
gamepad
.
The
four
axes
axis
inputs
of
the
"Standard
Gamepad"
are
associated
with
a
pair
of
analog
sticks,
one
on
the
left
and
one
on
the
right.
The
following
table
describes
the
buttons/axes
input
controls
and
their
physical
locations.
A
button
input
represents
a
Standard
Gamepad
button
if
it
reports
the
input
value
values
for
a
button
or
trigger,
and
the
button
or
trigger
is
located
in
approximately
the
same
location
as
the
corresponding
Standard
Gamepad
button.
button
or
trigger.
Inspecting
the
capabilities
of
Gamepad
objects
can
be
used
as
a
means
of
active
fingerprinting.
The
user
agent
MAY
alter
the
device
information
exposed
through
the
API
to
reduce
the
fingerprinting
surface.
As
an
example,
an
implementation
can
require
that
a
Gamepad
object
have
exactly
the
number
of
buttons
button
and
axes
axis
inputs
defined
in
the
Standard
Gamepad
layout
even
if
more
or
fewer
inputs
are
present
on
the
connected
device.
[
FINGERPRINTING-GUIDANCE
]
15.
Usage
Examples
This
section
is
non-normative.
The
example
below
demonstrates
typical
access
to
gamepads.
Note
the
relationship
with
the
requestAnimationFrame
()
method.
functionrunAnimation() {
window.requestAnimationFrame(runAnimation);
for (const pad of navigator.getGamepads()) {
// todo; simple demo of displaying pad.axes and pad.buttonsconsole.log(pad);
}
}
window
.
requestAnimationFrame
(runAnimation);
Interactive
applications
will
typically
be
using
the
requestAnimationFrame
()
method
to
drive
animation,
and
will
want
coordinate
animation
with
user
gamepad
input.
As
such,
the
gamepad
data
should
be
polled
as
closely
as
possible
to
immediately
before
the
animation
callbacks
are
executed,
and
with
frequency
matching
that
of
the
animation.
That
is,
if
the
animation
callbacks
are
running
at
60Hz,
the
gamepad
inputs
should
also
be
sampled
at
that
rate.
More
discussion
needed,
on
whether
to
include
or
exclude
axis
and
button
changed
events,
and
whether
to
roll
them
more
together
(
"gamepadchanged"
?),
separate
somewhat
(
"gamepadaxischanged"
?),
or
separate
by
individual
axis
and
button.
19.
Extensions
to
the
WindowEventHandlers
Interface
Mixin
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
MAY
,
MUST
,
MUST
NOT
,
RECOMMENDED
,
SHOULD
,
and
SHOULD
NOT
in
this
document
are
to
be
interpreted
as
described
in
BCP
14
[
RFC2119
]
[
RFC8174
]
when,
and
only
when,
they
appear
in
all
capitals,
as
shown
here.
A.
Acknowledgements
This
section
is
non-normative.
The
following
people
contributed
to
the
development
of
this
document.
