Summary

  • A 2013 W3C HTML 5.1 draft described dialog, showModal(), a browser-managed stack, a blocked document, autofocus, closing and a return value. The companion interaction chapter made the surrounding document inert during a modal dialog.
  • The 2014 HTML5 Candidate Recommendation and 2017 HTML 5.2 Recommendation carried that model forward. The current HTML Standard spells out focus and dismissal in still greater detail.

Imagine a newspaper asking whether to delete a saved reading list. The site can draw a box in front of the headline, dim the background and print two impeccable buttons. Yet a keyboard user may still find the search field behind the box. A screen reader may hear controls that the darkened page suggests are unavailable. A finger can land on the wrong layer. The design team has staged a private conversation in the middle of a crowded room and forgotten to close the door.

The 28 May 2013 HTML 5.1 draft treated a dialog as part of an application in which a person performs a task. It offered show() for an ordinary dialog and showModal() for one that takes the room. The latter put the element on a document’s pending-dialog stack and into the top layer. It also blocked the document. This was a behavioral assignment, not an instruction to draw a more luxurious shadow.

The draft’s user-interaction chapter explained the consequence of that block: nodes outside the modal conversation became inert. The browser would stop treating the rest of the page as an alternative route through the task. The author still wrote the question and the buttons. The platform supplied a common answer to “which room is active?” A page with a painted backdrop alone could not make that promise.

The 2013 text also gave the doorman more chores. A modal dialog could honor an autofocus target. The top dialog could receive a cancel request, such as one triggered by the user interface, and the close() method could leave a returnValue. That value lets the application decide what the reader chose after the browser has managed the act of leaving. A confirmation box should remember whether its visitor said yes, no or simply escaped; the doorman need not decide what “yes” means to the reading list.

The HTML5 Candidate Recommendation of February 2014 retained the modal stack, top layer and close/cancel machinery. The HTML 5.2 Recommendation of December 2017 described dialog focusing steps as well. Those dated documents chart a standards design, not a calendar of when every browser behaved identically. They show the shape of a delegation: the browser knows what sits above the page and what must wait below it.

The distinction between show() and showModal() matters. A nonmodal inspector can stay open while a reader works elsewhere. A modal confirmation must temporarily claim the conversation. Treating both as the same window because both have rounded corners is like calling a restaurant table a courtroom because each has chairs. The boundary comes from behavior. The author chooses which kind of exchange is justified.

The current HTML Standard gives that exchange a fuller script: initial focus, close requests, return values and controls over which user actions dismiss a dialog. Its newer requestClose() and closedby facilities belong to the present text, not to the 2013 draft. The long history is useful because it keeps the question visible beneath the API names. When a site interrupts a reader, who makes the interruption real, and who gets to decide when it ends?

The browser can guard the active layer and guide focus. It cannot write a humane confirmation question. The best dialog makes both jobs obvious: the page asks something worth interrupting for, and the rest of the page waits its turn.