User
agents
are
not
required
to
present
HTML
documents
in
any
particular
way.
However,
this
section
provides
a
set
of
suggestions
for
rendering
HTML
documents
that,
if
followed,
are
likely
to
lead
to
a
user
experience
that
closely
resembles
the
experience
intended
by
the
documents'
authors.
So
as
to
avoid
confusion
regarding
the
normativity
of
this
section,
"must"
has
not
been
used.
Instead,
the
term
"expected"
is
used
to
indicate
behavior
that
will
lead
to
this
experience.
For
the
purposes
of
conformance
for
user
agents
designated
as
supporting
the
suggested
default
rendering
,
the
term
"expected"
in
this
section
has
the
same
conformance
implications
as
"must".
14.1
Introduction
In
general,
user
agents
are
expected
to
support
CSS,
and
many
of
the
suggestions
in
this
section
are
expressed
in
CSS
terms.
User
agents
that
use
other
presentation
mechanisms
can
derive
their
expected
behavior
by
translating
from
the
CSS
rules
given
in
this
section.
In
the
absence
of
style-layer
rules
to
the
contrary
(e.g.
author
style
sheets),
user
agents
are
expected
to
render
an
element
so
that
it
conveys
to
the
user
the
meaning
that
the
element
represents
,
as
described
by
this
specification.
The
suggestions
in
this
section
generally
assume
a
visual
output
medium
with
a
resolution
of
96dpi
or
greater,
but
HTML
is
intended
to
apply
to
multiple
media
(it
is
a
media-independent
language).
User
agent
implementers
are
encouraged
to
adapt
the
suggestions
in
this
section
to
their
target
media.
An
element
is
being
rendered
if
it
has
any
associated
CSS
layout
boxes,
SVG
layout
boxes,
or
some
equivalent
in
other
styling
languages.
Just
being
off-screen
does
not
mean
the
element
is
not
being
rendered
.
The
presence
of
the
hidden
attribute
normally
means
the
element
is
not
being
rendered
,
though
this
might
be
overridden
by
the
style
sheets.
An
element
is
said
to
intersect
the
viewport
when
it
is
being
rendered
and
its
associated
CSS
layout
box
intersects
the
viewport
.
This
specification
does
not
define
the
precise
timing
for
when
the
intersection
is
tested,
but
it
is
suggested
that
the
timing
match
that
of
the
Intersection
Observer
API.
[INTERSECTIONOBSERVER]
User
agents
that
do
not
honor
author-level
CSS
style
sheets
are
nonetheless
expected
to
act
as
if
they
applied
the
CSS
rules
given
in
these
sections
in
a
manner
consistent
with
this
specification
and
the
relevant
CSS
and
Unicode
specifications.
[CSS]
[UNICODE]
[BIDI]
14.2
The
CSS
user
agent
style
sheet
and
presentational
hints
The
CSS
rules
given
in
these
subsections
are,
except
where
otherwise
specified,
expected
to
be
used
as
part
of
the
user-agent
level
style
sheet
defaults
for
all
documents
that
contain
HTML
elements
.
Some
rules
are
intended
for
the
author-level
zero-specificity
presentational
hints
part
of
the
CSS
cascade;
these
are
explicitly
called
out
as
presentational
hints
.
When
the
text
below
says
that
an
attribute
attribute
on
an
element
element
maps
to
the
pixel
length
property
(or
properties)
properties
,
it
means
that
if
element
has
an
attribute
attribute
set,
and
parsing
that
attribute's
value
using
the
rules
for
parsing
non-negative
integers
doesn't
generate
an
error,
then
the
user
agent
is
expected
to
use
the
parsed
value
as
a
pixel
length
for
a
presentational
hint
for
properties
.
When
the
text
below
says
that
an
attribute
attribute
on
an
element
element
maps
to
the
dimension
property
(or
properties)
properties
,
it
means
that
if
element
has
an
attribute
attribute
set,
and
parsing
that
attribute's
value
using
the
rules
for
parsing
dimension
values
doesn't
generate
an
error,
then
the
user
agent
is
expected
to
use
the
parsed
dimension
as
the
value
for
a
presentational
hint
for
properties
,
with
the
value
given
as
a
pixel
length
if
the
dimension
was
a
length,
and
with
the
value
given
as
a
percentage
if
the
dimension
was
a
percentage.
When
the
text
below
says
that
an
attribute
attribute
on
an
element
element
maps
to
the
dimension
property
(ignoring
zero)
(or
properties)
properties
,
it
means
that
if
element
has
an
attribute
attribute
set,
and
parsing
that
attribute's
value
using
the
rules
for
parsing
nonzero
dimension
values
doesn't
generate
an
error,
then
the
user
agent
is
expected
to
use
the
parsed
dimension
as
the
value
for
a
presentational
hint
for
properties
,
with
the
value
given
as
a
pixel
length
if
the
dimension
was
a
length,
and
with
the
value
given
as
a
percentage
if
the
dimension
was
a
percentage.
When
a
user
agent
is
to
align
descendants
of
a
node,
the
user
agent
is
expected
to
align
only
those
descendants
that
have
both
their
'margin-inline-start'
and
'margin-inline-end'
properties
computing
to
a
value
other
than
'auto',
that
are
over-constrained
and
that
have
one
of
those
two
margins
with
a
used
value
forced
to
a
greater
value,
and
that
do
not
themselves
have
an
applicable
align
attribute.
When
multiple
elements
are
to
align
a
particular
descendant,
the
most
deeply
nested
such
element
is
expected
to
override
the
others.
Aligned
elements
are
expected
to
be
aligned
by
having
the
used
values
of
their
margins
on
the
line-left
and
line-right
sides
be
set
accordingly.
[CSSLOGICAL]
[CSSWM]
@namespace url(http://www.w3.org/1999/xhtml);
html,
body
{
display:
block;
}
For
each
property
in
the
table
below,
given
a
body
element,
the
first
attribute
that
exists
maps
to
the
pixel
length
property
on
the
body
element.
If
none
of
the
attributes
for
a
property
are
found,
or
if
the
value
of
the
attribute
that
was
found
cannot
be
parsed
successfully,
then
a
default
value
of
8px
is
expected
to
be
used
for
that
property
instead.
The
above
requirements
imply
that
a
page
can
change
the
margins
of
another
page
(including
one
from
another
origin
)
using,
for
example,
an
iframe
.
This
is
potentially
a
security
risk,
as
it
might
in
some
cases
allow
an
attack
to
contrive
a
situation
in
which
a
page
is
rendered
not
as
the
author
intended,
possibly
for
the
purposes
of
phishing
or
otherwise
misleading
the
user.
For
the
purposes
of
the
CSS
ruby
model,
runs
of
children
of
ruby
elements
that
are
not
rt
or
rp
elements
are
expected
to
be
wrapped
in
anonymous
boxes
whose
'display'
property
has
the
value
'ruby-base'
.
[CSSRUBY]
When
a
particular
part
of
a
ruby
has
more
than
one
annotation,
the
annotations
should
be
distributed
on
both
sides
of
the
base
text
so
as
to
minimize
the
stacking
of
ruby
annotations
on
one
side.
When
it
becomes
possible
to
do
so,
the
preceding
requirement
will
be
updated
to
be
expressed
in
terms
of
CSS
ruby.
(Currently,
CSS
ruby
does
not
handle
nested
ruby
elements
or
multiple
sequential
rt
elements,
which
is
how
this
semantic
is
expressed.)
User
agents
that
do
not
support
correct
ruby
rendering
are
expected
to
render
parentheses
around
the
text
of
rt
elements
in
the
absence
of
rp
elements.
User
agents
are
expected
to
support
the
'clear'
property
on
inline
elements
(in
order
to
render
br
elements
with
clear
attributes)
in
the
manner
described
in
the
non-normative
note
to
this
effect
in
CSS
.
The
initial
value
for
the
'color'
property
is
expected
to
be
black.
The
initial
value
for
the
'background-color'
property
is
expected
to
be
'transparent'.
The
canvas's
background
is
expected
to
be
white.
When
a
font
element
has
a
color
attribute,
its
value
is
expected
to
be
parsed
using
the
rules
for
parsing
a
legacy
color
value
,
and
if
that
does
not
return
an
error,
the
user
agent
is
expected
to
treat
the
attribute
as
a
presentational
hint
setting
the
element's
'color'
property
to
the
resulting
color.
The
font
element
is
expected
to
override
the
color
of
any
text
decoration
that
spans
the
text
of
the
element
to
the
used
value
of
the
element's
'color'
property.
When
a
font
element
has
a
face
attribute,
the
user
agent
is
expected
to
treat
the
attribute
as
a
presentational
hint
setting
the
element's
'font-family'
property
to
the
attribute's
value.
When
a
font
element
has
a
size
attribute,
the
user
agent
is
expected
to
use
the
following
steps,
known
as
the
rules
for
parsing
a
legacy
font
size
,
to
treat
the
attribute
as
a
presentational
hint
setting
the
element's
'font-size'
property:
Let
input
be
the
attribute's
value.
Let
position
be
a
pointer
into
input
,
initially
pointing
at
the
start
of
the
string.
If
the
character
at
position
is
a
U+002B
PLUS
SIGN
character
(+),
then
let
mode
be
relative-plus
,
and
advance
position
to
the
next
character.
Otherwise,
if
the
character
at
position
is
a
U+002D
HYPHEN-MINUS
character
(-),
then
let
mode
be
relative-minus
,
and
advance
position
to
the
next
character.
Otherwise,
let
mode
be
absolute
.
@namespace url(http://www.w3.org/1999/xhtml);
[dir]:dir(ltr), bdi:dir(ltr), input[type=tel i]:dir(ltr) { direction: ltr; }
[dir]:dir(rtl), bdi:dir(rtl) { direction: rtl; }
address, blockquote, center, div, figure, figcaption, footer, form, header, hr,
legend, listing, main, p, plaintext, pre, summary, xmp, article, aside, h1, h2,
h3, h4, h5, h6, hgroup, nav, section, table, caption, colgroup, col, thead,
tbody, tfoot, tr, td, th, dir, dd, dl, dt, menu, ol, ul, li, bdi, output,
[dir=ltr i], [dir=rtl i], [dir=auto i] {
unicode-bidi: isolate;
}
bdo, bdo[dir] { unicode-bidi: isolate-override; }
input[dir=auto i]:matches([type=search i], [type=tel i], [type=url i],
[type=email i]), textarea[dir=auto i], pre[dir=auto i] {
unicode-bidi: plaintext;
}
/* see prose for input elements whose type attribute is in the Text state */
/*
the
rules
setting
the
'content'
property
on
br
and
wbr
elements
also
has
bidi
implications
*/
When
an
input
element's
dir
attribute
is
in
the
auto
state
and
its
type
attribute
is
in
the
Text
state,
then
the
user
agent
is
expected
to
act
as
if
it
had
a
user-agent-level
style
sheet
rule
setting
the
'unicode-bidi'
property
to
'plaintext'.
This
block
is
automatically
generated
from
the
Unicode
Common
Locale
Data
Repository.
[CLDR]
User
agents
are
expected
to
use
either
the
block
below
(which
will
be
regularly
updated)
or
to
automatically
generate
their
own
copy
directly
from
the
source
material.
The
language
codes
are
derived
from
the
CLDR
file
names.
The
quotes
are
derived
from
the
delimiter
blocks,
with
fallback
handled
as
specified
in
the
CLDR
documentation.
When
rendering
li
elements,
non-CSS
user
agents
are
expected
to
use
the
ordinal
value
of
the
li
element
to
render
the
counter
in
the
list
item
marker.
This
specification
does
not
yet
define
the
CSS-specific
rules
for
rendering
li
elements,
because
CSS
doesn't
yet
provide
sufficient
hooks
for
this
purpose.
For
the
purposes
of
the
CSS
table
model,
the
col
element
is
expected
to
be
treated
as
if
it
was
present
as
many
times
as
its
span
attribute
specifies
.
For
the
purposes
of
the
CSS
table
model,
the
colgroup
element,
if
it
contains
no
col
element,
is
expected
to
be
treated
as
if
it
had
as
many
such
children
as
its
span
attribute
specifies
.
For
the
purposes
of
the
CSS
table
model,
the
colspan
and
rowspan
attributes
on
td
and
th
elements
are
expected
to
provide
the
special
knowledge
regarding
cells
spanning
rows
and
columns.
In
HTML
documents
,
the
following
rules
are
also
expected
to
apply:
User
agents
are
expected
to
have
a
rule
in
their
user
agent
style
sheet
that
matches
th
elements
that
have
a
parent
node
whose
computed
value
for
the
'text-align'
property
is
its
initial
value,
whose
declaration
block
consists
of
just
a
single
declaration
that
sets
the
'text-align'
property
to
the
value
'center'.
Rules
marked
"
only
if
border
is
not
equivalent
to
zero
"
in
the
CSS
block
above
is
expected
to
only
be
applied
if
the
border
attribute
mentioned
in
the
selectors
for
the
rule
is
not
only
present
but,
when
parsed
using
the
rules
for
parsing
non-negative
integers
,
is
also
found
to
have
a
value
other
than
zero
or
to
generate
an
error.
Otherwise,
if
an
hr
element
has
neither
a
color
attribute
nor
a
noshade
attribute,
but
does
have
a
size
attribute,
and
parsing
that
attribute's
value
using
the
rules
for
parsing
non-negative
integers
doesn't
generate
an
error,
then:
if
the
parsed
value
is
one,
then
the
user
agent
is
expected
to
use
the
attribute
as
a
presentational
hint
setting
the
element's
'border-bottom-width'
to
0;
otherwise,
if
the
parsed
value
is
greater
than
one,
then
the
user
agent
is
expected
to
use
the
parsed
value
minus
two
as
a
pixel
length
for
presentational
hints
for
the
'height'
property
on
the
element.
If
the
element's
box
has
a
child
box
that
matches
the
conditions
in
the
list
below,
then
the
first
such
child
box
is
the
'fieldset'
element's
rendered
legend
:
The
child's
used
value
of
'position'
is
not
'absolute'
or
'fixed'.
If
the
element
has
a
rendered
legend
,
then
the
border
is
expected
to
not
be
painted
behind
the
rectangle
defined
as
follows,
using
the
writing
mode
of
the
fieldset:
The
block-start
edge
of
the
rectangle
is
the
smaller
of
the
block-start
edge
of
the
rendered
legend
's
margin
rectangle
at
its
static
position
(ignoring
transforms),
and
the
block-start
outer
edge
of
the
fieldset
's
border.
The
block-end
edge
of
the
rectangle
is
the
larger
of
the
block-end
edge
of
the
rendered
legend
's
margin
rectangle
at
its
static
position
(ignoring
transforms),
and
the
block-end
outer
edge
of
the
fieldset
's
border.
The
inline-start
edge
of
the
rectangle
is
the
smaller
of
the
inline-start
edge
of
the
rendered
legend
's
border
rectangle
at
its
static
position
(ignoring
transforms),
and
the
inline-start
outer
edge
of
the
fieldset
's
border.
The
inline-end
edge
of
the
rectangle
is
the
larger
of
the
inline-end
edge
of
the
rendered
legend
's
border
rectangle
at
its
static
position
(ignoring
transforms),
and
the
inline-end
outer
edge
of
the
fieldset
's
border.
The
space
allocated
for
the
element's
border
on
the
block-start
side
is
expected
to
be
the
element's
'border-block-start-width'
or
the
rendered
legend
's
margin
box
size
in
the
fieldset
's
block-flow
direction,
whichever
is
greater.
For
the
purpose
of
calculating
the
used
'block-size'
,
if
the
computed
'block-size'
is
not
'auto',
the
space
allocated
for
the
rendered
legend
's
margin
box
that
spills
out
past
the
border,
if
any,
is
expected
to
be
substracted
from
the
'block-size'
.
If
the
content
box's
block-size
would
be
negative,
then
let
the
content
box's
block-size
be
zero
instead.
If
the
element
has
a
rendered
legend
,
then
that
element
is
expected
to
be
the
first
child
box.
For
the
purpose
of
calculating
the
min-content
inline
size,
use
the
greater
of
the
min-content
inline
size
of
the
rendered
legend
and
the
min-content
inline
size
of
the
anonymous
fieldset
content
box
.
For
the
purpose
of
calculating
the
max-content
inline
size,
use
the
greater
of
the
max-content
inline
size
of
the
rendered
legend
and
the
max-content
inline
size
of
the
anonymous
fieldset
content
box
.
The
element
is
expected
to
be
positioned
in
the
inline
direction
as
is
normal
for
blocks
(e.g.,
taking
into
account
margins
and
the
'justify-self'
property).
The
element's
box
is
expected
to
be
constrained
in
the
inline
direction
by
the
inline
content
size
of
the
fieldset
as
if
it
had
used
its
computed
inline
padding.
The
element
is
expected
to
be
positioned
in
the
block-flow
direction
such
that
its
border
box
is
centered
over
the
border
on
the
block-start
side
of
the
fieldset
element.
A
fieldset
element's
anonymous
fieldset
content
box
is
expected
to
act
as
follows:
The
'display'
property
is
expected
to
act
as
follows:
If
the
computed
value
of
'display'
on
the
fieldset
element
is
'grid'
or
'inline-grid',
then
set
the
used
value
to
'grid'.
If
the
computed
value
of
'display'
on
the
fieldset
element
is
'flex'
or
'inline-flex',
then
set
the
used
value
to
'flex'.
Otherwise,
set
the
used
value
to
'flow-root'.
The
following
properties
are
expected
to
inherit
from
the
fieldset
element:
The
'block-size'
property
is
expected
to
be
set
to
'100%'.
For
the
purpose
of
calculating
percentage
padding,
act
as
if
the
padding
was
calculated
for
the
fieldset
element.
The
legend
is
rendered
over
the
top
border,
and
the
top
border
area
reserves
vertical
space
for
the
legend.
The
fieldset's
top
margin
starts
at
the
top
margin
edge
of
the
legend.
The
legend's
horizontal
margins,
or
the
'justify-self'
property,
gives
its
horizontal
position.
The
anonymous
fieldset
content
box
appears
below
the
legend.
Whether
a
video
element
is
exposing
a
user
interface
is
not
expected
to
affect
the
size
of
the
rendering;
controls
are
expected
to
be
overlaid
above
the
page
content
without
causing
any
layout
changes,
and
are
expected
to
disappear
when
the
user
does
not
need
them.
When
a
video
element
represents
a
poster
frame
or
frame
of
video,
the
poster
frame
or
frame
of
video
is
expected
to
be
rendered
at
the
largest
size
that
maintains
the
aspect
ratio
of
that
poster
frame
or
frame
of
video
without
being
taller
or
wider
than
the
video
element
itself,
and
is
expected
to
be
centered
in
the
video
element.
User
agents
are
expected
to
render
img
elements
and
input
elements
whose
type
attributes
are
in
the
Image
Button
state,
according
to
the
first
applicable
rules
from
the
following
list:
The
user
agent
is
expected
to
treat
the
element
as
a
replaced
element
whose
content
is
the
text
that
the
element
represents,
if
any,
optionally
alongside
an
icon
indicating
that
the
image
is
being
obtained
(if
applicable).
For
input
elements,
the
element
is
expected
to
appear
button-like
to
indicate
that
the
element
is
a
button
.
If
the
element
is
an
img
element
that
represents
some
text
and
the
user
agent
does
not
expect
this
to
change
The
user
agent
is
expected
to
treat
the
element
as
a
non-replaced
phrasing
element
whose
content
is
the
text,
optionally
with
an
icon
indicating
that
an
image
is
missing,
so
that
the
user
can
request
the
image
be
displayed
or
investigate
why
it
is
not
rendering.
In
non-graphical
contexts,
such
an
icon
should
be
omitted.
If
the
element
is
an
img
element
that
represents
nothing
and
the
user
agent
does
not
expect
this
to
change
The
user
agent
is
expected
to
treat
the
element
as
an
empty
inline
element.
(In
the
absence
of
further
styles,
this
will
cause
the
element
to
essentially
not
be
rendered.)
If
the
element
is
an
input
element
that
does
not
represent
an
image
and
the
user
agent
does
not
expect
this
to
change
The
user
agent
is
expected
to
treat
the
element
as
a
replaced
element
consisting
of
a
button
whose
content
is
the
element's
alternative
text.
The
intrinsic
dimensions
of
the
button
are
expected
to
be
about
one
line
in
height
and
whatever
width
is
necessary
to
render
the
text
on
one
line.
The
icons
mentioned
above
are
expected
to
be
relatively
small
so
as
not
to
disrupt
most
text
but
be
easily
clickable.
In
a
visual
environment,
for
instance,
icons
could
be
16
pixels
by
16
pixels
square,
or
1em
by
1em
if
the
images
are
scalable.
In
an
audio
environment,
the
icon
could
be
a
short
bleep.
The
icons
are
intended
to
indicate
to
the
user
that
they
can
be
used
to
get
to
whatever
options
the
UA
provides
for
images,
and,
where
appropriate,
are
expected
to
provide
access
to
the
context
menu
that
would
have
come
up
if
the
user
interacted
with
the
actual
image.
All
animated
images
with
the
same
absolute
URL
and
the
same
image
data
are
expected
to
be
rendered
synchronized
to
the
same
timeline
as
a
group,
with
the
timeline
starting
at
the
time
of
the
least
recent
addition
to
the
group.
In
other
words,
when
a
second
image
with
the
same
absolute
URL
and
animated
image
data
is
inserted
into
a
document,
it
jumps
to
the
point
in
the
animation
cycle
that
is
currently
being
displayed
by
the
first
image.
When
a
user
agent
is
to
restart
the
animation
for
an
img
element
showing
an
animated
image,
all
animated
images
with
the
same
absolute
URL
and
the
same
image
data
in
that
img
element's
node
document
are
expected
to
restart
their
animation
from
the
beginning.
When
an
embed
,
iframe
,
img
,
or
object
element,
or
an
input
element
whose
type
attribute
is
in
the
Image
Button
state,
has
an
align
attribute
whose
value
is
an
ASCII
case-insensitive
match
for
the
string
"
center
"
or
the
string
"
middle
",
the
user
agent
is
expected
to
act
as
if
the
element's
'vertical-align'
property
was
set
to
a
value
that
aligns
the
vertical
middle
of
the
element
with
the
parent
element's
baseline.
Shapes
on
an
image
map
are
expected
to
act,
for
the
purpose
of
the
CSS
cascade,
as
elements
independent
of
the
original
area
element
that
happen
to
match
the
same
style
rules
but
inherit
from
the
img
or
object
element.
For
the
purposes
of
the
rendering,
only
the
'cursor'
property
is
expected
to
have
any
effect
on
the
shape.
Thus,
for
example,
if
an
area
element
has
a
style
attribute
that
sets
the
'cursor'
property
to
'help',
then
when
the
user
designates
that
shape,
the
cursor
would
change
to
a
Help
cursor.
Similarly,
if
an
area
element
had
a
CSS
rule
that
set
its
'cursor'
property
to
'inherit'
(or
if
no
rule
setting
the
'cursor'
property
matched
the
element
at
all),
the
shape's
cursor
would
be
inherited
from
the
img
or
object
element
of
the
image
map
,
not
from
the
parent
of
the
area
element.
14.5
Widgets
14.5.1
Introduction
The
elements
defined
in
this
section
can
be
rendered
in
a
variety
of
manners,
within
the
guidelines
provided
below.
User
agents
are
encouraged
to
set
the
'appearance'
CSS
property
appropriately
to
achieve
platform-native
appearances
for
widgets,
and
are
expected
to
implement
any
relevant
animations,
etc,
that
are
appropriate
for
the
platform.
14.5.2
Button
layout
Button
layout
is
as
follows:
The
'display'
property
is
expected
to
act
as
follows:
If
the
computed
value
of
'display'
is
'inline-grid',
'grid',
'inline-flex',
or
'flex',
then
behave
as
the
computed
value.
Otherwise,
if
the
computed
value
of
'display'
is
a
value
such
that
the
outer
display
type
is
'inline',
then
behave
as
'inline-block'.
Otherwise,
behave
as
'flow-root'.
The
element
is
expected
to
establish
a
new
formatting
context
for
its
contents.
The
type
of
this
formatting
context
is
determined
by
its
'display'
value,
as
usual.
For
the
purpose
of
the
'normal'
keyword
of
the
'align-self'
property,
act
as
if
the
element
is
a
replaced
element.
If
the
element
is
an
input
element,
or
if
it
is
a
button
element
and
its
computed
value
for
'display'
is
not
'inline-grid',
'grid',
'inline-flex',
or
'flex',
then
the
element's
box
has
a
child
anonymous
button
content
box
with
the
following
behaviors:
An
input
element
whose
type
attribute
is
in
the
Password
state
is
expected
to
render
as
an
'inline-block'
box
depicting
a
text
control
that
obscures
data
entry.
If
an
input
element
whose
type
attribute
is
in
one
of
the
above
states
does
not
have
a
size
attribute,
then
the
user
agent
is
expected
to
act
as
if
it
had
a
user-agent-level
style
sheet
rule
setting
the
'width'
property
on
the
element
to
the
value
obtained
from
applying
the
converting
a
character
width
to
pixels
algorithm
to
the
number
20.
The
converting
a
character
width
to
pixels
algorithm
returns
(
size
-1)×
avg
+
max
,
where
size
is
the
character
width
to
convert,
avg
is
the
average
character
width
of
the
primary
font
for
the
element
for
which
the
algorithm
is
being
run,
in
pixels,
and
max
is
the
maximum
character
width
of
that
same
font,
also
in
pixels.
(The
element's
'letter-spacing'
property
does
not
affect
the
result.)
14.5.6
The
input
element
as
domain-specific
widgets
When
the
control
is
wider
than
it
is
tall
(or
square),
the
control
is
expected
to
be
a
horizontal
slider,
with
the
lowest
value
on
the
right
if
the
'direction'
property
on
this
element
has
a
computed
value
of
'rtl',
and
on
the
left
otherwise.
When
the
control
is
taller
than
it
is
wide,
it
is
expected
to
be
a
vertical
slider,
with
the
lowest
value
on
the
bottom.
Predefined
suggested
values
(provided
by
the
list
attribute)
are
expected
to
be
shown
as
tick
marks
on
the
slider,
which
the
slider
can
snap
to.
User
agents
are
expected
to
use
the
used
value
of
the
'direction'
property
on
the
element
to
determine
the
direction
in
which
the
slider
operates.
Typically,
a
left-to-right
('ltr')
horizontal
control
would
have
the
lowest
value
on
the
left
and
the
highest
value
on
the
right,
and
vice
versa.
Predefined
suggested
values
(provided
by
the
list
attribute)
are
expected
to
be
shown
in
the
color
picker
interface,
not
on
the
color
well
itself.
14.5.9
The
input
element
as
a
checkbox
and
radio
button
widgets
An
input
element
whose
type
attribute
is
in
the
Checkbox
state
is
expected
to
render
as
an
'inline-block'
box
containing
a
single
checkbox
control,
with
no
label.
14.5.10
The
input
element
as
a
file
upload
control
An
input
element
whose
type
attribute
is
in
the
File
Upload
state,
when
it
generates
a
CSS
box
,
is
expected
to
render
as
an
'inline-block'
box
containing
a
span
of
text
giving
the
file
name(s)
of
the
selected
files
,
if
any,
followed
by
a
button
that,
when
activated,
provides
the
user
with
a
file
picker
from
which
the
selection
can
be
changed.
The
button
is
expected
to
use
button
layout
and
the
contents
of
the
anonymous
button
content
box
are
expected
to
be
user-agent-defined
(and
possibly
locale-specific)
text,
for
example
"Choose
file".
Slide
the
contents
of
the
element
in
the
direction
described
by
the
direction
attribute
as
defined
below,
such
that
it
begins
off
the
start
side
of
the
marquee
,
and
ends
flush
with
the
inner
end
side.
For
example,
if
the
direction
attribute
is
left
(the
default),
then
the
contents
would
start
such
that
their
left
edge
are
off
the
side
of
the
right
edge
of
the
marquee
's
content
area
,
and
the
contents
would
then
slide
up
to
the
point
where
the
left
edge
of
the
contents
are
flush
with
the
left
inner
edge
of
the
marquee
's
content
area
.
Slide
the
contents
of
the
element
in
the
direction
described
by
the
direction
attribute
as
defined
below,
such
that
it
begins
off
the
start
side
of
the
marquee
,
and
ends
off
the
end
side
of
the
marquee
.
For
example,
if
the
direction
attribute
is
left
(the
default),
then
the
contents
would
start
such
that
their
left
edge
are
off
the
side
of
the
right
edge
of
the
marquee
's
content
area
,
and
the
contents
would
then
slide
up
to
the
point
where
the
right
edge
of
the
contents
are
flush
with
the
left
inner
edge
of
the
marquee
's
content
area
.
When
the
marquee
current
loop
index
is
even
(or
zero),
slide
the
contents
of
the
element
in
the
direction
described
by
the
direction
attribute
as
defined
below,
such
that
it
begins
flush
with
the
start
side
of
the
marquee
,
and
ends
flush
with
the
end
side
of
the
marquee
.
When
the
marquee
current
loop
index
is
odd,
slide
the
contents
of
the
element
in
the
opposite
direction
than
that
described
by
the
direction
attribute
as
defined
below,
such
that
it
begins
flush
with
the
end
side
of
the
marquee
,
and
ends
flush
with
the
start
side
of
the
marquee
.
For
example,
if
the
direction
attribute
is
left
(the
default),
then
the
contents
would
with
their
right
edge
flush
with
the
right
inner
edge
of
the
marquee
's
content
area
,
and
the
contents
would
then
slide
up
to
the
point
where
the
left
edge
of
the
contents
are
flush
with
the
left
inner
edge
of
the
marquee
's
content
area
.
In
any
case,
the
animation
should
proceed
such
that
there
is
a
delay
given
by
the
marquee
scroll
interval
between
each
frame,
and
such
that
the
content
moves
at
most
the
distance
given
by
the
marquee
scroll
distance
with
each
frame.
When
the
element
is
wider
than
it
is
tall
(or
square),
the
depiction
is
expected
to
be
of
a
horizontal
gauge,
with
the
minimum
value
on
the
right
if
the
'direction'
property
on
this
element
has
a
computed
value
of
'rtl',
and
on
the
left
otherwise.
When
the
element
is
taller
than
it
is
wide,
it
is
expected
to
depict
a
vertical
gauge,
with
the
minimum
value
on
the
bottom.
User
agents
are
expected
to
use
a
presentation
consistent
with
platform
conventions
for
gauges,
if
any.
Requirements
for
what
must
be
depicted
in
the
gauge
are
included
in
the
definition
of
the
meter
element.
When
the
element
is
wider
than
it
is
tall,
the
element
is
expected
to
be
depicted
as
a
horizontal
progress
bar,
with
the
start
on
the
right
and
the
end
on
the
left
if
the
'direction'
property
on
this
element
has
a
computed
value
of
'rtl',
and
with
the
start
on
the
left
and
the
end
on
the
right
otherwise.
When
the
element
is
taller
than
it
is
wide,
it
is
expected
to
be
depicted
as
a
vertical
progress
bar,
with
the
lowest
value
on
the
bottom.
When
the
element
is
square,
it
is
expected
to
be
depicted
as
a
direction-independent
progress
widget
(e.g.
a
circular
progress
ring).
User
agents
are
expected
to
use
a
presentation
consistent
with
platform
conventions
for
progress
bars.
In
particular,
user
agents
are
expected
to
use
different
presentations
for
determinate
and
indeterminate
progress
bars.
User
agents
are
also
expected
to
vary
the
presentation
based
on
the
dimensions
of
the
element.
For
example,
on
some
platforms
for
showing
indeterminate
progress
there
is
a
"spinner"
progress
indicator
with
square
dimensions,
which
could
be
used
when
the
element
is
square,
and
an
indeterminate
progress
bar,
which
could
be
used
when
the
element
is
wide.
Requirements
for
how
to
determine
if
the
progress
bar
is
determinate
or
indeterminate,
and
what
progress
a
determinate
progress
bar
is
to
show,
are
included
in
the
definition
of
the
progress
element.
An
optgroup
element
is
expected
to
be
rendered
by
displaying
the
element's
label
attribute.
An
option
element
is
expected
to
be
rendered
by
displaying
the
element's
label
,
indented
under
its
optgroup
element
if
it
has
one.
The
width
of
the
select
's
labels
is
the
wider
of
the
width
necessary
to
render
the
widest
optgroup
,
and
the
width
necessary
to
render
the
widest
option
element
in
the
element's
list
of
options
(including
its
indent,
if
any).
If
a
select
element
contains
a
placeholder
label
option
,
the
user
agent
is
expected
to
render
that
option
in
a
manner
that
conveys
that
it
is
a
label,
rather
than
a
valid
option
of
the
control.
This
can
include
preventing
the
placeholder
label
option
from
being
explicitly
selected
by
the
user.
When
the
placeholder
label
option
's
selectedness
is
true,
the
control
is
expected
to
be
displayed
in
a
fashion
that
indicates
that
no
valid
option
is
currently
selected.
User
agents
are
expected
to
render
the
labels
in
a
select
in
such
a
manner
that
any
alignment
remains
consistent
whether
the
label
is
being
displayed
as
part
of
the
page
or
in
a
menu
control.
The
textarea
effective
width
of
a
textarea
element
is
size
×
avg
+
sbw
,
where
size
is
the
element's
character
width
,
avg
is
the
average
character
width
of
the
primary
font
of
the
element,
in
CSS
pixels
,
and
sbw
is
the
width
of
a
scrollbar,
in
CSS
pixels
.
(The
element's
'letter-spacing'
property
does
not
affect
the
result.)
User
agent
are
expected
to
render
frameset
elements
as
a
box
with
the
height
and
width
of
the
viewport
,
with
a
surface
rendered
according
to
the
following
layout
algorithm:
The
cols
and
rows
variables
are
lists
of
zero
or
more
pairs
consisting
of
a
number
and
a
unit,
the
unit
being
one
of
percentage
,
relative
,
and
absolute
.
Use
the
rules
for
parsing
a
list
of
dimensions
to
parse
the
value
of
the
element's
cols
attribute,
if
there
is
one.
Let
cols
be
the
result,
or
an
empty
list
if
there
is
no
such
attribute.
Use
the
rules
for
parsing
a
list
of
dimensions
to
parse
the
value
of
the
element's
rows
attribute,
if
there
is
one.
Let
rows
be
the
result,
or
an
empty
list
if
there
is
no
such
attribute.
For
any
of
the
entries
in
cols
or
rows
that
have
the
number
zero
and
the
unit
relative
,
change
the
entry's
number
to
one.
If
cols
has
no
entries,
then
add
a
single
entry
consisting
of
the
value
1
and
the
unit
relative
to
cols
.
If
rows
has
no
entries,
then
add
a
single
entry
consisting
of
the
value
1
and
the
unit
relative
to
rows
.
For
each
rectangle,
if
there
is
an
element
assigned
to
that
rectangle,
and
that
element
has
a
border
,
draw
an
inner
set
of
borders
around
that
rectangle,
using
the
element's
frame
border
color
.
For
each
(visible)
border
that
does
not
abut
a
rectangle
that
is
assigned
a
frame
element
with
a
noresize
attribute
(including
rectangles
in
further
nested
frameset
elements),
the
user
agent
is
expected
to
allow
the
user
to
move
the
border,
resizing
the
rectangles
within,
keeping
the
proportions
of
any
nested
frameset
grids.
A
frameset
or
frame
element
has
a
border
if
the
following
algorithm
returns
true:
If
the
element
has
a
frameborder
attribute
whose
value
is
not
the
empty
string
and
whose
first
character
is
either
a
U+0031
DIGIT
ONE
(1)
character,
a
U+0079
LATIN
SMALL
LETTER
Y
character
(y),
or
a
U+0059
LATIN
CAPITAL
LETTER
Y
character
(Y),
then
return
true.
Otherwise,
if
the
element
has
a
frameborder
attribute,
return
false.
Otherwise,
if
the
element
has
a
parent
element
that
is
a
frameset
element,
then
return
true
if
that
element
has
a
border
,
and
false
if
it
does
not.
Otherwise,
return
true.
The
frame
border
color
of
a
frameset
or
frame
element
is
the
color
obtained
from
the
following
algorithm:
If
the
element
has
a
bordercolor
attribute,
and
applying
the
rules
for
parsing
a
legacy
color
value
to
that
attribute's
value
does
not
result
in
an
error,
then
return
the
color
so
obtained.
Otherwise,
if
the
element
has
a
parent
element
that
is
a
frameset
element,
then
return
the
frame
border
color
of
that
element.
Otherwise,
return
gray.
The
algorithm
to
convert
a
list
of
dimensions
to
a
list
of
pixel
values
consists
of
the
following
steps:
Let
input
list
be
the
list
of
numbers
and
units
passed
to
the
algorithm.
Let
output
list
be
a
list
of
numbers
the
same
length
as
input
list
,
all
zero.
Entries
in
output
list
correspond
to
the
entries
in
input
list
that
have
the
same
position.
Let
input
dimension
be
the
size
passed
to
the
algorithm.
Let
count
percentage
be
the
number
of
entries
in
input
list
whose
unit
is
percentage
.
Let
total
percentage
be
the
sum
of
all
the
numbers
in
input
list
whose
unit
is
percentage
.
Let
count
relative
be
the
number
of
entries
in
input
list
whose
unit
is
relative
.
Let
total
relative
be
the
sum
of
all
the
numbers
in
input
list
whose
unit
is
relative
.
Let
count
absolute
be
the
number
of
entries
in
input
list
whose
unit
is
absolute
.
Let
total
absolute
be
the
sum
of
all
the
numbers
in
input
list
whose
unit
is
absolute
.
Let
remaining
space
be
the
value
of
input
dimension
.
If
total
absolute
is
greater
than
remaining
space
,
then
for
each
entry
in
input
list
whose
unit
is
absolute
,
set
the
corresponding
value
in
output
list
to
the
number
of
the
entry
in
input
list
multiplied
by
remaining
space
and
divided
by
total
absolute
.
Then,
set
remaining
space
to
zero.
Otherwise,
for
each
entry
in
input
list
whose
unit
is
absolute
,
set
the
corresponding
value
in
output
list
to
the
number
of
the
entry
in
input
list
.
Then,
decrement
remaining
space
by
total
absolute
.
If
total
percentage
multiplied
by
the
input
dimension
and
divided
by
100
is
greater
than
remaining
space
,
then
for
each
entry
in
input
list
whose
unit
is
percentage
,
set
the
corresponding
value
in
output
list
to
the
number
of
the
entry
in
input
list
multiplied
by
remaining
space
and
divided
by
total
percentage
.
Then,
set
remaining
space
to
zero.
Otherwise,
for
each
entry
in
input
list
whose
unit
is
percentage
,
set
the
corresponding
value
in
output
list
to
the
number
of
the
entry
in
input
list
multiplied
by
the
input
dimension
and
divided
by
100.
Then,
decrement
remaining
space
by
total
percentage
multiplied
by
the
input
dimension
and
divided
by
100.
For
each
entry
in
input
list
whose
unit
is
relative
,
set
the
corresponding
value
in
output
list
to
the
number
of
the
entry
in
input
list
multiplied
by
remaining
space
and
divided
by
total
relative
.
Return
output
list
.
User
agents
working
with
integer
values
for
frame
widths
(as
opposed
to
user
agents
that
can
lay
frames
out
with
subpixel
accuracy)
are
expected
to
distribute
the
remainder
first
to
the
last
entry
whose
unit
is
relative
,
then
equally
(not
proportionally)
to
each
entry
whose
unit
is
percentage
,
then
equally
(not
proportionally)
to
each
entry
whose
unit
is
absolute
,
and
finally,
failing
all
else,
to
the
last
entry.
User
agents
are
expected
to
allow
users
to
discover
the
destination
of
hyperlinks
and
of
forms
before
triggering
their
navigation
.
User
agents
are
expected
to
inform
the
user
of
whether
a
hyperlink
includes
hyperlink
auditing
,
and
to
let
them
know
at
a
minimum
which
domains
will
be
contacted
as
part
of
such
auditing.
User
agents
may
surface
hyperlinks
created
by
link
elements
in
their
user
interface.
While
link
elements
that
create
hyperlinks
will
match
the
:link
or
:visited
pseudo-classes
,
will
react
to
clicks
if
visible,
and
so
forth,
this
does
not
extend
to
any
browser
interface
constructs
that
expose
those
same
links.
Activating
a
link
through
the
browser's
interface,
rather
than
in
the
page
itself,
does
not
trigger
click
events
and
the
like.
User
agents
are
expected
to
expose
the
advisory
information
of
elements
upon
user
request,
and
to
make
the
user
aware
of
the
presence
of
such
information.
On
interactive
graphical
systems
where
the
user
can
use
a
pointing
device,
this
could
take
the
form
of
a
tooltip.
When
the
user
is
unable
to
use
a
pointing
device,
then
the
user
agent
is
expected
to
make
the
content
available
in
some
other
fashion,
e.g.
by
making
the
element
a
focusable
area
and
always
displaying
the
advisory
information
of
the
currently
focused
element,
or
by
showing
the
advisory
information
of
the
elements
under
the
user's
finger
on
a
touch
device
as
the
user
pans
around
the
screen.
U+000A
LINE
FEED
(LF)
characters
are
expected
to
cause
line
breaks
in
the
tooltip;
U+0009
CHARACTER
TABULATION
(tab)
characters
are
expected
to
render
as
a
nonzero
horizontal
shift
that
lines
up
the
next
glyph
with
the
next
tab
stop,
with
tab
stops
occurring
at
points
that
are
multiples
of
8
times
the
width
of
a
U+0020
SPACE
character.
For
example,
a
visual
user
agent
could
make
elements
with
a
title
attribute
focusable
,
and
could
make
any
focused
element
with
a
title
attribute
show
its
tooltip
under
the
element
while
the
element
has
focus.
This
would
allow
a
user
to
tab
around
the
document
to
find
all
the
advisory
text.
As
another
example,
a
screen
reader
could
provide
an
audio
cue
when
reading
an
element
with
a
tooltip,
with
an
associated
key
to
read
the
last
tooltip
for
which
a
cue
was
played.
14.7.3
Editing
hosts
The
current
text
editing
caret
(i.e.
the
active
range
,
if
it
is
empty
and
in
an
editing
host
),
if
any,
is
expected
to
act
like
an
inline
replaced
element
with
the
vertical
dimensions
of
the
caret
and
with
zero
width
for
the
purposes
of
the
CSS
rendering
model.
This
means
that
even
an
empty
block
can
have
the
caret
inside
it,
and
that
when
the
caret
is
in
such
an
element,
it
prevents
margins
from
collapsing
through
the
element.
14.7.4
Text
rendered
in
native
user
interfaces
User
agents
are
expected
to
honor
the
Unicode
semantics
of
text
that
is
exposed
in
user
interfaces,
for
example
supporting
the
bidirectional
algorithm
in
text
shown
in
dialogs,
title
bars,
pop-up
menus,
and
tooltips.
Text
from
the
contents
of
elements
is
expected
to
be
rendered
in
a
manner
that
honors
the
directionality
of
the
element
from
which
the
text
was
obtained.
Text
from
attributes
is
expected
to
be
rendered
in
a
manner
that
honours
the
directionality
of
the
attribute
.
Consider
the
following
markup,
which
has
Hebrew
text
asking
for
a
programming
language,
the
languages
being
text
for
which
a
left-to-right
direction
is
important
given
the
punctuation
in
some
of
their
names:
<p dir="rtl" lang="he">
<label>
בחר שפת תכנות:
<select>
<option dir="ltr">C++</option>
<option dir="ltr">C#</option>
<option dir="ltr">FreePascal</option>
<option dir="ltr">F#</option>
</select>
</label>
</p>
If
the
select
element
was
rendered
as
a
drop
down
box,
a
correct
rendering
would
ensure
that
the
punctuation
was
the
same
both
in
the
drop
down,
and
in
the
box
showing
the
current
selection.
The
directionality
of
attributes
depends
on
the
attribute
and
on
the
element's
dir
attribute,
as
the
following
example
demonstrates.
Consider
this
markup:
If
the
abbr
attributes
are
rendered,
e.g.
in
a
tooltip
or
other
user
interface,
the
first
will
have
a
left
parenthesis
(because
the
direction
is
'ltr'),
the
second
will
have
a
right
parenthesis
(because
the
direction
is
'rtl'),
and
the
third
will
have
a
right
parenthesis
(because
the
direction
is
determined
from
the
attribute
value
to
be
'rtl').
In
this
case,
if
the
user
agent
were
to
expose
the
data-abbr
attribute
in
the
user
interface
(e.g.
in
a
debugging
environment),
the
last
case
would
be
rendered
with
a
left
parenthesis,
because
the
direction
would
be
determined
from
the
element's
contents.
A
string
provided
by
a
script
(e.g.
the
argument
to
window.alert()
)
is
expected
to
be
treated
as
an
independent
set
of
one
or
more
bidirectional
algorithm
paragraphs
when
displayed,
as
defined
by
the
bidirectional
algorithm,
including,
for
instance,
supporting
the
paragraph-breaking
behavior
of
U+000A
LINE
FEED
(LF)
characters.
For
the
purposes
of
determining
the
paragraph
level
of
such
text
in
the
bidirectional
algorithm,
this
specification
does
not
provide
a
higher-level
override
of
rules
P2
and
P3.
[BIDI]
When
necessary,
authors
can
enforce
a
particular
direction
for
a
given
paragraph
by
starting
it
with
the
Unicode
U+200E
LEFT-TO-RIGHT
MARK
or
U+200F
RIGHT-TO-LEFT
MARK
characters.
Thus,
the
following
script:
alert('\u05DC\u05DE\u05D3
HTML
\u05D4\u05D9\u05D5\u05DD!')
...would
always
result
in
a
message
reading
"
למד LMTH היום!
"
(not
"
דמל HTML םויה!
"),
regardless
of
the
language
of
the
user
agent
interface
or
the
direction
of
the
page
or
any
of
its
elements.
For
a
more
complex
example,
consider
the
following
script:
/* Warning: this script does not handle right-to-left scripts correctly */
var s;
if (s = prompt('What is your name?')) {
alert(s + '! Ok, Fred, ' + s + ', and Wilma will get the car.');
}
When
the
user
enters
"
Kitty
",
the
user
agent
would
alert
"
Kitty!
Ok,
Fred,
Kitty,
and
Wilma
will
get
the
car.
".
However,
if
the
user
enters
"
لا أفهم
",
then
the
bidirectional
algorithm
will
determine
that
the
direction
of
the
paragraph
is
right-to-left,
and
so
the
output
will
be
the
following
unintended
mess:
"
لا أفهم! derF ,kO, لا أفهم, rac eht teg lliw amliW dna.
"
To
force
an
alert
that
starts
with
user-provided
text
(or
other
text
of
unknown
directionality)
to
render
left-to-right,
the
string
can
be
prefixed
with
a
U+200E
LEFT-TO-RIGHT
MARK
character:
var s;
if (s = prompt('What is your name?')) {
alert('\u200E' + s + '! Ok, Fred, ' + s + ', and Wilma will get the car.');
}
14.8
Print
media
User
agents
are
expected
to
allow
the
user
to
request
the
opportunity
to
obtain
a
physical
form
(or
a
representation
of
a
physical
form)
of
a
Document
.
For
example,
selecting
the
option
to
print
a
page
or
convert
it
to
PDF
format.
[PDF]
When
the
user
actually
obtains
a
physical
form
(or
a
representation
of
a
physical
form)
of
a
Document
,
the
user
agent
is
expected
to
create
a
new
rendering
of
the
Document
for
the
print
media.
14.9
Unstyled
XML
documents
HTML
user
agents
may,
in
certain
circumstances,
find
themselves
rendering
non-HTML
documents
that
use
vocabularies
for
which
they
lack
any
built-in
knowledge.
This
section
provides
for
a
way
for
user
agents
to
handle
such
documents
in
a
somewhat
useful
manner.
A
Document
is
an
unstyled
document
while
it
matches
the
following
conditions:
The
Document
has
no
author
style
sheets
(whether
referenced
by
HTTP
headers,
processing
instructions,
elements
like
link
,
inline
elements
like
style
,
or
any
other
mechanism).
None
of
the
elements
in
the
Document
have
any
registered
event
listeners.
An
unstyled
document
view
is
one
where
the
DOM
is
not
rendered
according
to
CSS
(which
would,
since
there
are
no
applicable
styles
in
this
context,
just
result
in
a
wall
of
text),
but
is
instead
rendered
in
a
manner
that
is
useful
for
a
developer.
This
could
consist
of
just
showing
the
Document
object's
source,
maybe
with
syntax
highlighting,
or
it
could
consist
of
displaying
just
the
DOM
tree,
or
simply
a
message
saying
that
the
page
is
not
a
styled
document.
If
a
Document
stops
being
an
unstyled
document
,
then
the
conditions
above
stop
applying,
and
thus
a
user
agent
following
these
requirements
will
switch
to
using
the
regular
CSS
rendering.
When
the
element
is
wider
than
it
is
tall,
the
element
is
expected
to
be
depicted
as
a
horizontal
progress
bar,
with
the
start
on
the
right
and
the
end
on
the
left
if
the
'direction'
property
on
this
element
has
a
computed
value
of
'rtl',
and
with
the
start
on
the
left
and
the
end
on
the
right
otherwise.
When
the
element
is
taller
than
it
is
wide,
it
is
expected
to
be
depicted
as
a
vertical
progress
bar,
with
the
lowest
value
on
the
bottom.
When
the
element
is
square,
it
is
expected
to
be
depicted
as
a
direction-independent
progress
widget
(e.g.
a
circular
progress
ring).
