hidden
attribute
contenteditable
content
attribute
designMode
IDL
attribute
inputmode
attribute
hidden
attribute
Support:
hidden
Chrome
for
Android
64+
66+
Chrome
6+
iOS
Safari
5.0+
UC
Browser
for
Android
11.8+
Firefox
4+
IE
11+
Opera
Mini
all+
Samsung
Internet
4+
Safari
5.1+
Edge
12+
Android
Browser
4+
Opera
11.1+
Source: caniuse.com
All using the rules suggested in the Rendering section .
may have the content attribute set. The attribute is a . When specified on an element, it indicates that the element is not yet, or is no longer, directly relevant to the page's current state, or that it is being used to declare content to be reused by other parts of the page as opposed to being directly accessed by the user. User agents should not render elements that have the attribute specified. This requirement may be implemented indirectly through the style layer. For example, an HTML+CSS user agent could implement these requirementsBecause this attribute is typically implemented using CSS, it's also possible to override it using CSS. For instance, a rule that applies 'display: block' to all elements will cancel the effects of the
attribute. Authors therefore have to take care when writing their style sheets to make sure that the attribute is still styled as expected.In the following skeletal example, the attribute is used to hide the Web game's main screen until the user logs in:
<h1>The Example Game</h1> <section id="login"> <h2>Login</h2> <form> ... <!-- calls login() once the user's credentials have been checked --> </form> <script> function login() { // switch screens document.getElementById('login').hidden = true; document.getElementById('game').hidden = false; } </script> </section> <section id="game" hidden> ... </section>
The
attribute must not be used to hide content that could legitimately be shown in another presentation. For example, it is incorrect to use to hide panels in a tabbed dialog, because the tabbed interface is merely a kind of overflow presentation — one could equally well just show all the form controls in one big page with a scrollbar. It is similarly incorrect to use this attribute to hide content just from one presentation — if something is marked , it is hidden from all presentations, including, for instance, screen readers.
Elements
that
are
not
themselves
for
attributes
of
and
elements
that
are
not
themselves
must
similarly
not
refer
to
elements
that
are
.
In
both
cases,
such
references
would
cause
user
confusion.
Elements and scripts may, however, refer to elements that are
in other contexts.For example, it would be incorrect to use the
attribute to link to a section marked with the attribute. If the content is not applicable or relevant, then there is no reason to link to it.It would be fine, however, to use the ARIA
attribute to refer to descriptions that are themselves . While hiding the descriptions implies that they are not useful alone, they could be written in such a way that they are useful in the specific context of being referenced from the images that they describe.Similarly, a
element with the attribute could be used by a scripted graphics engine as an off-screen buffer, and a form control could refer to a hidden element using its attribute.Elements in a section hidden by the
attribute are still active, e.g. scripts and form controls in such sections still execute and submit respectively. Only their presentation to the user changes.
The
hidden
IDL
attribute
must
the
content
attribute
of
the
same
name.
This section does not define or create any content attribute named "inert". This section merely defines an abstract concept of inertness .
A node (in particular elements and text nodes) can be marked as inert . When a node is inert , then the user agent must act as if the node was absent for the purposes of targeting user interaction events, may ignore the node for the purposes of text search user interfaces (commonly known as "find in page"), and may prevent the user from selecting text in that node. User agents should allow the user to override the restrictions on search and text selection, however.
For
example,
consider
a
page
that
consists
of
just
a
single
inert
paragraph
positioned
in
the
middle
of
a
body
.
If
a
user
moves
their
pointing
device
from
the
body
over
to
the
inert
paragraph
and
clicks
on
the
paragraph,
no
mouseover
event
would
be
fired,
and
the
mousemove
and
click
events
would
be
fired
on
the
body
element
rather
than
the
paragraph.
When a node is inert, it generally cannot be focused. Inert nodes that are commands will also get disabled.
While
a
browsing
context
container
is
marked
as
inert
,
its
nested
browsing
context
's
active
document
,
and
all
nodes
in
that
Document
,
must
be
marked
as
inert
.
A
Document
document
is
blocked
by
a
modal
dialog
subject
if
subject
is
the
topmost
dialog
element
in
document
's
top
layer
.
While
document
is
so
blocked,
every
node
that
is
connected
to
document
,
with
the
exception
of
the
subject
element
and
its
shadow-including
descendants
,
must
be
marked
inert
.
(The
elements
excepted
by
this
paragraph
can
additionally
be
marked
inert
through
other
means;
being
part
of
a
modal
dialog
does
not
"protect"
a
node
from
being
marked
inert
.)
The
dialog
element's
showModal()
method
causes
this
mechanism
to
trigger,
by
adding
the
dialog
element
to
its
node
document
's
top
layer
.
Certain
elements
in
HTML
have
an
activation
behavior
,
which
means
that
the
user
can
activate
them.
This
is
always
caused
by
a
click
event.
The
user
agent
should
allow
the
user
to
manually
trigger
elements
that
have
an
activation
behavior
,
for
instance
using
keyboard
or
voice
input,
or
through
mouse
clicks.
When
the
user
triggers
an
element
with
a
defined
activation
behavior
in
a
manner
other
than
clicking
it,
the
default
action
of
the
interaction
event
must
be
to
fire
a
click
event
at
the
element.
An algorithm is triggered by user activation if any of the following conditions is true:
The
task
in
which
the
algorithm
is
running
is
currently
processing
an
activation
behavior
whose
click
event's
isTrusted
attribute
is
true.
The
task
in
which
the
algorithm
is
running
is
currently
running
the
event
listener
for
an
event
whose
isTrusted
attribute
is
true
and
whose
type
is
one
of:
The task in which the algorithm is running was queued by an algorithm that was triggered by user activation , and the chain of such algorithms started within a user-agent defined timeframe.
For example, if a user clicked a button, it might be acceptable for a popup to result from that after 4 seconds, but it would likely not be acceptable for a popup to result from that after 4 hours.
click
()
Acts as if the element was clicked.
Each element has an associated click in progress flag , which is initially unset.
The
click()
method
must
run
the
following
steps:
If this element is a form control that is disabled , then return.
If this element's click in progress flag is set, then return.
Set this element's click in progress flag .
Fire a synthetic mouse event at this element, with the not trusted flag set.
Unset this element's click in progress flag .
This section is non-normative.
An HTML user interface typically consists of multiple interactive widgets, such as form controls, scrollable regions, links, dialog boxes, browser tabs, and so forth. These widgets form a hierarchy, with some (e.g. browser tabs, dialog boxes) containing others (e.g. links, form controls).
When interacting with an interface using a keyboard, key input is channeled from the system, through the hierarchy of interactive widgets, to an active widget, which is said to be focused .
Consider an HTML application running in a browser tab running in a graphical environment. Suppose this application had a page with some text controls and links, and was currently showing a modal dialog, which itself had a text control and a button.
The hierarchy of focusable widgets, in this scenario, would include the browser window, which would have, amongst its children, the browser tab containing the HTML application. The tab itself would have as its children the various links and text controls, as well as the dialog. The dialog itself would have as its children the text control and the button.
If the widget with focus in this example was the text control in the dialog box, then key input would be channeled from the graphical system to ① the Web browser, then to ② the tab, then to ③ the dialog, and finally to ④ the text control.
Keyboard events are always targeted at this focused element.
The term focusable area is used to refer to regions of the interface that can become the target of keyboard input. Focusable areas can be elements, parts of elements, or other regions managed by the user agent.
Each
focusable
area
has
a
DOM
anchor
,
which
is
a
Node
object
that
represents
the
position
of
the
focusable
area
in
the
DOM.
(When
the
focusable
area
is
itself
a
Node
,
it
is
its
own
DOM
anchor
.)
The
DOM
anchor
is
used
in
some
APIs
as
a
substitute
for
the
focusable
area
when
there
is
no
other
DOM
object
to
represent
the
focusable
area
.
The following table describes what objects can be focusable areas . The cells in the left column describe objects that can be focusable areas ; the cells in the right column describe the DOM anchors for those elements. (The cells that span both columns are non-normative examples.)
Focusable area | DOM anchor |
---|---|
Examples | |
Elements that have their tabindex focus flag set, that are not actually disabled , that are not expressly inert , and that are either being rendered or being used as relevant canvas fallback content . | The element itself. |
|
|
The
shapes
of
area
elements
in
an
image
map
associated
with
an
img
element
that
is
being
rendered
and
is
not
expressly
inert
.
|
The
img
element.
|
In
the
following
example,
the
<map id=wallmap><area alt="Enter Door" coords="10,10,100,200" href="door.html"></map> ... <img src="images/innerwall.jpeg" alt="There is a white wall here, with a door." usemap="#wallmap"> ... <img src="images/outerwall.jpeg" alt="There is a red wall here, with a door." usemap="#wallmap"> |
|
The user-agent provided subwidgets of elements that are being rendered and are not actually disabled or expressly inert . | The element for which the focusable area is a subwidget. |
The
controls
in
the
user
interface
that
is
exposed
to
the
user
for
a
|
|
The scrollable regions of elements that are being rendered and are not expressly inert . | The element for which the box that the scrollable region scrolls was created. |
The CSS 'overflow' property's 'scroll' value typically creates a scrollable region. |
|
The
viewport
of
a
Document
that
has
a
browsing
context
and
is
not
inert
.
|
The
Document
for
which
the
viewport
was
created.
|
The
contents
of
an
|
|
Any other element or part of an element, especially to aid with accessibility or to better match platform conventions. | The element. |
A user agent could make all list item bullets focusable, so that a user can more easily navigate lists.
Similarly,
a
user
agent
could
make
all
elements
with
|
A
browsing
context
container
(e.g.
an
iframe
)
is
a
focusable
area
,
but
key
events
routed
to
a
browsing
context
container
get
immediately
routed
to
the
nested
browsing
context
's
active
document
.
Similarly,
in
sequential
focus
navigation
a
browsing
context
container
essentially
acts
merely
as
a
placeholder
for
its
nested
browsing
context
's
active
document
.
The following create control groups :
Document
object
that
have
browsing
contexts
.
dialog
elements
that
have
an
open
attribute
specified
and
that
are
being
rendered
.
The
corresponding
Document
object
or
dialog
element
is
the
created
control
group
's
owner
object
.
(There
is
always
a
1-to-1
mapping
of
control
groups
to
control
group
owner
objects
.)
Each focusable area belongs to a single control group as follows. If the DOM anchor of a focusable area is a control group owner object , then that focusable area belongs to that control group owner object 's control group . Otherwise, the focusable area belongs to its DOM anchor 's nearest ancestor control group owner object 's control group .
Thus:
A
viewport
always
belongs
to
the
control
group
of
the
Document
for
which
the
viewport
was
created.
An
input
control
belongs
to
the
control
group
of
its
nearest
ancestor
dialog
or
Document
.
An
image
map's
shapes
belong
to
the
nearest
ancestor
dialog
or
Document
of
the
img
elements
(not
the
area
elements
—
this
means
one
area
element
might
create
multiple
shapes
in
different
control
groups
).
It is possible for a control group to be empty, i.e. for it to have no focusable areas .
An element is expressly inert if it is inert and its nearest ancestor control group owner object is not inert .
In
a
page
with
no
dialog
elements,
all
elements
that
are
inert
are
expressly
inert
,
and
vice-versa.
Inside
an
inert
dialog
element,
all
descendant
elements
are
not
expressly
inert
,
even
if
they
are
inert
.
A
dialog
element
is
expressly
inert
if
it
is
inert
and
not
nested
inside
another
inert
dialog.
One focusable area in each non-empty control group is designated the focused area of the control group . Which control is so designated changes over time, based on algorithms in this specification. If a control group is empty, it has no focused area .
Focusable areas in control groups are ordered relative to the tree order of their DOM anchors . Focusable areas with the same DOM anchor in a control group are ordered relative to their CSS box's relative positions in a pre-order, depth-first traversal of the box tree. [CSS]
The
currently
focused
area
of
a
top-level
browsing
context
at
any
particular
time
is
the
focusable
area
or
dialog
returned
by
this
algorithm:
Let
candidate
be
the
Document
of
the
top-level
browsing
context
.
If candidate has a non-empty control group , and the designated focused area of the control group is a browsing context container with a non-null nested browsing context , then let candidate be the active document of that browsing context container 's nested browsing context , and redo this step.
Otherwise, if candidate has a non-empty control group , let candidate be the designated focused area of the control group .
Return candidate .
An element that is the DOM anchor of a focusable area is said to gain focus when that focusable area becomes the currently focused area of a top-level browsing context . When an element is the DOM anchor of a focusable area of the currently focused area of a top-level browsing context , it is focused .
The focus chain of a focusable area or control group owner object subject is the ordered list constructed as follows:
Let current object be subject .
Let output be an empty list.
Loop : Append current object to output .
If
current
object
is
an
area
element's
shape,
append
that
area
element
to
output
.
Otherwise, if current object is a focusable area whose DOM anchor is an element that is not current object itself, append that DOM anchor element to output .
If current object is a focusable area , let current object be that focusable area 's control group 's owner object , and return to the step labeled loop .
Otherwise,
if
current
object
is
a
Document
in
a
nested
browsing
context
,
let
current
object
be
its
browsing
context
container
,
and
return
to
the
step
labeled
loop
.
Return output .
The
chain
starts
with
subject
and
(if
subject
is
or
can
be
the
currently
focused
area
of
a
top-level
browsing
context
)
continues
up
the
focus
hierarchy
up
to
the
Document
of
the
top-level
browsing
context
.
tabindex
attribute
The
tabindex
content
attribute
allows
authors
to
indicate
that
an
element
is
supposed
to
be
focusable
,
and
whether
it
is
supposed
to
be
reachable
using
sequential
focus
navigation
and,
if
so,
what
is
to
be
the
relative
order
of
the
element
for
the
purposes
of
sequential
focus
navigation.
The
name
"tab
index"
comes
from
the
common
use
of
the
"tab"
key
to
navigate
through
the
focusable
elements.
The
term
"tabbing"
refers
to
moving
forward
through
the
focusable
elements
that
can
be
reached
using
sequential
focus
navigation.
Support:
tabindex-attr
Chrome
for
Android
64+
66+
Chrome
15+
iOS
Safari
3.2+
Firefox
4+
IE
7+
Safari
5.1+
Edge
12+
Opera
9.5+
Source: caniuse.com
When the attribute is omitted, the user agent applies defaults. (There is no way to make an element that is being rendered be not focusable at all without disabling it or making it inert .)
The
tabindex
attribute,
if
specified,
must
have
a
value
that
is
a
valid
integer
.
Positive
numbers
specify
the
relative
position
of
the
element's
focusable
areas
in
the
sequential
focus
navigation
order
,
and
negative
numbers
indicate
that
the
control
is
to
be
unreachable
by
sequential
focus
navigation
.
Developers
should
use
caution
when
using
values
other
than
0
or
−1
for
their
tabindex
attributes
as
this
is
complicated
to
do
correctly.
Each element can have a tabindex focus flag set, as defined below. This flag is a factor that contributes towards determining whether an element is a focusable area , as described in the previous section.
If
the
tabindex
attribute
is
specified
on
an
element,
it
must
be
parsed
using
the
rules
for
parsing
integers
.
The
attribute's
values,
or
lack
thereof,
must
be
interpreted
as
follows:
The user agent should follow platform conventions to determine if the element's tabindex focus flag is set and, if so, whether the element and any focusable areas that have the element as their DOM anchor can be reached using sequential focus navigation , and if so, what their relative position in the sequential focus navigation order is to be.
Modulo platform conventions, it is suggested that for the following elements, the tabindex focus flag be set:
a
elements
that
have
an
href
attribute
link
elements
that
have
an
href
attribute
button
elements
input
elements
whose
type
attribute
are
not
in
the
state
select
elements
textarea
elements
summary
elements
that
are
the
first
summary
element
child
of
a
details
element
draggable
attribute
set,
if
that
would
enable
the
user
agent
to
allow
the
user
to
begin
a
drag
operations
for
those
elements
without
the
use
of
a
pointing
device
The user agent must set the element's tabindex focus flag , but should omit the element from the sequential focus navigation order .
One
valid
reason
to
ignore
the
requirement
that
sequential
focus
navigation
not
allow
the
author
to
lead
to
the
element
would
be
if
the
user's
only
mechanism
for
moving
the
focus
is
sequential
focus
navigation.
For
instance,
a
keyboard-only
user
would
be
unable
to
click
on
a
text
control
with
a
negative
tabindex
,
so
that
user's
user
agent
would
be
well
justified
in
allowing
the
user
to
tab
to
the
control
regardless.
The user agent must set the element's tabindex focus flag , should allow the element and any focusable areas that have the element as their DOM anchor to be reached using sequential focus navigation , following platform conventions to determine the element's relative position in the sequential focus navigation order .
The user agent must set the element's tabindex focus flag , should allow the element and any focusable areas that have the element as their DOM anchor to be reached using sequential focus navigation, and should place the element — referenced as candidate below — and the aforementioned focusable areas in the sequential focus navigation order so that, relative to other focusable areas in the sequential focus navigation order , they are:
tabindex
attribute
has
been
omitted
or
whose
value,
when
parsed,
returns
an
error,
tabindex
attribute
has
a
value
equal
to
or
less
than
zero,
tabindex
attribute
has
a
value
greater
than
zero
but
less
than
the
value
of
the
tabindex
attribute
on
candidate
,
tabindex
attribute
has
a
value
equal
to
the
value
of
the
tabindex
attribute
on
candidate
but
that
is
earlier
in
the
document
in
tree
order
than
candidate
,
tabindex
attribute
has
a
value
equal
to
the
value
of
the
tabindex
attribute
on
candidate
but
that
is
later
in
the
document
in
tree
order
than
candidate
,
and
tabindex
attribute
has
a
value
greater
than
the
value
of
the
tabindex
attribute
on
candidate
.
An
element
with
the
tabindex
attribute
specified
is
interactive
content
.
The
tabIndex
IDL
attribute
must
reflect
the
value
of
the
tabindex
content
attribute.
Its
default
value
is
0
for
elements
that
are
focusable
and
−1
for
elements
that
are
not
focusable.
The focusing steps for an object new focus target that is either a focusable area , or an element that is not a focusable area , or a browsing context , are as follows. They can optionally be run with a fallback target .
If
new
focus
target
is
neither
a
dialog
element
that
has
an
open
attribute
specified
and
that
is
being
rendered
(i.e.
that
is
a
control
group
owner
object
),
nor
a
focusable
area
,
then
run
the
first
matching
set
of
steps
from
the
following
list:
area
element
with
one
or
more
shapes
that
are
focusable
areas
Let
new
focus
target
be
the
shape
corresponding
to
the
first
img
element
in
tree
order
that
uses
the
image
map
to
which
the
area
element
belongs.
Let new focus target be the element's first scrollable region, according to a pre-order, depth-first traversal of the box tree. [CSS]
Document
Let new focus target be the browsing context 's active document .
Let new focus target be the browsing context container 's nested browsing context 's active document .
If no fallback target was specified, abort the focusing steps .
Otherwise, let new focus target be the fallback target .
If new focus target is a control group owner object that is not a focusable area , and its control group is not empty, then designate new focus target as the focused area of the control group , and redo this step.
Otherwise, if new focus target is a browsing context container with non-null nested browsing context , then let new focus target be the nested browsing context 's active document , and redo this step.
A
dialog
element
can
be
both
a
control
group
owner
object
and
a
focusable
area
,
if
it
has
both
an
open
attribute
specified
and
a
tabindex
attribute
specified
and
is
being
rendered
.
If new focus target is a focusable area and its DOM anchor is inert , then return.
If new focus target is the currently focused area of a top-level browsing context , then return.
Let old chain be the focus chain of the currently focused area of the top-level browsing context in which new focus target finds itself.
Let new chain be the focus chain of new focus target .
Run the focus update steps with old chain , new chain , and new focus target respectively.
User
agents
must
immediately
run
the
focusing
steps
for
a
focusable
area
,
dialog
,
or
browsing
context
candidate
whenever
the
user
attempts
to
move
the
focus
to
candidate
.
The unfocusing steps for an object old focus target that is either a focusable area or an element that is not a focusable area are as follows:
If old focus target is inert , then return.
If
old
focus
target
is
an
area
element
and
one
of
its
shapes
is
the
currently
focused
area
of
a
top-level
browsing
context
,
or,
if
old
focus
target
is
an
element
with
one
or
more
scrollable
regions,
and
one
of
them
is
the
currently
focused
area
of
a
top-level
browsing
context
,
then
let
old
focus
target
be
that
currently
focused
area
of
a
top-level
browsing
context
.
Let old chain be the focus chain of the currently focused area of a top-level browsing context .
If old focus target is not one of the entries in old chain , then return.
If
old
focus
target
is
a
focusable
area
,
then
let
new
focus
target
be
the
first
focusable
area
of
its
control
group
(if
the
control
group
owner
object
is
a
Document
,
this
will
always
be
a
viewport
).
Otherwise, let new focus target be null.
If new focus target is not null, then run the focusing steps for new focus target .
When the currently focused area of a top-level browsing context is somehow unfocused without another element being explicitly focused in its stead, the user agent must immediately run the unfocusing steps for that object.
The unfocusing steps do not always result in the focus changing, even when applied to the currently focused area of a top-level browsing context . For example, if the currently focused area of a top-level browsing context is a viewport , then it will usually keep its focus regardless until another focusable area is explicitly focused with the focusing steps .
When a focusable area is added to an empty control group , it must be designated the focused area of the control group .
Focus fixup rule : When the designated focused area of a control group is removed from that control group in some way (e.g. it stops being a focusable area , it is removed from the DOM, it becomes expressly inert , etc), and the control group is still not empty: designate the first non- inert focusable area in that control group to be the new focused area of the control group , if any; if they are all inert , then designate the first focusable area in that control group to be the new focused area of the control group regardless of inertness . If such a removal instead results in the control group being empty, then there is simply no longer a focused area of the control group .
For
example,
this
might
happen
because
an
element
is
removed
from
its
Document
,
or
has
a
attribute
added.
It
might
also
happen
to
an
input
element
when
the
element
gets
disabled
.
In
a
Document
without
dialog
elements,
whose
focused
area
is
a
button
element,
removing,
disabling,
or
hiding
that
button
would
cause
the
page's
new
focused
area
to
be
the
viewport
of
the
Document
.
This
would,
in
turn,
be
reflected
through
the
activeElement
API
as
the
body
element
.
The focus update steps , given an old chain , a new chain , and a new focus target respectively, are as follows:
If the last entry in old chain and the last entry in new chain are the same, pop the last entry from old chain and the last entry from new chain and redo this step.
For each entry entry in old chain , in order, run these substeps:
If
entry
is
an
input
element,
and
the
change
event
applies
to
the
element,
and
the
element
does
not
have
a
defined
activation
behavior
,
and
the
user
has
changed
the
element's
value
or
its
list
of
selected
files
while
the
control
was
focused
without
committing
that
change
(such
that
it
is
different
to
what
it
was
when
the
control
was
first
focused),
then
fire
an
event
named
change
at
the
element,
with
the
bubbles
attribute
initialized
to
true.
If entry is an element, let blur event target be entry .
If
entry
is
a
Document
object,
let
blur
event
target
be
that
Document
object's
Window
object.
Otherwise, let blur event target be null.
If
entry
is
the
last
entry
in
old
chain
,
and
entry
is
an
Element
,
and
the
last
entry
in
new
chain
is
also
an
Element
,
then
let
related
blur
target
be
the
last
entry
in
new
chain
.
Otherwise,
let
related
blur
target
be
null.
If
blur
event
target
is
not
null,
fire
a
focus
event
named
blur
at
blur
event
target
,
with
related
blur
target
as
the
related
target.
In
some
cases,
e.g.
if
entry
is
an
area
element's
shape,
a
scrollable
region,
or
a
viewport
,
no
event
is
fired.
Apply any relevant platform-specific conventions for focusing new focus target . (For example, some platforms select the contents of a text control when that control is focused.)
For each entry entry in new chain , in reverse order, run these substeps:
If entry is a focusable area : designate entry as the focused area of the control group .
It
is
possible
for
entry
to
be
both
a
dialog
element
and
a
focusable
area
,
in
which
case
it
is
its
own
control
group
owner
object
.
If entry is an element, let focus event target be entry .
If
entry
is
a
Document
object,
let
focus
event
target
be
that
Document
object's
Window
object.
Otherwise, let focus event target be null.
If
entry
is
the
last
entry
in
new
chain
,
and
entry
is
an
Element
,
and
the
last
entry
in
old
chain
is
also
an
Element
,
then
let
related
focus
target
be
the
last
entry
in
old
chain
.
Otherwise,
let
related
focus
target
be
null.
If
focus
event
target
is
not
null,
fire
a
focus
event
named
focus
at
focus
event
target
,
with
related
focus
target
as
the
related
target.
In
some
cases,
e.g.
if
entry
is
an
area
element's
shape,
a
scrollable
region,
or
a
viewport
,
no
event
is
fired.
To
fire
a
focus
event
named
e
at
an
element
t
with
a
given
related
target
r
,
fire
an
event
named
e
at
t
,
using
FocusEvent
,
with
the
relatedTarget
attribute
initialized
to
r
,
the
view
attribute
initialized
to
t
's
node
document
's
Window
object,
and
the
composed
flag
set.
When a key event is to be routed in a top-level browsing context , the user agent must run the following steps:
Let target area be the currently focused area of the top-level browsing context .
If
target
area
is
a
focusable
area
,
let
target
node
be
target
area
's
DOM
anchor
.
Otherwise,
target
area
is
a
dialog
;
let
target
node
be
target
area
.
If
target
node
is
a
Document
that
has
a
body
element
,
then
let
target
node
be
the
body
element
of
that
Document
.
Otherwise,
if
target
node
is
a
Document
object
that
has
a
non-null
document
element
,
then
let
target
node
be
that
document
element
.
If target node is not inert , then:
It
is
possible
for
the
currently
focused
area
of
a
top-level
browsing
context
to
be
inert
,
for
example
if
a
modal
dialog
is
shown
,
and
then
that
dialog
element
is
made
inert
.
It
is
likely
to
be
the
result
of
a
logic
error
in
the
application,
though.
Let canHandle be the result of dispatching the key event at target node .
If
canHandle
is
true,
then
let
target
area
handle
the
key
event.
This
might
include
firing
a
click
event
at
target
node
.
The
has
focus
steps
,
given
a
Document
object
target
,
are
as
follows:
Let
candidate
be
the
Document
of
the
top-level
browsing
context
.
If candidate is target , return true.
If candidate has a non-empty control group , and the designated focused area of the control group is a browsing context container with a non-null nested browsing context , and the active document of that browsing context container 's nested browsing context is target , then return true.
Otherwise, if candidate has a non-empty control group , and the designated focused area of the control group is a browsing context container with a non-null nested browsing context , then let candidate be the active document of that browsing context container 's nested browsing context , and redo this step.
Otherwise, return false.
Each control group has a sequential focus navigation order , which orders some or all of the focusable areas in the control group relative to each other. The order in the sequential focus navigation order does not have to be related to the order in the control group itself. If a focusable area is omitted from the sequential focus navigation order of its control group , then it is unreachable via sequential focus navigation .
There can also be a sequential focus navigation starting point . It is initially unset. The user agent may set it when the user indicates that it should be moved.
For example, the user agent could set it to the position of the user's click if the user clicks on the document contents.
When the user requests that focus move from the currently focused area of a top-level browsing context to the next or previous focusable area (e.g. as the default action of pressing the tab key), or when the user requests that focus sequentially move to a top-level browsing context in the first place (e.g. from the browser's location bar), the user agent must use the following algorithm:
Let starting point be the currently focused area of a top-level browsing context , if the user requested to move focus sequentially from there, or else the top-level browsing context itself, if the user instead requested to move focus from outside the top-level browsing context .
If there is a sequential focus navigation starting point defined and it is inside starting point , then let starting point be the sequential focus navigation starting point instead.
Let direction be forward if the user requested the next control, and backward if the user requested the previous control.
Typically, pressing tab requests the next control, and pressing shift + tab requests the previous control.
Loop : Let selection mechanism be sequential if the starting point is a browsing context or if starting point is in its control group 's sequential focus navigation order .
Otherwise, starting point is not in its control group 's sequential focus navigation order ; let selection mechanism be DOM .
Let candidate be the result of running the sequential navigation search algorithm with starting point , direction , and selection mechanism as the arguments.
If candidate is not null, then run the focusing steps for candidate and return.
Otherwise, unset the sequential focus navigation starting point .
If starting point is the top-level browsing context , or a focusable area in the top-level browsing context , the user agent should transfer focus to its own controls appropriately (if any), honouring direction , and then return.
For example, if direction is backward , then the last focusable control before the browser's rendering area would be the control to focus.
If the user agent has no focusable controls — a kiosk-mode browser, for instance — then the user agent may instead restart these steps with the starting point being the top-level browsing context itself.
Otherwise, starting point is a focusable area in a nested browsing context . Let starting point be that nested browsing context 's browsing context container , and return to the step labeled loop .
The sequential navigation search algorithm consists of the following steps. This algorithm takes three arguments: starting point , direction , and selection mechanism .
Pick the appropriate cell from the following table, and follow the instructions in that cell.
The appropriate cell is the one that is from the column whose header describes direction and from the first row whose header describes starting point and selection mechanism .
direction is forward | direction is backward | |
---|---|---|
starting point is a browsing context | Let candidate be the first suitable sequentially focusable area in starting point 's active document 's control group , if any; or else null | Let candidate be the last suitable sequentially focusable area in starting point 's active document 's control group , if any; or else null |
selection mechanism is DOM | Let candidate be the first suitable sequentially focusable area in the home control group following starting point , if any; or else null | Let candidate be the last suitable sequentially focusable area in the home control group preceding starting point , if any; or else null |
selection mechanism is sequential | Let candidate be the first suitable sequentially focusable area in the home sequential focus navigation order following starting point , if any; or else null | Let candidate be the last suitable sequentially focusable area in the home sequential focus navigation order preceding starting point , if any; or else null |
A suitable sequentially focusable area is a focusable area whose DOM anchor is not inert and that is in its control group 's sequential focus navigation order .
The home control group is the control group to which starting point belongs.
The home sequential focus navigation order is the sequential focus navigation order to which starting point belongs.
The home sequential focus navigation order is the home control group 's sequential focus navigation order , but is only used when the starting point is in that sequential focus navigation order (when it's not, selection mechanism will be DOM ).
If candidate is a browsing context container with a non-null nested browsing context , then let new candidate be the result of running the sequential navigation search algorithm with candidate 's nested browsing context as the first argument, direction as the second, and sequential as the third.
If new candidate is null, then let starting point be candidate , and return to the top of this algorithm. Otherwise, let candidate be new candidate .
Return candidate .
dictionary FocusOptions { boolean preventScroll = false; };
activeElement
Returns the deepest element in the document through which or to which key events are being routed. This is, roughly speaking, the focused element in the document.
For
the
purposes
of
this
API,
when
a
child
browsing
context
is
focused,
its
browsing
context
container
is
focused
in
the
parent
browsing
context
.
For
example,
if
the
user
moves
the
focus
to
a
text
control
in
an
iframe
,
the
iframe
is
the
element
returned
by
the
activeElement
API
in
the
iframe
's
node
document
.
hasFocus
()
Returns true if key events are being routed through or to the document; otherwise, returns false. Roughly speaking, this corresponds to the document, or a document nested inside this one, being focused.
focus
()
Moves the focus to the window's browsing context , if any.
focus
([
{
preventScroll
:
true
}
])
Moves the focus to the element.
If the element is a browsing context container , moves the focus to the nested browsing context instead.
By
default,
this
method
also
scrolls
the
element
into
view.
Providing
the
preventScroll
option
and
setting
it
to
true
prevents
this
behavior.
blur
()
Moves
the
focus
to
the
viewport
.
Use
of
this
method
is
discouraged;
if
you
want
to
focus
the
viewport
,
call
the
focus()
method
on
the
Document
's
document
element
.
Do not use this method to hide the focus ring if you find the focus ring unsightly. Instead, use a CSS rule to override the 'outline' property, and provide a different way to show what element is focused. Be aware that if an alternative focusing style isn't made available, the page will be significantly less usable for people who primarily navigate pages using a keyboard, or those with reduced vision who use focus outlines to help them navigate the page.
For example, to hide the outline from links and instead use a yellow background to indicate focus, you could use:
:link:focus, :visited:focus { outline: none; background: yellow; color: black; }
The
activeElement
attribute's
getter
must
run
these
steps:
Let
candidate
be
this
Document
object.
If candidate has a non-empty control group , then set candidate to the designated focused area of the control group .
If candidate is a focusable area , then set candidate to candidate 's DOM anchor .
If
candidate
is
not
a
Document
object,
then
return
candidate
.
If candidate has a body element , then return that body element .
If candidate 's document element is non-null, then return that document element .
Return null.
The
hasFocus()
method
on
the
Document
object,
when
invoked,
must
return
the
result
of
running
the
has
focus
steps
with
the
Document
object
as
the
argument.
The
focus()
method
on
the
Window
object,
when
invoked,
must
run
the
focusing
steps
with
the
Window
object's
browsing
context
.
Additionally,
if
this
browsing
context
is
a
top-level
browsing
context
,
user
agents
are
encouraged
to
trigger
some
sort
of
notification
to
indicate
to
the
user
that
the
page
is
attempting
to
gain
focus.
The
blur()
method
on
the
Window
object,
when
invoked,
provides
a
hint
to
the
user
agent
that
the
script
believes
the
user
probably
is
not
currently
interested
in
the
contents
of
the
browsing
context
of
the
Window
object
on
which
the
method
was
invoked,
but
that
the
contents
might
become
interesting
again
in
the
future.
User
agents
are
encouraged
to
ignore
calls
to
this
blur()
method
entirely.
Historically,
the
focus()
and
blur()
methods
actually
affected
the
system-level
focus
of
the
system
widget
(e.g.
tab
or
window)
that
contained
the
browsing
context
,
but
hostile
sites
widely
abuse
this
behavior
to
the
user's
detriment.
The
focus(
options
)
method
on
elements,
when
invoked,
must
run
the
following
steps:
If the element is marked as locked for focus , then return.
Mark the element as locked for focus .
Run the focusing steps for the element.
If
the
value
of
the
preventScroll
dictionary
member
of
options
is
false,
then
scroll
the
element
into
view
with
scroll
behavior
"
auto
",
block
flow
direction
position
set
to
a
UA-defined
value,
and
inline
base
direction
position
set
to
a
UA-defined
value.
Unmark the element as locked for focus .
The
blur()
method,
when
invoked,
should
run
the
unfocusing
steps
for
the
element
on
which
the
method
was
called.
User
agents
may
selectively
or
uniformly
ignore
calls
to
this
method
for
usability
reasons.
For
example,
if
the
blur()
method
is
unwisely
being
used
to
remove
the
focus
ring
for
aesthetics
reasons,
the
page
would
become
unusable
by
keyboard
users.
Ignoring
calls
to
this
method
would
thus
allow
keyboard
users
to
interact
with
the
page.
This section is non-normative.
Each
element
that
can
be
activated
or
focused
can
be
assigned
a
single
key
combination
to
activate
it,
using
the
accesskey
attribute.
The
exact
shortcut
is
determined
by
the
user
agent,
based
on
information
about
the
user's
keyboard,
what
keyboard
shortcuts
already
exist
on
the
platform,
and
what
other
shortcuts
have
been
specified
on
the
page,
using
the
information
provided
in
the
accesskey
attribute
as
a
guide.
In
order
to
ensure
that
a
relevant
keyboard
shortcut
is
available
on
a
wide
variety
of
input
devices,
the
author
can
provide
a
number
of
alternatives
in
the
accesskey
attribute.
Each alternative consists of a single character, such as a letter or digit.
User
agents
can
provide
users
with
a
list
of
the
keyboard
shortcuts,
but
authors
are
encouraged
to
do
so
also.
The
accessKeyLabel
IDL
attribute
returns
a
string
representing
the
actual
key
combination
assigned
by
the
user
agent.
In this example, an author has provided a button that can be invoked using a shortcut key. To support full keyboards, the author has provided "C" as a possible key. To support devices equipped only with numeric keypads, the author has provided "1" as another possibly key.
<input type=button value=Collect onclick="collect()" accesskey="C 1" id=c>
To tell the user what the shortcut key is, the author has this script here opted to explicitly add the key combination to the button's label:
function addShortcutKeyLabel(button) { if (button.accessKeyLabel != '') button.value += ' (' + button.accessKeyLabel + ')'; } addShortcutKeyLabel(document.getElementById('c'));
Browsers on different platforms will show different labels, even for the same key combination, based on the convention prevalent on that platform. For example, if the key combination is the Control key, the Shift key, and the letter C, a Windows browser might display " Ctrl+Shift+C ", whereas a Mac browser might display " ^⇧C ", while an Emacs browser might just display " C-C ". Similarly, if the key combination is the Alt key and the Escape key, Windows might use " Alt+Esc ", Mac might use " ⌥⎋ ", and an Emacs browser might use " M-ESC " or " ESC ESC ".
In
general,
therefore,
it
is
unwise
to
attempt
to
parse
the
value
returned
from
the
accessKeyLabel
IDL
attribute.
accesskey
attribute
All
HTML
elements
may
have
the
accesskey
content
attribute
set.
The
accesskey
attribute's
value
is
used
by
the
user
agent
as
a
guide
for
creating
a
keyboard
shortcut
that
activates
or
focuses
the
element.
If specified, the value must be an ordered set of unique space-separated tokens that are case-sensitive , each of which must be exactly one code point in length.
In the following example, a variety of links are given with access keys so that keyboard users familiar with the site can more quickly navigate to the relevant pages:
<nav> <p> <a title="Consortium Activities" accesskey="A" href="/Consortium/activities">Activities</a> | <a title="Technical Reports and Recommendations" accesskey="T" href="/TR/">Technical Reports</a> | <a title="Alphabetical Site Index" accesskey="S" href="/Consortium/siteindex">Site Index</a> | <a title="About This Site" accesskey="B" href="/Consortium/">About Consortium</a> | <a title="Contact Consortium" accesskey="C" href="/Consortium/contact">Contact</a> </p> </nav>
In the following example, the search field is given two possible access keys, "s" and "0" (in that order). A user agent on a device with a full keyboard might pick Ctrl + Alt + S as the shortcut key, while a user agent on a small device with just a numeric keypad might pick just the plain unadorned key 0 :
<form action="/search"> <label>Search: <input type="search" name="q" accesskey="s 0"></label> <input type="submit"> </form>
In the following example, a button has possible access keys described. A script then tries to update the button's label to advertise the key combination the user agent selected.
<input type=submit accesskey="N @ 1" value="Compose"> ... <script> function labelButton(button) { if (button.accessKeyLabel) button.value += ' (' + button.accessKeyLabel + ')'; } var inputs = document.getElementsByTagName('input'); for (var i = 0; i < inputs.length; i += 1) { if (inputs[i].type == "submit") labelButton(inputs[i]); } </script>
On one user agent, the button's label might become " Compose (⌘N) ". On another, it might become " Compose (Alt+⇧+1) ". If the user agent doesn't assign a key, it will be just " Compose ". The exact string depends on what the assigned access key is, and on how the user agent represents that key combination.
An
element's
assigned
access
key
is
a
key
combination
derived
from
the
element's
accesskey
content
attribute.
Initially,
an
element
must
not
have
an
assigned
access
key
.
Whenever
an
element's
accesskey
attribute
is
set,
changed,
or
removed,
the
user
agent
must
update
the
element's
assigned
access
key
by
running
the
following
steps:
If
the
element
has
no
accesskey
attribute,
then
skip
to
the
fallback
step
below.
Otherwise, split the attribute's value on ASCII whitespace , and let keys be the resulting tokens.
For each value in keys in turn, in the order the tokens appeared in the attribute's value, run the following substeps:
If the value is not a string exactly one code point in length, then skip the remainder of these steps for this value.
If the value does not correspond to a key on the system's keyboard, then skip the remainder of these steps for this value.
If the user agent can find a mix of zero or more modifier keys that, combined with the key that corresponds to the value given in the attribute, can be used as the access key, then the user agent may assign that combination of keys as the element's assigned access key and return.
Fallback : Optionally, the user agent may assign a key combination of its choosing as the element's assigned access key and then return.
If this step is reached, the element has no assigned access key .
Once
a
user
agent
has
selected
and
assigned
an
access
key
for
an
element,
the
user
agent
should
not
change
the
element's
assigned
access
key
unless
the
accesskey
content
attribute
is
changed
or
the
element
is
moved
to
another
Document
.
When the user presses the key combination corresponding to the assigned access key for an element, if the element defines a command , the command's facet is false (visible), the command's Disabled State facet is also false (enabled), the element is in a document that has a browsing context , and neither the element nor any of its ancestors has a attribute specified, then the user agent must trigger the Action of the command.
User
agents
might
expose
elements
that
have
an
accesskey
attribute
in
other
ways
as
well,
e.g.
in
a
menu
displayed
in
response
to
a
specific
key
combination.
The
accessKey
IDL
attribute
must
reflect
the
accesskey
content
attribute.
The
accessKeyLabel
IDL
attribute
must
return
a
string
that
represents
the
element's
assigned
access
key
,
if
any.
If
the
element
does
not
have
one,
then
the
IDL
attribute
must
return
the
empty
string.
contenteditable
content
attribute
Support:
contenteditable
Chrome
for
Android
64+
66+
Chrome
4+
iOS
Safari
5.0+
UC
Browser
for
Android
11.8+
Firefox
3.5+
IE
5.5+
Opera
Mini
None
Samsung
Internet
4+
Safari
3.1+
Edge
12+
Android
Browser
3+
Opera
9+
Source: caniuse.com
interface mixin ElementContentEditable { [CEReactions] attribute DOMString contentEditable; readonly attribute boolean isContentEditable; [CEReactions] attribute DOMString inputMode; };
The
contenteditable
content
attribute
is
an
enumerated
attribute
whose
keywords
are
the
empty
string,
true
,
and
false
.
The
empty
string
and
the
true
keyword
map
to
the
true
state.
The
false
keyword
maps
to
the
false
state.
In
addition,
there
is
a
third
state,
the
inherit
state,
which
is
the
missing
value
default
and
the
invalid
value
default
.
The true state indicates that the element is editable. The inherit state indicates that the element is editable if its parent is. The false state indicates that the element is not editable.
For
example,
consider
a
page
that
has
a
form
and
a
textarea
to
publish
a
new
article,
where
the
user
is
expected
to
write
the
article
using
HTML:
<form method=POST> <fieldset> <legend>New article</legend> <textarea name=article><p>Hello world.</p></textarea> </fieldset> <p><button>Publish</button></p> </form>
When
scripting
is
enabled,
the
textarea
element
could
be
replaced
with
a
rich
text
control
instead,
using
the
contenteditable
attribute:
<form method=POST> <fieldset> <legend>New article</legend> <textarea id=textarea name=article><p>Hello world.</p></textarea> <div id=div style="white-space: pre-wrap" hidden><p>Hello world.</p></div> <script> let textarea = document.getElementById("textarea"); let div = document.getElementById("div"); textarea.hidden = true; div.hidden = false; div.contentEditable = "true"; div.oninput = (e) => { textarea.value = div.innerHTML; }; </script> </fieldset> <p><button>Publish</button></p> </form>
Features
to
enable,
e.g.,
inserting
links,
can
be
implemented
using
the
document.execCommand()
API,
or
using
Selection
APIs
and
other
DOM
APIs.
[EXECCOMMAND]
[SELECTION]
[DOM]
The
contenteditable
attribute
can
also
be
used
to
great
effect:
<!doctype html> <html lang=en> <title>Live CSS editing!</title> <style style=white-space:pre contenteditable> html { margin:.2em; font-size:2em; color:lime; background:purple } head, title, style { display:block } body { display:none } </style>
contentEditable
[
=
value
]
Returns
"
true
",
"
false
",
or
"
inherit
",
based
on
the
state
of
the
contenteditable
attribute.
Can be set, to change that state.
Throws
a
"
SyntaxError
"
DOMException
if
the
new
value
isn't
one
of
those
strings.
isContentEditable
Returns true if the element is editable; otherwise, returns false.
The
contentEditable
IDL
attribute,
on
getting,
must
return
the
string
"
true
"
if
the
content
attribute
is
set
to
the
true
state,
"
false
"
if
the
content
attribute
is
set
to
the
false
state,
and
"
inherit
"
otherwise.
On
setting,
if
the
new
value
is
an
ASCII
case-insensitive
match
for
the
string
"
inherit
"
then
the
content
attribute
must
be
removed,
if
the
new
value
is
an
ASCII
case-insensitive
match
for
the
string
"
true
"
then
the
content
attribute
must
be
set
to
the
string
"
true
",
if
the
new
value
is
an
ASCII
case-insensitive
match
for
the
string
"
false
"
then
the
content
attribute
must
be
set
to
the
string
"
false
",
and
otherwise
the
attribute
setter
must
throw
a
"
SyntaxError
"
DOMException
.
The
isContentEditable
IDL
attribute,
on
getting,
must
return
true
if
the
element
is
either
an
editing
host
or
editable
,
and
false
otherwise.
designMode
IDL
attribute
Spec bugs: 17743
Documents
have
a
designMode
,
which
can
be
either
enabled
or
disabled.
designMode
[
=
value
]
Returns
"
on
"
if
the
document
is
editable,
and
"
off
"
if
it
isn't.
Can be set, to change the document's current state. This focuses the document and resets the selection in that document.
The
designMode
IDL
attribute
on
the
Document
object
takes
two
values,
"
on
"
and
"
off
".
On
setting,
the
new
value
must
be
compared
in
an
ASCII
case-insensitive
manner
to
these
two
values;
if
it
matches
the
"
on
"
value,
then
designMode
must
be
enabled,
and
if
it
matches
the
"
off
"
value,
then
designMode
must
be
disabled.
Other
values
must
be
ignored.
On
getting,
if
designMode
is
enabled,
the
IDL
attribute
must
return
the
value
"
on
";
otherwise
it
is
disabled,
and
the
attribute
must
return
the
value
"
off
".
The
last
state
set
must
persist
until
the
document
is
destroyed
or
the
state
is
changed.
Initially,
documents
must
have
their
designMode
disabled.
When
the
designMode
changes
from
being
disabled
to
being
enabled,
the
user
agent
must
immediately
reset
the
document's
active
range
's
start
and
end
boundary
points
to
be
at
the
start
of
the
Document
and
then
run
the
focusing
steps
for
the
document
element
of
the
Document
,
if
non-null.
Authors are encouraged to set the 'white-space' property on editing hosts and on markup that was originally created through these editing mechanisms to the value 'pre-wrap'. Default HTML whitespace handling is not well suited to WYSIWYG editing, and line wrapping will not work correctly in some corner cases if 'white-space' is left at its default value.
As an example of problems that occur if the default 'normal' value is used instead, consider the case of the user typing " yellow␣␣ball ", with two spaces (here represented by "␣") between the words. With the editing rules in place for the default value of 'white-space' ('normal'), the resulting markup will either consist of " yellow ball " or " yellow ball "; i.e., there will be a non-breaking space between the two words in addition to the regular space. This is necessary because the 'normal' value for 'white-space' requires adjacent regular spaces to be collapsed together.
In the former case, " yellow⍽ " might wrap to the next line ("⍽" being used here to represent a non-breaking space) even though " yellow " alone might fit at the end of the line; in the latter case, " ⍽ball ", if wrapped to the start of the line, would have visible indentation from the non-breaking space.
When 'white-space' is set to 'pre-wrap', however, the editing rules will instead simply put two regular spaces between the words, and should the two words be split at the end of a line, the spaces would be neatly removed from the rendering.
The
definition
of
the
terms
active
range
,
editing
host
,
editing
host
of
,
and
editable
,
the
user
interface
requirements
of
elements
that
are
editing
hosts
or
editable
,
the
execCommand()
,
queryCommandEnabled()
,
queryCommandIndeterm()
,
queryCommandState()
,
queryCommandSupported()
,
and
queryCommandValue()
methods,
text
selections,
and
the
delete
the
selection
algorithm
are
defined
in
execCommand
.
[EXECCOMMAND]
Support:
spellcheck-attribute
Chrome
for
Android
(limited)
64+
66+
Chrome
9+
iOS
Safari
(limited)
3.2+
UC
Browser
for
Android
(limited)
11.8+
Firefox
2+
IE
10+
Opera
Mini
(limited)
all+
Samsung
Internet
(limited)
4+
Safari
5.1+
Edge
12+
Android
Browser
(limited)
2.1+
Opera
10.5+
Source: caniuse.com
User
agents
can
support
the
checking
of
spelling
and
grammar
of
editable
text,
either
in
form
controls
(such
as
the
value
of
textarea
elements),
or
in
elements
in
an
editing
host
(e.g.
using
contenteditable
).
For each element, user agents must establish a default behavior , either through defaults or through preferences expressed by the user. There are three possible default behaviors for each element:
spellcheck
attribute.
spellcheck
attribute.
The
spellcheck
attribute
is
an
enumerated
attribute
whose
keywords
are
the
empty
string,
true
and
false
.
The
empty
string
and
the
true
keyword
map
to
the
true
state.
The
false
keyword
maps
to
the
false
state.
In
addition,
there
is
a
third
state,
the
default
state,
which
is
the
missing
value
default
and
the
invalid
value
default
.
The
true
state
indicates
that
the
element
is
to
have
its
spelling
and
grammar
checked.
The
default
state
indicates
that
the
element
is
to
act
according
to
a
default
behavior,
possibly
based
on
the
parent
element's
own
spellcheck
state,
as
defined
below.
The
false
state
indicates
that
the
element
is
not
to
be
checked.
spellcheck
[
=
value
]
Returns true if the element is to have its spelling and grammar checked; otherwise, returns false.
Can
be
set,
to
override
the
default
and
set
the
spellcheck
content
attribute.
The
spellcheck
IDL
attribute,
on
getting,
must
return
true
if
the
element's
spellcheck
content
attribute
is
in
the
true
state,
or
if
the
element's
spellcheck
content
attribute
is
in
the
default
state
and
the
element's
default
behavior
is
true-by-default
,
or
if
the
element's
spellcheck
content
attribute
is
in
the
default
state
and
the
element's
default
behavior
is
inherit-by-default
and
the
element's
parent
element's
spellcheck
IDL
attribute
would
return
true;
otherwise,
if
none
of
those
conditions
applies,
then
the
attribute
must
instead
return
false.
The
spellcheck
IDL
attribute
is
not
affected
by
user
preferences
that
override
the
spellcheck
content
attribute,
and
therefore
might
not
reflect
the
actual
spellchecking
state.
On
setting,
if
the
new
value
is
true,
then
the
element's
spellcheck
content
attribute
must
be
set
to
the
literal
string
"
true
",
otherwise
it
must
be
set
to
the
literal
string
"
false
".
User agents must only consider the following pieces of text as checkable for the purposes of this feature:
input
elements
whose
type
attributes
are
in
the
Text
,
Search
,
URL
,
or
E-mail
states
and
that
are
mutable
(i.e.
that
do
not
have
the
readonly
attribute
specified
and
that
are
not
disabled
).
textarea
elements
that
do
not
have
a
readonly
attribute
and
that
are
not
disabled
.
Text
nodes
that
are
children
of
editing
hosts
or
editable
elements.
For
text
that
is
part
of
a
Text
node,
the
element
with
which
the
text
is
associated
is
the
element
that
is
the
immediate
parent
of
the
first
character
of
the
word,
sentence,
or
other
piece
of
text.
For
text
in
attributes,
it
is
the
attribute's
element.
For
the
values
of
input
and
textarea
elements,
it
is
the
element
itself.
To determine if a word, sentence, or other piece of text in an applicable element (as defined above) is to have spelling- and grammar-checking enabled, the UA must use the following algorithm:
spellcheck
content
attribute,
then:
if
that
attribute
is
in
the
true
state,
then
checking
is
enabled;
otherwise,
if
that
attribute
is
in
the
false
state,
then
checking
is
disabled.
spellcheck
content
attribute
that
is
not
in
the
default
state,
then:
if
the
nearest
such
ancestor's
spellcheck
content
attribute
is
in
the
true
state,
then
checking
is
enabled;
otherwise,
checking
is
disabled.
If
the
checking
is
enabled
for
a
word/sentence/text,
the
user
agent
should
indicate
spelling
and
grammar
errors
in
that
text.
User
agents
should
take
into
account
the
other
semantics
given
in
the
document
when
suggesting
spelling
and
grammar
corrections.
User
agents
may
use
the
language
of
the
element
to
determine
what
spelling
and
grammar
rules
to
use,
or
may
use
the
user's
preferred
language
settings.
UAs
should
use
input
element
attributes
such
as
pattern
to
ensure
that
the
resulting
value
is
valid,
where
possible.
If checking is disabled, the user agent should not indicate spelling or grammar errors for that text.
The element with ID "a" in the following example would be the one used to determine if the word "Hello" is checked for spelling errors. In this example, it would not be.
<div contenteditable="true"> <span spellcheck="false" id="a">Hell</span><em>o!</em> </div>
The
element
with
ID
"b"
in
the
following
example
would
have
checking
enabled
(the
leading
space
character
in
the
attribute's
value
on
the
input
element
causes
the
attribute
to
be
ignored,
so
the
ancestor's
value
is
used
instead,
regardless
of
the
default).
<p spellcheck="true"> <label>Name: <input spellcheck=" false" id="b"></label> </p>
This specification does not define the user interface for spelling and grammar checkers. A user agent could offer on-demand checking, could perform continuous checking while the checking is enabled, or could use other interfaces.
Some
methods
of
entering
text,
for
example
virtual
keyboards
on
mobile
devices,
and
also
voice
input,
often
assist
users
by
automatically
capitalizing
the
first
letter
of
sentences
(when
composing
text
in
a
language
with
this
convention).
A
virtual
keyboard
that
implements
autocapitalization
might
automatically
switch
to
showing
uppercase
letters
(but
allow
the
user
to
toggle
it
back
to
lowercase)
when
a
letter
that
should
be
autocapitalized
is
about
to
be
typed.
Other
types
of
input,
for
example
voice
input,
may
perform
autocapitalization
in
a
way
that
does
not
give
users
an
option
to
intervene
first.
The
autocapitalize
attribute
allows
authors
to
control
such
behavior.
The
autocapitalize
attribute,
as
typically
implemented,
does
not
affect
behavior
when
typing
on
a
physical
keyboard.
(For
this
reason,
as
well
as
the
ability
for
users
to
override
the
autocapitalization
behavior
in
some
cases
or
edit
the
text
after
initial
input,
the
attribute
must
not
be
relied
on
for
any
sort
of
input
validation.)
The
autocapitalize
attribute
can
be
used
on
an
editing
host
to
control
autocapitalization
behavior
for
the
hosted
editable
region,
on
an
input
or
textarea
element
to
control
the
behavior
for
inputting
text
into
that
element,
or
on
a
form
element
to
control
the
default
behavior
for
all
autocapitalize-inheriting
elements
associated
with
the
form
element.
The
autocapitalize
attribute
never
causes
autocapitalization
to
be
enabled
for
input
elements
whose
type
attribute
is
in
one
of
the
URL
,
E-mail
,
or
Password
states.
(This
behavior
is
included
in
the
used
autocapitalization
hint
algorithm
below.)
The autocapitalization processing model is based on selecting among five autocapitalization hints , defined as follows:
The user agent and input method should use make their own determination of whether or not to enable autocapitalization.
No autocapitalization should be applied (all letters should default to lowercase).
The first letter of each sentence should default to a capital letter; all other letters should default to lowercase.
The first letter of each word should default to a capital letter; all other letters should default to lowercase.
All letters should default to uppercase.
The
autocapitalize
attribute
is
an
enumerated
attribute
whose
states
are
the
possible
autocapitalization
hints
.
The
autocapitalization
hint
specified
by
the
attribute's
state
combines
with
other
considerations
to
form
the
used
autocapitalization
hint
,
which
informs
the
behavior
of
the
user
agent.
The
keywords
for
this
attribute
and
their
state
mappings
are
as
follows:
Keyword | State |
---|---|
off
|
none |
none
|
|
on
|
sentences |
sentences
|
|
words
|
words |
characters
|
characters |
The invalid value default is the sentences state. The missing value default is the default state.
autocapitalize
[
=
value
]
Returns
the
current
autocapitalization
state
for
the
element,
or
an
empty
string
if
it
hasn't
been
set.
Note
that
for
input
and
textarea
elements
that
inherit
their
state
from
a
form
element,
this
will
return
the
autocapitalization
state
of
the
form
element,
but
for
an
element
in
an
editable
region,
this
will
not
return
the
autocapitalization
state
of
the
editing
host
(unless
this
element
is,
in
fact,
the
editing
host
).
Can
be
set,
to
set
the
autocapitalize
content
attribute
(and
thereby
change
the
autocapitalization
behavior
for
the
element).
To compute the own autocapitalization hint of an element element , run the following steps:
If
the
autocapitalize
content
attribute
is
present
on
element
,
and
its
value
is
not
the
empty
string,
return
the
state
of
the
attribute.
If element is an autocapitalize-inheriting element and has a non-null form owner , return the own autocapitalization hint of element 's form owner .
Return default .
The
autocapitalize
IDL
attribute,
on
getting,
must
return
the
string
value
corresponding
to
own
autocapitalization
hint
of
the
element,
with
the
exception
that
the
default
state
maps
to
the
empty
string.
On
setting,
it
must
set
the
autocapitalize
content
attribute
to
the
given
new
value.
User agents that support customizable autocapitalization behavior for a text input method and wish to allow web developers to control this functionality should, during text input into an element, compute the used autocapitalization hint for the element. This will be an autocapitalization hint that describes the recommended autocapitalization behavior for text input into the element.
User agents or input methods may choose to ignore or override the used autocapitalization hint in certain circumstances.
The used autocapitalization hint for an element element is computed using the following algorithm:
If
element
is
an
input
element
whose
type
attribute
is
in
one
of
the
URL
,
E-mail
,
or
Password
states,
then
return
default
.
If
element
is
an
input
element
or
a
textarea
element,
then
return
element
's
own
autocapitalization
hint
.
If element is an editing host or an editable element, then return the own autocapitalization hint of the editing host of element .
Assert: this step is never reached, since text input only occurs in elements that meet one of the above criteria.
inputmode
attribute
Support: input-inputmode Chrome for Android None Chrome 66+ iOS Safari None UC Browser for Android None Firefox None IE None Opera Mini None Samsung Internet None Safari None Edge None Android Browser None Opera None
Source: caniuse.com
User
agents
can
support
the
inputmode
attribute
on
form
controls
(such
as
the
value
of
textarea
elements),
or
in
elements
in
an
editing
host
(e.g.,
using
contenteditable
).
The
inputmode
content
attribute
is
an
enumerated
attribute
that
specifies
what
kind
of
input
mechanism
would
be
most
helpful
for
users
entering
content.
Keyword | Description |
---|---|
none
|
The user agent should not display a virtual keyboard. This keyword is useful for content that renders its own keyboard control. |
text
|
The user agent should display a virtual keyboard capable of text input in the user's locale. |
tel
|
The user agent should display a virtual keyboard capable of telephone number input. This should including keys for the digits 0 to 9, the "#" character, and the "*" character. In some locales, this can also include alphabetic mnemonic labels (e.g., in the US, the key labeled "2" is historically also labeled with the letters A, B, and C). |
url
|
The user agent should display a virtual keyboard capable of text input in the user's locale, with keys for aiding in the input of URLs , such as that for the "/" and "." characters and for quick input of strings commonly found in domain names such as "www." or ".com". |
email
|
The user agent should display a virtual keyboard capable of text input in the user's locale, with keys for aiding in the input of e-mail addresses, such as that for the "@" character and the "." character. |
numeric
|
The user agent should display a virtual keyboard capable of numeric input. This keyword is useful for PIN entry. |
decimal
|
The user agent should display a virtual keyboard capable of fractional numeric input. Numeric keys and the format separator for the locale should be shown. |
search
|
The user agent should display a virtual keyboard optimized for search. |
The
inputMode
IDL
attribute
must
reflect
the
inputmode
content
attribute,
limited
to
only
known
values
.
When
inputmode
is
unspecified
(or
is
in
a
state
not
supported
by
the
user
agent),
the
user
agent
should
determine
the
default
virtual
keyboard
to
be
shown.
Contextual
information
such
as
the
input
type
or
pattern
attributes
should
be
used
to
determine
which
type
of
virtual
keyboard
should
be
presented
to
the
user.