Previously:

• https://www.w3.org/Bugs/Public/show_bug.cgi?id=24983
• https://groups.google.com/forum/#!msg/browser-accessibility-dev/QinGGM_OM7Y/FHpxY_qfBgAJ

Based on these discussions, especially the last one, I'd like to propose the following API to explain some of the magic of <dialog>:

document.blockingElements.push(element); // note: if element is already in the blocking elements stack, it moves to the top
document.blockingElements.pop();
document.blockingElements.remove(element); // see https://github.com/whatwg/html/issues/897#issuecomment-198565716
document.blockingElements.top; // or .current or .peek()

We would generalize the "pending dialog stack" (which, note, is only used when showModal() is called, not just show()) to a "blocking element stack".

Dialogs would take part in that stack and be fully explained by it and integrated into it. For example:

• Calling document.blockingElements.top after dialogEl.showModal() would return dialogEl.
• Calling document.blockingElements.pop() with an active modal dialog would make that dialog un-modal (but not hide it or remove it from the document), and make whatever was below it on the stack become the new blocking element.

Ccing some people form the browser-accessibility-dev discussion: @marcysutton @alice @minorninth. Implementer interest would be especially helpful in moving this forward, @alice @minorninth.