HTML

Living Standard — Last Updated 28 January 2023

    1. 4.11 Interactive elements
      1. 4.11.1 The details element
      2. 4.11.2 The summary element
      3. 4.11.3 Commands
        1. 4.11.3.1 Facets
        2. 4.11.3.2 Using the a element to define a command
        3. 4.11.3.3 Using the button element to define a command
        4. 4.11.3.4 Using the input element to define a command
        5. 4.11.3.5 Using the option element to define a command
        6. 4.11.3.6 Using the accesskey attribute on a legend element to define a command
        7. 4.11.3.7 Using the accesskey attribute to define a command on other elements
      4. 4.11.4 The dialog element

4.11 Interactive elements

4.11.1 The details element

Element/details

Support in all current engines.

Firefox49+Safari6+Chrome12+
Opera?Edge79+
Edge (Legacy)?Internet ExplorerNo
Firefox Android49+Safari iOS?Chrome AndroidYesWebView Android?Samsung Internet?Opera Android14+

HTMLDetailsElement

Support in all current engines.

Firefox49+Safari6+Chrome10+
Opera?Edge79+
Edge (Legacy)?Internet ExplorerNo
Firefox Android?Safari iOS?Chrome Android?WebView Android37+Samsung Internet?Opera Android?
Categories:
Flow content.
Interactive content.
Palpable content.
Contexts in which this element can be used:
Where flow content is expected.
Content model:
One summary element followed by flow content.
Tag omission in text/html:
Neither tag is omissible.
Content attributes:
Global attributes
open — Whether the details are visible
Accessibility considerations:
For authors.
For implementers.
DOM interface:
[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:

  1. 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.

  2. Fire an event named toggle at the details element.

The open IDL attribute must reflect the open content attribute.

The ancestor details revealing algorithm is to run the following steps on currentNode:

  1. While currentNode has a parent node within the flat tree:

    1. If currentNode is slotted into the second slot of a details element:

      1. Set currentNode to the details element which currentNode is slotted into.

      2. If the open attribute is not set on currentNode, then set the open attribute on currentNode to the empty string.

    2. Otherwise, set currentNode to the parent node of currentNode 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>

4.11.2 The summary element

Element/summary

Support in all current engines.

Firefox49+Safari6+Chrome12+
Opera?Edge79+
Edge (Legacy)?Internet ExplorerNo
Firefox Android?Safari iOSYesChrome AndroidYesWebView Android4+Samsung Internet?Opera Android14+
Categories:
None.
Contexts in which this element can be used:
As the first child of a details element.
Content model:
Phrasing content, optionally intermixed with heading content.
Tag omission in text/html:
Neither tag is omissible.
Content attributes:
Global attributes
Accessibility considerations:
For authors.
For implementers.
DOM interface:
Uses 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:

  1. If this summary element has no parent, then return false.

  2. Let parent be this summary element's parent.

  3. If parent is not a details element, then return false.

  4. If parent's first summary element child is not this summary element, then return false.

  5. Return true.

The activation behavior of summary elements is to run the following steps:

  1. If this summary element is not the summary for its parent details, then return.

  2. Let parent be this summary element's parent.

  3. 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.

4.11.3 Commands

4.11.3.1 Facets

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:

Label
The name of the command as seen by the user.
Access Key
A key combination selected by the user agent that triggers the command. A command might not have an Access Key.
Hidden State
Whether the command is hidden or not (basically, whether it should be shown in menus).
Disabled State
Whether the command is relevant and can be triggered or not.
Action
The actual effect that triggering the command will have. This could be a scripted event handler, a URL to which to navigate, or a form submission.

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.

4.11.3.2 Using the 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 Hidden State of the command is true (hidden) if the element has a hidden 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.

4.11.3.3 Using the button element to define a command

A button element always defines a command.

The Label, Access Key, Hidden State, 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.

4.11.3.4 Using the 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:

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 Hidden State of the command is true (hidden) if the element has a hidden 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.

4.11.3.5 Using the 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 Hidden State of the command is true (hidden) if the element has a hidden 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.

4.11.3.6 Using the accesskey attribute on a legend element to define a command

A legend element defines a command if all of the following are true:

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 Hidden State, 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>
4.11.3.7 Using the 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 Hidden State of the command is true (hidden) if the element has a hidden 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:

  1. Run the focusing steps for the element.
  2. Fire a click event at the element.

4.11.4 The dialog element

Element/dialog

Support in all current engines.

Firefox98+Safari15.4+Chrome37+
Opera?Edge79+
Edge (Legacy)?Internet ExplorerNo
Firefox Android?Safari iOS?Chrome Android?WebView Android?Samsung Internet?Opera Android?

HTMLDialogElement

Support in all current engines.

Firefox98+Safari15.4+Chrome37+
Opera?Edge79+
Edge (Legacy)?Internet ExplorerNo
Firefox Android?Safari iOS?Chrome Android?WebView Android?Samsung Internet?Opera Android?
Categories:
Flow content.
Contexts in which this element can be used:
Where flow content is expected.
Content model:
Flow content.
Tag omission in text/html:
Neither tag is omissible.
Content attributes:
Global attributes
open — Whether the dialog box is showing
Accessibility considerations:
For authors.
For implementers.
DOM interface:
[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:

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 hidden attribute to hide it.

The tabindex attribute must not be specified on dialog elements.

dialog.show()

HTMLDialogElement/show

Support in all current engines.

Firefox98+Safari15.4+Chrome37+
Opera?Edge79+
Edge (Legacy)?Internet ExplorerNo
Firefox Android?Safari iOS?Chrome Android?WebView Android?Samsung Internet?Opera Android?

Displays the dialog element.

dialog.showModal()

HTMLDialogElement/showModal

Support in all current engines.

Firefox98+Safari15.4+Chrome37+
Opera?Edge79+
Edge (Legacy)?Internet ExplorerNo
Firefox Android?Safari iOS?Chrome Android?WebView Android?Samsung Internet?Opera Android?

Displays the dialog element and makes it the top-most modal dialog.

This method honors the autofocus attribute.

dialog.close([ result ])

HTMLDialogElement/close

Support in all current engines.

Firefox98+Safari15.4+Chrome37+
Opera?Edge79+
Edge (Legacy)?Internet ExplorerNo
Firefox Android?Safari iOS?Chrome Android?WebView Android?Samsung Internet?Opera Android?

Closes the dialog element.

The argument, if provided, provides a return value.

dialog.returnValue [ = result ]

HTMLDialogElement/returnValue

Support in all current engines.

Firefox98+Safari15.4+Chrome37+
Opera?Edge79+
Edge (Legacy)?Internet ExplorerNo
Firefox Android?Safari iOS?Chrome Android?WebView Android?Samsung Internet?Opera Android?

Returns the dialog's return value.

Can be set, to update the return value.

When the show() method is invoked, the user agent must run the following steps:

  1. If the element already has an open attribute, then return.

  2. If subject is in the popover showing state, then throw an "InvalidStateError" open attribute to the dialog element, whose value is the empty string.

  3. Set the dialog element's previously focused element to the focused element.

  4. Run the dialog focusing steps given the dialog element and false.

When the showModal() method is invoked, the user agent must run the following steps:

  1. Let subject be the dialog element on which the method was invoked.

  2. If subject already has an open attribute, then throw an "InvalidStateError" subject is not connected, then throw an "InvalidStateError" subject is in the popover showing state, then throw an "InvalidStateError" open attribute to subject, whose value is the empty string.

  3. Set the is modal flag of subject to true.

  4. Let subject's node document be blocked by the modal dialog subject.

    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.

  5. If subject's node document's top layer does not already contain subject, then add subject to subject's node document's top layer.

  6. Set the subject's previously focused element to the focused element.

  7. Run the dialog focusing steps given subject and true.

The dialog focusing steps, given a dialog element subject and a boolean isModal, are as follows:

  1. Run hide all popovers until given null, false, and false.

  2. Let control be null.

  3. If isModal is true and subject has the autofocus attribute, then set control to subject.

  4. If control is null, then set control to the focus delegate of subject.

  5. If control is null, then set control to subject.

  6. 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.

  7. Let topDocument be control's node navigable's top-level traversable's active document.

  8. If control's node document's origin is not the same as the origin of topDocument, then return.

  9. Empty topDocument's autofocus candidates.

  10. 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.

When the close(returnValue) method is invoked, the user agent must close the dialog that the method was invoked on. If returnValue was given, it must be used as the return value; otherwise, there is no return value.

When a dialog element subject is to be closed, optionally with a return value result, the user agent must run the following steps:

  1. If subject does not have an open attribute, then return.

  2. Remove subject's open attribute.

  3. Set the is modal flag of subject to false.

  4. If the argument result was provided, then set the returnValue attribute to the value of result.

  5. If subject is in its Document's top layer, then remove it.

  6. If subject's previously focused element is not null, then:

    1. Let element be subject's previously focused element.

    2. Set subject's previously focused element to null.

    3. Run the focusing steps for element; the viewport should not be scrolled by doing this step.

  7. 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 hidden attribute or by removing 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 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:

  1. Let close be the result of firing an event named cancel at dialog, with the

    If close is true and dialog has an open attribute, then close the dialog with no return value.

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.


HTMLDialogElement/open

Support in all current engines.

Firefox98+Safari15.4+Chrome37+
Opera?Edge79+
Edge (Legacy)?Internet ExplorerNo
Firefox Android?Safari iOS?Chrome Android?WebView Android?Samsung Internet?Opera Android?

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>