GeezerVison

The details name group that contains a details element a also contains all the other details elements b that fulfill all of the following conditions:

• Both a and b are in the same tree.
• They both have a name attribute, their name attributes are not the empty string, and the value of a's name attribute equals the value of b's name attribute.

The following attribute change steps, given element, localName, oldValue, value, and namespace, are used for all details elements:

1. If namespace is not null, then return.

2. If localName is name, then ensure details exclusivity by closing the given element if needed given element.

3. If localName is open:

   1. If one of oldValue or value is null and the other is not null, run the following steps, which are known as the details notification task steps, for this details element:

      When the open attribute is toggled several times in succession, the resulting tasks essentially get coalesced so that only one event is fired.

      1. If oldValue is null, queue a details toggle event task given the details element, "closed", and "open".

      2. Otherwise, queue a details toggle event task given the details element, "open", and "closed".

   2. If oldValue is null and value is not null, then ensure details exclusivity by closing other elements if needed given element.

The details HTML element insertion steps, given insertedNode, are:

1. Ensure details exclusivity by closing the given element if needed given insertedNode.

To queue a details toggle event task given a details element element, a string oldState, and a string newState:

1. If element's details toggle task tracker is not null:

   1. Set oldState to element's details toggle task tracker's old state.

   2. Remove element's details toggle task tracker's task from its task queue.

   3. Set element's details toggle task tracker to null.

2. Queue an element task given the DOM manipulation task source and element to run the following steps:

   1. Fire an event named toggle at element, using ToggleEvent, with the oldState attribute initialized to oldState and the newState attribute initialized to newState.

   2. Set element's details toggle task tracker to null.

3. Set element's details toggle task tracker to a struct with task set to the just-queued task and old state set to oldState.

To ensure details exclusivity by closing other elements if needed given a details element element:

1. Assert: element has an open attribute.

2. If element does not have a name attribute, or its name attribute is the empty string, then return.

3. Let groupMembers be a list of elements, containing all elements in element's details name group except for element, in tree order.

4. For each element otherElement of groupMembers:

   1. If the open attribute is set on otherElement:

      1. Assert: otherElement is the only element in groupMembers that has the open attribute set.

      2. Remove the open attribute on otherElement.

      3. Break.

To ensure details exclusivity by closing the given element if needed given a details element element:

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

2. If element does not have a name attribute, or its name attribute is the empty string, then return.

3. Let groupMembers be a list of elements, containing all elements in element's details name group except for element, in tree order.

4. For each element otherElement of groupMembers:

   1. If the open attribute is set on otherElement:

      1. Remove the open attribute on element.

      2. Break.

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.

The following example shows the name attribute of the details element being used to create an exclusive accordion, a set of details elements where a user action to open one details element causes any open details to close.

<section class="characteristics">
 <details name="frame-characteristics">
  <summary>Material</summary>
  The picture frame is made of solid oak wood.
 </details>
 <details name="frame-characteristics">
  <summary>Size</summary>
  The picture frame fits a photo 40cm tall and 30cm wide.
  The frame is 45cm tall, 35cm wide, and 2cm thick.
 </details>
 <details name="frame-characteristics">
  <summary>Color</summary>
  The picture frame is available in its natural wood
  color, or with black stain.
 </details>
</section>

The following example shows what happens when the open attribute is set on a details element that is part of a set of elements using the name attribute to create an exclusive accordion.

Given the initial markup:

<section class="characteristics">
 <details name="frame-characteristics" id="d1" open>...</details>
 <details name="frame-characteristics" id="d2">...</details>
 <details name="frame-characteristics" id="d3">...</details>
</section>

and the script:

document.getElementById("d2").setAttribute("open", "");

then the resulting tree after the script executes will be equivalent to the markup:

<section class="characteristics">
 <details name="frame-characteristics" id="d1">...</details>
 <details name="frame-characteristics" id="d2" open>...</details>
 <details name="frame-characteristics" id="d3">...</details>
</section>

because setting the open attribute on d2 removes it from d1.

The same happens when the user activates the summary element inside of d2.

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>

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.

User agents may expose the commands that match the following criteria:

• The Hidden State facet is false (visible).

• The element is in a document with a non-null browsing context.

• Neither the element nor any of its ancestors has a hidden attribute specified.

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.

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.

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:

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

2. 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.)

3. Otherwise, if the value attribute is present, then the Label is the value of that attribute.

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

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.

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

An element that has an assigned access key defines a command.

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.

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

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.

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>

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 close requests, 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 requestClose() or close() methods to close the dialog, or the hidden attribute to hide it.

The show() method steps are:

1. If this has an open attribute and is modal of this is false, then return.

2. If this has an open attribute, then throw an "InvalidStateError" DOMException.

3. If the result of firing an event named beforetoggle, using ToggleEvent, with the cancelable attribute initialized to true, the oldState attribute initialized to "closed", and the newState attribute initialized to "open" at this is false, then return.

4. If this has an open attribute, then return.

5. Queue a dialog toggle event task given this, "closed", "open", and null.

6. Add an open attribute to this, whose value is the empty string.

7. Set this's previously focused element to the focused element.

8. Let document be this's node document.

9. Let hideUntil be the result of running topmost popover ancestor given this, null, and false.

10. Run hide popovers until given document, hideUntil, false, and true.

11. Run the dialog focusing steps given this.

The showModal() method steps are to show a modal dialog given this and null.

The close(returnValue) method steps are:

1. If returnValue is not given, then set it to null.

2. Close the dialog this with returnValue and null.

The requestClose(returnValue) method steps are:

1. If returnValue is not given, then set it to null.

2. Request to close the dialog this with returnValue and null.

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

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.

The closedBy getter steps are to return the keyword corresponding to the computed closed-by state given this.

The dialog HTML element insertion steps, given insertedNode, are:

1. If insertedNode's node document is not fully active, then return.

2. If insertedNode has an open attribute and is connected, then run the dialog setup steps given insertedNode.

The dialog HTML element removing steps, given removedNode, isSubtreeRoot, and oldAncestor are:

1. If removedNode has an open attribute, then run the dialog cleanup steps given removedNode.

2. If removedNode's node document's top layer contains removedNode, then remove an element from the top layer immediately given removedNode.

3. Set is modal of removedNode to false.

The following attribute change steps, given element, localName, oldValue, value, and namespace are used for dialog elements:

1. If namespace is not null, then return.

2. If localName is not open, then return.

3. If value is null and oldValue is not null, then run the dialog cleanup steps given element.

4. If element's node document is not fully active, then return.

5. If element is not connected, then return.

   This ensures that the dialog setup steps are not run on nodes that are disconnected, which would result in a close watcher being established. The dialog cleanup steps need no such guard.

6. If value is not null and oldValue is null, then run the dialog setup steps given element.

To show a modal dialog given a dialog element subject and an Element or null source:

1. If subject has an open attribute and is modal of subject is true, then return.

2. If subject has an open attribute, then throw an "InvalidStateError" DOMException.

3. If subject's node document is not fully active, then throw an "InvalidStateError" DOMException.

4. If subject is not connected, then throw an "InvalidStateError" DOMException.

5. If subject is in the popover showing state, then throw an "InvalidStateError" DOMException.

6. If the result of firing an event named beforetoggle, using ToggleEvent, with the cancelable attribute initialized to true, the oldState attribute initialized to "closed", the newState attribute initialized to "open", and the source attribute initialized to source at subject is false, then return.

7. If subject has an open attribute, then return.

8. If subject is not connected, then return.

9. If subject is in the popover showing state, then return.

10. Queue a dialog toggle event task given subject, "closed", "open", and source.

11. Add an open attribute to subject, whose value is the empty string.

12. Assert: subject's close watcher is not null.

13. Set is modal of subject to true.

14. Set subject's node document to 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.

15. If subject's node document's top layer does not already contain subject, then add an element to the top layer given subject.

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

17. Let document be subject's node document.

18. Let hideUntil be the result of running topmost popover ancestor given subject, null, and false.

19. Run hide popovers until given document, hideUntil, false, and true.

20. Run the dialog focusing steps given subject.

To set the dialog close watcher, given a dialog element dialog:

1. Assert: dialog's close watcher is null.

2. Assert: dialog has an open attribute and dialog's node document is fully active.

3. Set dialog's close watcher to the result of establishing a close watcher given dialog's relevant global object, with:

   • cancelAction given canPreventClose being to return the result of firing an event named cancel at dialog, with the cancelable attribute initialized to canPreventClose.

   • closeAction being to close the dialog given dialog, dialog's request close return value, and dialog's request close source element.

   • getEnabledState being to return true if dialog's enable close watcher for request close is true or dialog's computed closed-by state is not None; otherwise false.

The is valid command steps for dialog elements, given a command attribute command, are:

1. If command is in the Close state, the Request Close state, or the Show Modal state, then return true.

2. Return false.

The command steps for dialog elements, given an element element, an element source, and a command attribute command, are:

1. If element is in the popover showing state, then return.

2. If command is in the Close state and element has an open attribute, then close the dialog element with source's optional value and source.

3. If command is in the Request Close state and element has an open attribute, then request to close the dialog element with source's optional value and source.

4. If command is the Show Modal state and element does not have an open attribute, then show a modal dialog given element and source.

The following buttons use commandfor to open and close a "confirm" dialog as modal when activated:

<button type=button
        commandfor="the-dialog"
        command="show-modal">
 Delete
</button>
<dialog id="the-dialog">
 <form action="/delete" method="POST">
  <button type="submit">
   Delete
  </button>
  <button commandfor="the-dialog"
          command="close">
   Cancel
  </button>
 </form>
</dialog>
    

When a dialog element subject is to be closed, with null or a string result and an Element or null source, run these steps:

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

2. Fire an event named beforetoggle, using ToggleEvent, with the oldState attribute initialized to "open", the newState attribute initialized to "closed", and the source attribute initialized to source at subject.

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

4. Queue a dialog toggle event task given subject, "open", "closed", and source.

5. Remove subject's open attribute.

6. If is modal of subject is true, then request an element to be removed from the top layer given subject.

7. Let wasModal be the value of subject's is modal flag.

8. Set is modal of subject to false.

9. If result is not null, then set subject's returnValue attribute to result.

10. Set subject's request close return value to null.

11. Set subject's request close source element to null.

12. If subject's previously focused element is not null:

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

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

    3. If subject's node document's focused area of the document's DOM anchor is a shadow-including inclusive descendant of subject, or wasModal is true, then run the focusing steps for element; the viewport should not be scrolled by doing this step.

13. Queue an element task on the user interaction task source given the subject element to fire an event named close at subject.

To request to close dialog element subject, given null or a string returnValue and null or an Element source:

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

2. If subject is not connected or subject's node document is not fully active, then return.

3. Assert: subject's close watcher is not null.

4. Set subject's enable close watcher for request close to true.

5. Set subject's request close return value to returnValue.

6. Set subject's request close source element to source.

7. Request to close subject's close watcher with false.

8. Set subject's enable close watcher for request close to false.

To queue a dialog toggle event task given a dialog element element, a string oldState, a string newState, and an Element or null source:

1. If element's dialog toggle task tracker is not null:

   1. Set oldState to element's dialog toggle task tracker's old state.

   2. Remove element's dialog toggle task tracker's task from its task queue.

   3. Set element's dialog toggle task tracker to null.

2. Queue an element task given the DOM manipulation task source and element to run the following steps:

   1. Fire an event named toggle at element, using ToggleEvent, with the oldState attribute initialized to oldState, the newState attribute initialized to newState, and the source attribute initialized to source.

   2. Set element's dialog toggle task tracker to null.

3. Set element's dialog toggle task tracker to a struct with task set to the just-queued task and old state set to oldState.

To retrieve a dialog's computed closed-by state, given a dialog dialog:

1. If the state of dialog's closedby attribute is Auto:

   1. If dialog's is modal is true, then return Close Request.

   2. Return None.

2. Return the state of dialog's closedby attribute.

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

1. If the allow focus steps given subject's node document return false, then return.

2. Let control be null.

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

The dialog setup steps, given a dialog element subject, are as follows:

1. Assert: subject has an open attribute.

2. Assert: subject is connected.

3. Assert: subject's node document's open dialogs list does not contain subject.

4. Add subject to subject's node document's open dialogs list.

5. Set the dialog close watcher with subject.

The dialog cleanup steps, given a dialog element subject, are as follows:

1. Remove subject from subject's node document's open dialogs list.

2. If subject's close watcher is not null:

   1. Destroy subject's close watcher.

   2. Set subject's close watcher to null.

To light dismiss open dialogs, given a PointerEvent event:

1. Assert: event's isTrusted attribute is true.

2. Let document be event's target's node document.

3. If document's open dialogs list is empty, then return.

4. Let ancestor be the result of running nearest clicked dialog given event.

5. If event's type is "pointerdown", then set document's dialog pointerdown target to ancestor.

6. If event's type is "pointerup":

   1. Let sameTarget be true if ancestor is document's dialog pointerdown target.

   2. Set document's dialog pointerdown target to null.

   3. If sameTarget is false, then return.

   4. Let topmostDialog be the last element of document's open dialogs list.

   5. If ancestor is topmostDialog, then return.

   6. If topmostDialog's computed closed-by state is not Any, then return.

   7. Assert: topmostDialog's close watcher is not null.

   8. Request to close topmostDialog's close watcher with false.

To run light dismiss activities, given a PointerEvent event:

1. Run light dismiss open popovers with event.

2. Run light dismiss open dialogs with event.

To find the nearest clicked dialog, given a PointerEvent event:

1. Let target be event's target.

2. If target is a dialog element, target has an open attribute, target's is modal is true, and event's clientX and clientY are outside the bounds of target, then return null.

   The check for clientX and clientY is because a pointer event that hits the ::backdrop pseudo element of a dialog will result in event having a target of the dialog element itself.

3. Let currentNode be target.

4. While currentNode is not null:

   1. If currentNode is a dialog element and currentNode has an open attribute, then return currentNode.

   2. Set currentNode to currentNode's parent in the flat tree.

5. Return null.