This
document
specifies
an
API
that
allows
web
applications
to
request
and
be
notified
of
changes
of
the
posture
of
a
device.
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/device-posture/
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
technical
reports
index
at
https://www.w3.org/TR/.
Implementors
need
to
be
aware
that
this
specification
is
extremely
unstable.
Implementors
who
are
not
taking
part
in
the
discussions
will
find
the
specification
changing
out
from
under
them
in
incompatible
ways.
Vendors
interested
in
implementing
this
specification
before
it
eventually
reaches
the
Candidate
Recommendation
phase
should
subscribe
to
the
repository
on
GitHub
and
take
part
in
the
discussions.
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.
The
device
posture
is
the
physical
position
in
which
a
device
holds
which
may
be
derived
from
sensors
in
addition
to
the
angle.
New
types
of
mobile
devices
are
appearing
that
have
some
sort
of
capabilities
that
allow
them
to
change
their
posture.
The
most
common
types
of
devices
are
the
ones
that
can
fold
(their
screen
or
around
their
screen),
allowing
them
to
physically
alter
their
form
factor.
The
main
interest
in
knowing
the
posture
of
a
device
is
to
enable
new
user
experiences
with
responsive
design.
Among
the
described
"folding"
devices,
there
are
mainly
two
different
physical
form
factors:
devices
with
a
single
flexible
screen
(seamless),
and
devices
with
two
screens
(with
seam).
They
can
both
fold
around
a
hinge,
and
the
current
specification
applies
to
both
types.
It
should
be
clarified
as
well
that
both
seamless
and
(devices)
with
seam
can
be
of
different
dimension
ranging
from
mobile
and
tablets
to
laptop
sizes.
It
should
also
be
noted
that
different
devices
will
have
different
default
orientations
(portrait
or
landscape),
and
that
the
fold
might
happen
in
a
vertical
or
horizontal
way.
From
enhancing
the
usability
of
a
website
by
avoiding
the
area
of
a
fold,
to
enabling
innovative
use
cases
for
the
web,
knowing
the
posture
of
a
device
can
help
developers
tailor
their
content
to
different
devices.
Content
can
be
consumed
and
browsed
even
when
the
device
is
not
flat,
in
which
case
the
developer
might
want
to
provide
a
different
layout
for
it
depending
on
the
posture
state
in
which
the
device
is
being
used.
2.
Internal
slots
The
following
internal
slots
are
added
to
the
Document
interface.
As
it
name
implies,
it
will
house
the
value
of
the
current
posture
the
device
is
This
specification
defines
the
following
posture
values:
Continuous
posture:
The
continuous
posture
refers
to
a
"flat"
position.
This
is
the
default
case
for
most
devices
not
allowing
different
postures.
It
includes
devices
with
no
folds,
hinges
or
similar
capabilities.
Due
to
the
nature
of
hardware
innovation,
it
also
includes
devices
with
dual,
foldable,
rollable
or
curved
screens,
as
long
as
they
are
in
a
posture
where
the
Document
is
expected
to
be
displayed
with
a
flat
layout.
Examples
of
these
are:
Foldable
device
in
a
flat,
fully
unfolded
posture.
Foldable
device
running
the
browser
in
a
window/section
that
does
not
span
across
the
hinge.
2-in-1
device
in
tablet
mode
using
only
1
screen/side.
Devices
that
do
not
fold.
Note
In
some
cases,
devices
can
run
several
apps
and
be
in
a
physical
posture
other
than
flat,
but
as
long
as
the
browser
does
not
span
through
several
screens/sections,
the
corresponding
posture
is
continuous.
Folded
posture:
The
folded
posture
refers
to
devices
that
can
physically
fold.
These
devices
can
have
one
flexible
screen
or
two
adjacent
screens.
This
posture
forms
an
angle
between
the
displays/sections
that
does
not
exceed
a
'flat'
position.
Examples
of
these
are:
Foldable
device
with
a
vertical
hinge
and
internal
screens
being
used
in
a
'book'
posture,
where
the
content
spans
through
both
sections
and
forms
an
angle
between
~30°
and
~170°.
Foldable
device
with
a
horizontal
hinge
and
internal
screens
being
used
in
a
'laptop'
posture.
The
values
are
approximations
and
might
differ
per
device.
For
instance,
a
device
might
not
yield
exactly
180°
when
laying
flat,
but
instead
values
ranging
from
175°
to
185°.
Device
makers
SHOULD
make
sure
that
the
physical
device
postures
map
correctly
to
the
postures
defined
by
this
specification.
Device
makers
are
also
allowed
to
determine
the
posture
using
more
sensors
than
just
the
hinge
angle.
For
example,
they
can
also
detect
if
keyboard
is
docked
on
the
bottom
half
of
the
screen
or
not.
Another
example
is
to
detect
whether
the
kickstand
is
deployed
or
not.
Some
devices
might
also
lack
one
or
more
of
the
postures
due
to
physical
constraints
or
device
design,
in
which
case
the
device
SHOULD
make
sure
that
all
combinations
of
angles
and
device
orientation
(which
can
be
locked
by
[
SCREEN-ORIENTATION
]
and
host
OS),
as
well
as
device
specific
signals,
maps
into
one
of
the
defined
postures.
7.1.1
Foldables
Posture
values
for
foldable
devices
Posture
Angle
value
continuous
<
~180°
folded
~180°
8.
Algorithms
8.1
Calculating
the
device
posture
information
The
steps
to
calculate
the
device
posture
information
of
a
Document
document
are
as
follows:
It
would
be
better
if
specification
authors
sent
a
pull
request
to
add
calls
from
here
into
their
specifications
directly,
instead
of
using
the
page
visibility
change
steps
hook,
to
ensure
well-defined
cross-specification
call
order.
As
of
the
time
of
this
writing
the
following
specifications
are
known
to
have
page
visibility
change
steps
,
which
will
be
run
in
an
unspecified
order:
Device
Posture
API
and
Web
NFC.
[DEVICEPOSTURE]
[WEBNFC]
9.
Security
Considerations
No
new
security
considerations
have
been
reported
on
this
specification.
10.
Privacy
considerations
The
Device
Posture
API
exposes
a
posture
determined
from
the
hinge
angle
sensor,
but
additional
data
can
be
used
to
determine
the
posture
such
as
whether
the
keyboard
is
attached
or
not,
whether
the
kickstand
is
deployed
or
not,
etc.
Device
Posture
exposes
high
level
concept
and
not
sensor
values
making
fingerprinting
possibilities
more
limited.
Changing
posture
is
a
physical
manipulation
done
by
the
user.
The
frequency
of
the
posture
changes
are
low,
users
do
not
constantly
adjust
the
angle,
and
even
if
they
do
the
posture
will
only
be
changed
in
certain
scenarios
as
described
in
posture
values
table
.
10.1
Types
of
privacy
threats
This
section
is
non-normative.
10.1.1
Identifying
users
across
contexts
If
this
API
can
be
used
simultaneously
in
different
window
contexts
on
the
same
device
it
may
be
possible
for
that
code
to
correlate
the
user
across
those
two
contexts,
creating
unanticipated
tracking
mechanisms.
However,
because
the
posture
value
is
typically
stable
for
a
long
time
it
could
only
be
used
to
verify
that
two
users
are
not
the
same,
but
it
would
not
help
to
identify
a
given
user
given
the
fact
that
there
are
multiple
types
and
models
of
foldable
devices.
This
API's
entropy
is
comparable
to
the
pointer
API
which
tells
whether
the
user's
primary
input
is
touch-based
or
not.
However,
the
primary
input
can
change
on
devices
where
the
keyboard
can
be
removed/added
or
the
tablet
mode
is
activated/deactivated.
10.1.2
iframes
iframes
have
access
to
the
posture
through
this
API
and
therefore
could
use
this
information
to
identify
users
as
mentioned
in
10.1.1
Identifying
users
across
contexts
.
Posture
value
change
events
are
only
fired
for
each
active
document
whose
visibility
state
is
"visible"
as
explained
in
device
posture
change
steps
,
and
polling
the
value
while
that
is
not
the
case,
will
return
a
stale
value
as
the
value
is
only
updated
while
the
visibility
state
is
"visible"
or
just
changed
to
"visible".
11.
Accessibility
considerations
The
main
focus
of
the
Device
Posture
API
is
to
improve
the
user
experience.
There
are
three
ways
in
which
applications
that
build
on
the
API
can
positively
impact
accessibility.
Designing
and
making
applications
which
do
not
place
content
in
the
fold/hinge
area,
especially
buttons.
This
area
is
typically
hard
to
interact
with
with
fingers
because
the
curvature
of
the
fold
makes
touch
less
precise
or
impossible.
Designing
and
making
applications
which
do
not
put
large,
contiguous
content
(such
as
video
or
a
picture)
spanning
across
the
fold/hinge
area
if
the
device
is
folded.
This
area
slightly
distorts
content
and
colors.
Designing
and
making
applications
which
use
the
screen
estate
better
by
providing
a
split
UI
(a
user
interface
where
the
content
is
split
up
across
the
screen
segments),
allowing
the
application
to
provide
a
differentiated
and
more
powerful
interface.
When
using
this
API
it
is
important
to
consider
the
opportunities
above
with
accessibility
in
mind.
Here
are
few
concrete
examples:
Placement
of
UI
elements:
A
typical
placement
logic
for
dialogs
is
to
center
them
horizontally
and
vertically,
but
in
a
device
folded
with
a
symmetrical
fold
they
may
end
up
in
the
middle
of
the
fold
area
making
it
harder
to
interact
with,
for
instance
clicking
on
buttons.
It
might
also
make
it
harder
to
read
text
due
to
distortion
and
light
reflection.
Fullscreen
mode:
When
resizing
an
element
in
fullscreen,
a
typical
logic
would
expand
that
element
to
the
width
and
the
height
of
the
Window
.
If
the
device
is
folded,
the
element
will
be
laid
out
across
the
fold,
leading
to
a
subpar
user
experience.
An
alternative
is
to
display
that
element
either
on
top
or
below
the
fold
area.
Improving
the
user
experience:
With
this
API
it
is
possible
to
create
a
different
and
adapted
user
experience
when
the
device
is
folded,
allowing
for
a
better
user
experience
and
improved
accessibility.
For
example,
when
watching
a
video
and
the
device
is
folded,
the
video
could
be
displayed
on
top
of
the
fold
while
the
comments
section
could
be
shown
below
the
fold
by
default.
Another
example
would
be
a
video
conferencing
application
showing
the
video
feed
on
top
of
the
fold
and
the
chat
below
the
fold.
Content
shouldn't
be
designed
for
just
one
posture
:
The
idea
of
foldable
devices
is
their
versatility
and
the
ability
for
the
user
to
change
the
posture
as
they
see
fit.
Similarly
to
the
orientation
,
it
is
important
to
not
always
choose
for
the
user
as
they
might
have
other
needs
but
allowing
them
to
choose
the
UI
that
fits
their
needs
better.
Ideally
it
is
preferred
to
make
the
UI
configurable.
12.
Automation
The
Device
Posture
API
pose
a
challenge
to
test
authors,
as
fully
exercising
interface
requires
physical
hardware
devices.
To
address
this
challenge
this
document
defines
a
[
WEBDRIVER2
]
extension
commands
that
allows
users
to
control
the
reported
device
posture
and
simulate
a
real
device.
navigator.devicePosture.addEventListener("change", () => {
console.log(`The current posture is: ${navigator.devicePosture.type}!`);
})
12.2
13.2
Example
2:
device-posture
The
device
is
being
used
for
a
video
call
web
service.
It
can
be
folded
into
the
laptop
posture
to
enable
a
hands-free
when
placed
on
a
surface.
The
UA
detects
the
posture
and
the
UI
is
enhanced.
Similar
examples
can
be
drafted
for
content
to
adapt
to
any
posture.
See
the
explainer
for
other
key
scenarios.
12.3
13.3
Example
3:
Feature
detection
of
device-posture
media
feature
As
one
of
the
valid
device-posture
values
will
always
be
true,
you
can
use
the
following
snippet
to
detect
whether
a
user
agent
supports
the
media
feature:
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
and
SHOULD
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.
This
specification
defines
conformance
criteria
for
a
single
product:
a
user
agent
that
implements
the
interfaces
that
it
contains.
We
would
like
to
offer
our
sincere
thanks
to
Daniel
Appelquist,
Jo
Balletti,
Michael
Blix,
Paul
Grenier
and
Laura
Morinigo
for
their
contributions
to
this
work.
