Living Standard — Last Updated 26 June 2023
details
element
summary
element
a
element
to
define
a
command
button
element
to
define
a
command
input
element
to
define
a
command
option
element
to
define
a
command
accesskey
attribute
on
a
legend
element
to
define
a
command
accesskey
attribute
to
define
a
command
on
other
elements
dialog
element
details
element
Support in all current engines.
Support in all current engines.
summary
element
followed
by
flow
content
.
open
[Exposed=Window]
interface HTMLDetailsElement : HTMLElement {
[HTMLConstructor] constructor();
[CEReactions] attribute boolean open;
};
The
details
element
represents
a
disclosure
widget
from
which
the
user
can
obtain
additional
information
or
controls.
The
details
element
is
not
appropriate
for
footnotes.
Please
see
the
section
on
footnotes
for
details
on
how
to
mark
up
footnotes.
The
first
summary
element
child
of
the
element,
if
any,
represents
the
summary
or
legend
of
the
details.
If
there
is
no
child
summary
element,
the
user
agent
should
provide
its
own
legend
(e.g.
"Details").
The rest of the element's contents represents the additional information or controls.
The
open
content
attribute
is
a
boolean
attribute
.
If
present,
it
indicates
that
both
the
summary
and
the
additional
information
is
to
be
shown
to
the
user.
If
the
attribute
is
absent,
only
the
summary
is
to
be
shown.
When the element is created, if the attribute is absent, the additional information should be hidden; if the attribute is present, that information should be shown. Subsequently, if the attribute is removed, then the information should be hidden; if the attribute is added, the information should be shown.
The
user
agent
should
allow
the
user
to
request
that
the
additional
information
be
shown
or
hidden.
To
honor
a
request
for
the
details
to
be
shown,
the
user
agent
must
set
the
open
attribute
on
the
element
to
the
empty
string.
To
honor
a
request
for
the
information
to
be
hidden,
the
user
agent
must
remove
the
open
attribute
from
the
element.
This
ability
to
request
that
additional
information
be
shown
or
hidden
may
simply
be
the
activation
behavior
of
the
appropriate
summary
element,
in
the
case
such
an
element
exists.
However,
if
no
such
element
exists,
user
agents
can
still
provide
this
ability
through
some
other
user
interface
affordance.
Whenever
the
open
attribute
is
added
to
or
removed
from
a
details
element,
the
user
agent
must
queue
an
element
task
on
the
DOM
manipulation
task
source
given
then
details
element
that
runs
the
following
steps,
which
are
known
as
the
details
notification
task
steps
,
for
this
details
element:
If
another
task
has
been
queued
to
run
the
details
notification
task
steps
for
this
details
element,
then
return.
When
the
open
attribute
is
toggled
several
times
in
succession,
these
steps
essentially
get
coalesced
so
that
only
one
event
is
fired.
Fire
an
event
named
toggle
at
the
details
element.
Support in all current engines.
The
open
IDL
attribute
must
reflect
the
open
content
attribute.
The ancestor details revealing algorithm is to run the following steps on currentNode :
While currentNode has a parent node within the flat tree :
The
following
example
shows
the
details
element
being
used
to
hide
technical
details
in
a
progress
report.
<section class="progress window">
<h1>Copying "Really Achieving Your Childhood Dreams"</h1>
<details>
<summary>Copying... <progress max="375505392" value="97543282"></progress> 25%</summary>
<dl>
<dt>Transfer rate:</dt> <dd>452KB/s</dd>
<dt>Local filename:</dt> <dd>/home/rpausch/raycd.m4v</dd>
<dt>Remote filename:</dt> <dd>/var/www/lectures/raycd.m4v</dd>
<dt>Duration:</dt> <dd>01:16:27</dd>
<dt>Color profile:</dt> <dd>SD (6-1-6)</dd>
<dt>Dimensions:</dt> <dd>320×240</dd>
</dl>
</details>
</section>
The
following
shows
how
a
details
element
can
be
used
to
hide
some
controls
by
default:
<details>
<summary><label for=fn>Name & Extension:</label></summary>
<p><input type=text id=fn name=fn value="Pillar Magazine.pdf">
<p><label><input type=checkbox name=ext checked> Hide extension</label>
</details>
One
could
use
this
in
conjunction
with
other
details
in
a
list
to
allow
the
user
to
collapse
a
set
of
fields
down
to
a
small
set
of
headings,
with
the
ability
to
open
each
one.
In these examples, the summary really just summarizes what the controls can change, and not the actual values, which is less than ideal.
Because
the
open
attribute
is
added
and
removed
automatically
as
the
user
interacts
with
the
control,
it
can
be
used
in
CSS
to
style
the
element
differently
based
on
its
state.
Here,
a
style
sheet
is
used
to
animate
the
color
of
the
summary
when
the
element
is
opened
or
closed:
<style>
details > summary { transition: color 1s; color: black; }
details[open] > summary { color: red; }
</style>
<details>
<summary>Automated Status: Operational</summary>
<p>Velocity: 12m/s</p>
<p>Direction: North</p>
</details>
summary
element
Support in all current engines.
details
element.
HTMLElement
.
The
summary
element
represents
a
summary,
caption,
or
legend
for
the
rest
of
the
contents
of
the
summary
element's
parent
details
element,
if
any.
A
summary
element
is
a
summary
for
its
parent
details
if
the
following
algorithm
returns
true:
If
this
summary
element
has
no
parent,
then
return
false.
Let
parent
be
this
summary
element's
parent.
If
parent
is
not
a
details
element,
then
return
false.
If
parent
's
first
summary
element
child
is
not
this
summary
element,
then
return
false.
Return true.
The
activation
behavior
of
summary
elements
is
to
run
the
following
steps:
If
this
summary
element
is
not
the
summary
for
its
parent
details
,
then
return.
Let
parent
be
this
summary
element's
parent.
If
the
open
attribute
is
present
on
parent
,
then
remove
it.
Otherwise,
set
parent
's
open
attribute
to
the
empty
string.
This will then run the details notification task steps .
A command is the abstraction behind menu items, buttons, and links. Once a command is defined, other parts of the interface can refer to the same command, allowing many access points to a single feature to share facets such as the Disabled State .
Commands are defined to have the following facets :
User agents may expose the commands that match the following criteria:
User agents are encouraged to do this especially for commands that have Access Keys , as a way to advertise those keys to the user.
For example, such commands could be listed in the user agent's menu bar.
a
element
to
define
a
command
An
a
element
with
an
href
attribute
defines
a
command
.
The Label of the command is the element's descendant text content .
The Access Key of the command is the element's assigned access key , if any.
The
of the command is true (hidden) if the element has a attribute, and false otherwise.The Disabled State facet of the command is true if the element or one of its ancestors is inert , and false otherwise.
The
Action
of
the
command
is
to
fire
a
click
event
at
the
element.
button
element
to
define
a
command
A
button
element
always
defines
a
command
.
The
Label
,
Access
Key
,
,
and
Action
facets
of
the
command
are
determined
as
for
a
elements
(see
the
previous
section).
The Disabled State of the command is true if the element or one of its ancestors is inert , or if the element's disabled state is set, and false otherwise.
input
element
to
define
a
command
An
input
element
whose
type
attribute
is
in
one
of
the
Submit
Button
,
Reset
Button
,
Image
Button
,
Button
,
Radio
Button
,
or
Checkbox
states
defines
a
command
.
The Label of the command is determined as follows:
If
the
type
attribute
is
in
one
of
the
Submit
Button
,
Reset
Button
,
Image
Button
,
or
Button
states,
then
the
Label
is
the
string
given
by
the
value
attribute,
if
any,
and
a
UA-dependent,
locale-dependent
value
that
the
UA
uses
to
label
the
button
itself
if
the
attribute
is
absent.
Otherwise,
if
the
element
is
a
labeled
control
,
then
the
Label
is
the
descendant
text
content
of
the
first
label
element
in
tree
order
whose
labeled
control
is
the
element
in
question.
(In
JavaScript
terms,
this
is
given
by
element
.labels[0].textContent
.)
Otherwise,
if
the
value
attribute
is
present,
then
the
Label
is
the
value
of
that
attribute.
Otherwise, the Label is the empty string.
Even
though
the
value
attribute
on
input
elements
in
the
Image
Button
state
is
non-conformant,
the
attribute
can
still
contribute
to
the
Label
determination,
if
it
is
present
and
the
Image
Button's
alt
attribute
is
missing.
The Access Key of the command is the element's assigned access key , if any.
The
of the command is true (hidden) if the element has a attribute, and false otherwise.The Disabled State of the command is true if the element or one of its ancestors is inert , or if the element's disabled state is set, and false otherwise.
The
Action
of
the
command
is
to
fire
a
click
event
at
the
element.
option
element
to
define
a
command
An
option
element
with
an
ancestor
select
element
and
either
no
value
attribute
or
a
value
attribute
that
is
not
the
empty
string
defines
a
command
.
The
Label
of
the
command
is
the
value
of
the
option
element's
label
attribute,
if
there
is
one,
or
else
the
option
element's
descendant
text
content
,
with
ASCII
whitespace
stripped
and
collapsed
.
The Access Key of the command is the element's assigned access key , if any.
The
of the command is true (hidden) if the element has a attribute, and false otherwise.
The
Disabled
State
of
the
command
is
true
if
the
element
is
disabled
,
or
if
its
nearest
ancestor
select
element
is
disabled
,
or
if
it
or
one
of
its
ancestors
is
inert
,
and
false
otherwise.
If
the
option
's
nearest
ancestor
select
element
has
a
multiple
attribute,
the
Action
of
the
command
is
to
toggle
the
option
element.
Otherwise,
the
Action
is
to
pick
the
option
element.
accesskey
attribute
on
a
legend
element
to
define
a
command
A
legend
element
defines
a
command
if
all
of
the
following
are
true:
It has an assigned access key .
It
is
a
child
of
a
fieldset
element.
Its
parent
has
a
descendant
that
defines
a
command
that
is
neither
a
label
element
nor
a
legend
element.
This
element,
if
it
exists,
is
the
legend
element's
accesskey
delegatee
.
The Label of the command is the element's descendant text content .
The Access Key of the command is the element's assigned access key .
The
Disabled
State
,
and
Action
facets
of
the
command
are
the
same
as
the
respective
facets
of
the
legend
element's
accesskey
delegatee
.
In
this
example,
the
legend
element
specifies
an
accesskey
,
which,
when
activated,
will
delegate
to
the
input
element
inside
the
legend
element.
<fieldset>
<legend accesskey=p>
<label>I want <input name=pizza type=number step=1 value=1 min=0>
pizza(s) with these toppings</label>
</legend>
<label><input name=pizza-cheese type=checkbox checked> Cheese</label>
<label><input name=pizza-ham type=checkbox checked> Ham</label>
<label><input name=pizza-pineapple type=checkbox> Pineapple</label>
</fieldset>
accesskey
attribute
to
define
a
command
on
other
elements
An element that has an assigned access key defines a command .
If one of the earlier sections that define elements that define commands define that this element defines a command , then that section applies to this element, and this section does not. Otherwise, this section applies to that element.
The
Label
of
the
command
depends
on
the
element.
If
the
element
is
a
labeled
control
,
the
descendant
text
content
of
the
first
label
element
in
tree
order
whose
labeled
control
is
the
element
in
question
is
the
Label
(in
JavaScript
terms,
this
is
given
by
element
.labels[0].textContent
).
Otherwise,
the
Label
is
the
element's
descendant
text
content
.
The Access Key of the command is the element's assigned access key .
The
of the command is true (hidden) if the element has a attribute, and false otherwise.The Disabled State of the command is true if the element or one of its ancestors is inert , and false otherwise.
The Action of the command is to run the following steps:
click
event
at
the
element.
dialog
element
Support in all current engines.
Support in all current engines.
open
[Exposed=Window]
interface HTMLDialogElement : HTMLElement {
[HTMLConstructor] constructor();
[CEReactions] attribute boolean open;
attribute DOMString returnValue;
[CEReactions] undefined show();
[CEReactions] undefined showModal();
[CEReactions] undefined close(optional DOMString returnValue);
};
The
dialog
element
represents
a
transitory
part
of
an
application,
in
the
form
of
a
small
window
("dialog
box"),
which
the
user
interacts
with
to
perform
a
task
or
gather
information.
Once
the
user
is
done,
the
dialog
can
be
automatically
closed
by
the
application,
or
manually
closed
by
the
user.
Especially for modal dialogs, which are a familiar pattern across all types of applications, authors should work to ensure that dialogs in their web applications behave in a way that is familiar to users of non-web applications.
As
with
all
HTML
elements,
it
is
not
conforming
to
use
the
dialog
element
when
attempting
to
represent
another
type
of
control.
For
example,
context
menus,
tooltips,
and
popup
listboxes
are
not
dialog
boxes,
so
abusing
the
dialog
element
to
implement
these
patterns
is
incorrect.
An
important
part
of
user-facing
dialog
behavior
is
the
placement
of
initial
focus.
The
dialog
focusing
steps
attempt
to
pick
a
good
candidate
for
initial
focus
when
a
dialog
is
shown,
but
might
not
be
a
substitute
for
authors
carefully
thinking
through
the
correct
choice
to
match
user
expectations
for
a
specific
dialog.
As
such,
authors
should
use
the
autofocus
attribute
on
the
descendant
element
of
the
dialog
that
the
user
is
expected
to
immediately
interact
with
after
the
dialog
opens.
If
there
is
no
such
element,
then
authors
should
use
the
autofocus
attribute
on
the
dialog
element
itself.
In the following example, a dialog is used for editing the details of a product in an inventory management web application.
<dialog>
<label>Product Number <input type="text" readonly></label>
<label>Product Name <input type="text" autofocus></label>
</dialog>
If
the
autofocus
attribute
was
not
present,
the
Product
Number
field
would
have
been
focused
by
the
dialog
focusing
steps.
Although
that
is
reasonable
behavior,
the
author
determined
that
the
more
relevant
field
to
focus
was
the
Product
Name
field,
as
the
Product
Number
field
is
readonly
and
expects
no
user
input.
So,
the
author
used
autofocus
to
override
the
default.
Even
if
the
author
wants
to
focus
the
Product
Number
field
by
default,
they
are
best
off
explicitly
specifying
that
by
using
autofocus
on
that
input
element.
This
makes
the
intent
obvious
to
future
readers
of
the
code,
and
ensures
the
code
stays
robust
in
the
face
of
future
updates.
(For
example,
if
another
developer
added
a
close
button,
and
positioned
it
in
the
node
tree
before
the
Product
Number
field).
Another important aspect of user behavior is whether dialogs are scrollable or not. In some cases, overflow (and thus scrollability) cannot be avoided, e.g., when it is caused by the user's high text zoom settings. But in general, scrollable dialogs are not expected by users. Adding large text nodes directly to dialog elements is particularly bad as this is likely to cause the dialog element itself to overflow. Authors are best off avoiding them.
The following terms of service dialog respects the above suggestions.
<dialog style="height: 80vh;">
<div style="overflow: auto; height: 60vh;" autofocus>
<p>By placing an order via this Web site on the first day of the fourth month of the year
2010 Anno Domini, you agree to grant Us a non-transferable option to claim, for now and for
ever more, your immortal soul.</p>
<p>Should We wish to exercise this option, you agree to surrender your immortal soul,
and any claim you may have on it, within 5 (five) working days of receiving written
notification from this site or one of its duly authorized minions.</p>
<!-- ... etc., with many more <p> elements ... -->
</div>
<form method="dialog">
<button type="submit" value="agree">Agree</button>
<button type="submit" value="disagree">Disagree</button>
</form>
</dialog>
Note
how
the
dialog
focusing
steps
would
have
picked
the
scrollable
div
element
by
default,
but
similarly
to
the
previous
example,
we
have
placed
autofocus
on
the
div
so
as
to
be
more
explicit
and
robust
against
future
changes.
In
contrast,
if
the
p
elements
expressing
the
terms
of
service
did
not
have
such
a
wrapper
div
element,
then
the
dialog
itself
would
become
scrollable,
violating
the
above
advice.
Furthermore,
in
the
absence
of
any
autofocus
attribute,
such
a
markup
pattern
would
have
violated
the
above
advice
and
tripped
up
the
dialog
focusing
steps
's
default
behavior,
and
caused
focus
to
jump
to
the
Agree
button
,
which
is
a
bad
user
experience.
The
open
attribute
is
a
boolean
attribute
.
When
specified,
it
indicates
that
the
dialog
element
is
active
and
that
the
user
can
interact
with
it.
A
dialog
element
without
an
open
attribute
specified
should
not
be
shown
to
the
user.
This
requirement
may
be
implemented
indirectly
through
the
style
layer.
For
example,
user
agents
that
support
the
suggested
default
rendering
implement
this
requirement
using
the
CSS
rules
described
in
the
Rendering
section
.
Removing
the
open
attribute
will
usually
hide
the
dialog.
However,
doing
so
has
a
number
of
strange
additional
consequences:
The
close
event
will
not
be
fired.
The
close()
method,
and
any
user-agent
provided
cancelation
interface
,
will
no
longer
be
able
to
close
the
dialog.
If
the
dialog
was
shown
using
its
showModal()
method,
the
Document
will
still
be
blocked
.
For
these
reasons,
it
is
generally
better
to
never
remove
the
open
attribute
manually.
Instead,
use
the
close()
method
to
close
the
dialog,
or
the
attribute
to
hide
it.
The
tabindex
attribute
must
not
be
specified
on
dialog
elements.
dialog
.
show
()
Support in all current engines.
Displays
the
dialog
element.
dialog
.
showModal
()
Support in all current engines.
Displays
the
dialog
element
and
makes
it
the
top-most
modal
dialog.
This
method
honors
the
autofocus
attribute.
dialog
.
close
([
result
])
Support in all current engines.
Closes
the
dialog
element.
The argument, if provided, provides a return value.
dialog
.
returnValue
[
=
result
]
Support in all current engines.
Returns
the
dialog
's
return
value.
Can be set, to update the return value.
The
show()
method
steps
are:
If
this
is
in
the
popover
showing
state
,
then
throw
an
"
InvalidStateError
"
DOMException
.
Add
an
open
attribute
to
this
,
whose
value
is
the
empty
string.
Set this 's previously focused element to the focused element.
Run the dialog focusing steps given this and false.
The
showModal()
method
steps
are:
If
this
has
an
open
attribute,
then
throw
an
"
InvalidStateError
"
DOMException
.
If
this
is
not
connected
,
then
throw
an
"
InvalidStateError
"
DOMException
.
If
this
is
in
the
popover
showing
state
,
then
throw
an
"
InvalidStateError
"
DOMException
.
Add
an
open
attribute
to
this
,
whose
value
is
the
empty
string.
Let this 's node document be blocked by the modal dialog this .
This will cause the focused area of the document to become inert (unless that currently focused area is a shadow-including descendant of subject ). In such cases, the focused area of the document will soon be reset to the viewport . In a couple steps we will attempt to find a better candidate to focus.
If this 's node document 's top layer does not already contain this , then add this to this 's node document 's top layer .
Set this 's previously focused element to the focused element.
Run the dialog focusing steps given this and true.
The
dialog
focusing
steps
,
given
a
dialog
element
subject
and
a
boolean
isModal
,
are
as
follows:
Run hide all popovers given subject 's node document .
Let control be null.
If
isModal
is
true
and
subject
has
the
autofocus
attribute,
then
set
control
to
subject
.
If control is null, then set control to the focus delegate of subject .
If control is null, then set control to subject .
Run the focusing steps for control .
If
control
is
not
focusable
,
this
will
do
nothing.
This
would
only
happen
if
subject
had
no
focus
delegate,
and
the
user
agent
decided
that
dialog
elements
were
not
generally
focusable.
In
that
case,
any
earlier
modifications
to
the
focused
area
of
the
document
will
apply.
Let topDocument be control 's node navigable 's top-level traversable 's active document .
If control 's node document 's origin is not the same as the origin of topDocument , then return.
Empty topDocument 's autofocus candidates .
Set topDocument 's autofocus processed flag to true.
If
at
any
time
a
dialog
element
is
removed
from
a
Document
,
then
if
that
dialog
is
in
that
Document
's
top
layer
,
it
must
be
removed
from
it.
Also,
set
the
dialog
element's
is
modal
flag
to
false.
The
close(
returnValue
)
method
steps
are:
If returnValue is not given, then set it to null.
Close the dialog this with returnValue .
When
a
dialog
element
subject
is
to
be
closed
,
with
null
or
a
string
result
,
run
these
steps:
If
subject
does
not
have
an
open
attribute,
then
return.
Remove
subject
's
open
attribute.
Set the is modal flag of subject to false.
If
result
is
not
null,
then
set
the
returnValue
attribute
to
result
.
If
subject
is
in
its
Document
's
top
layer
,
then
remove
it.
If subject 's previously focused element is not null, then:
Let element be subject 's previously focused element .
Set subject 's previously focused element to null.
Run the focusing steps for element ; the viewport should not be scrolled by doing this step.
Queue
an
element
task
on
the
user
interaction
task
source
given
the
subject
element
to
fire
an
event
named
close
at
subject
.
The
returnValue
IDL
attribute,
on
getting,
must
return
the
last
value
to
which
it
was
set.
On
setting,
it
must
be
set
to
the
new
value.
When
the
element
is
created,
it
must
be
set
to
the
empty
string.
We
use
show/close
as
the
verbs
for
dialog
elements,
as
opposed
to
verb
pairs
that
are
more
commonly
thought
of
as
antonyms
such
as
show/hide
or
open/close,
due
to
the
following
constraints:
Hiding
a
dialog
is
different
from
closing
one.
Closing
a
dialog
gives
it
a
return
value,
fires
an
event,
unblocks
the
page
for
other
dialogs,
and
so
on.
Whereas
hiding
a
dialog
is
a
purely
visual
property,
and
is
something
you
can
already
do
with
the
open
attribute.
(See
also
the
note
above
about
removing
the
open
attribute,
and
how
hiding
the
dialog
in
that
way
is
generally
not
desired.)
Showing
a
dialog
is
different
from
opening
one.
Opening
a
dialog
consists
of
creating
and
showing
that
dialog
(similar
to
how
window.open()
both
creates
and
shows
a
new
window).
Whereas
showing
the
dialog
is
the
process
of
taking
a
dialog
element
that
is
already
in
the
DOM,
and
making
it
interactive
and
visible
to
the
user.
If
we
were
to
have
a
dialog.open()
method
despite
the
above,
it
would
conflict
with
the
dialog.open
property.
Furthermore,
a
survey
of
many
other
UI
frameworks
contemporary
to
the
original
design
of
the
dialog
element
made
it
clear
that
the
show/close
verb
pair
was
reasonably
common.
In summary, it turns out that the implications of certain verbs, and how they are used in technology contexts, mean that paired actions such as showing and closing a dialog are not always expressible as antonyms.
Canceling
dialogs
:
When
Document
is
blocked
by
a
modal
dialog
dialog
,
user
agents
may
provide
a
user
interface
that,
upon
activation,
queues
an
element
task
on
the
user
interaction
task
source
given
the
dialog
element
to
run
these
steps:
Let
close
be
the
result
of
firing
an
event
named
cancel
at
dialog
,
with
the
cancelable
attribute
initialized
to
true.
If close is true, then close the dialog dialog with null.
An example of such a UI mechanism would be the user pressing the "Escape" key.
Each
dialog
element
has
an
is
modal
flag.
When
a
dialog
element
is
created,
this
flag
must
be
set
to
false.
Each
HTML
element
has
a
previously
focused
element
which
is
null
or
an
element,
and
it
is
initially
null.
When
showModal()
and
show()
are
called,
this
element
is
set
to
the
currently
focused
element
before
running
the
dialog
focusing
steps
.
Elements
with
the
popover
attribute
set
this
element
to
the
currently
focused
element
during
the
show
popover
algorithm
.
Support in all current engines.
The
open
IDL
attribute
must
reflect
the
open
content
attribute.
This
dialog
box
has
some
small
print.
The
strong
element
is
used
to
draw
the
user's
attention
to
the
more
important
part.
<dialog>
<h1>Add to Wallet</h1>
<p><strong><label for=amt>How many gold coins do you want to add to your wallet?</label></strong></p>
<p><input id=amt name=amt type=number min=0 step=0.01 value=100></p>
<p><small>You add coins at your own risk.</small></p>
<p><label><input name=round type=checkbox> Only add perfectly round coins</label></p>
<p><input type=button onclick="submit()" value="Add Coins"></p>
</dialog>
Buttons may have the following content attributes:
dialogmoddaltarget
If
specified,
the
dialogmodaltarget
attribute
value
must
be
the
ID
of
a
dialog
element
in
the
same
tree
as
the
button
with
the
dialogmodaltarget
attribute.
The
following
shows
how
the
dialogmodaltarget
attribute
can
be
used
to
show
and
close
a
dialog:
<button dialogmodaltarget="foo">
Show a dialog (modal)
</button>
<dialog id="foo">
This is a dialog!
<button dialogmodaltarget="foo">Close</button>
</article>
interface mixin DialogInvokerElement {
[CEReactions] attribute Element? dialogModalTargetElement;
};
The
dialogModalTargetElement
IDL
attribute
must
reflect
the
dialogmodaltarget
attribute.
To
run
the
dialog
modal
target
attribute
activation
behavior
given
a
Node
node
:
Let dialog be node 's dialog modal target element .
If dialog is null, then return.
If
the
open
attribute
is
set
on
node
then:
Run
close()
Otherwise,
run
showModal()
on
node
To
get
the
dialog
modal
target
element
given
a
Node
node
,
perform
the
following
steps.
They
return
an
HTML
element
or
null.
If node is not a button , then return null.
If node is disabled , then return null.
If node 's popovertarget is set, then return null.
If node has a form owner and node is a submit button , then return null.
Let
dialogElement
be
node
's
dialogmodaltarget
-associated
element
.
If dialogElement is null, then return null.
If
dialogElement
is
not
a
dialog
element,
then
return
null.
Return dialogElement .