Expose a stack of blocking elements

[domenic]

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.

[annevk]

It seems @cookiecrook might also have valuable input given he filed the bug.

[alice]

Very glad to see the conversation continuing on this, thanks for pushing it forward @domenic!

I like this concept in general. I'd like to dig a little deeper into what an element being on the "blocking element stack" means. Here are my guesses, basically copied from <dialog>'s behaviour:

1. Being at the top of the stack effectively means everything else on the page is inert.
2. Everything on the stack is in the top layer
   • (Aside: I'm intrigued by the possibilities of this, isolated from the other behaviours described here, as a solution to the problem of people messing with the DOM order to hack layering without using z-index, for things like floating top menu bars.)
3. The top blocking element is a control group owner object.
   • Note the role that control groups play in selecting the sequential focus navigation start point and in the focusing steps.

Have I missed anything?

Also, would the order of the stack determine the visual layering order? If calling pop() doesn't hide the element, what does it do?

[alice]

Also, I'd like to ensure that we don't prematurely write off inert as a primitive which may be useful separately from this concept.

[domenic]

Thanks for working on the precision there @alice. You're right that there are several separate concepts. Currently (1) is handled by blocked by a modal dialog, which is set in showModal(). (2) is the only part that is directly tied to the definition of the pending dialog stack. In theory we could tease them apart, so that you can block all other elements on the page without being in the top layer, but in practice that's probably not so useful.

(3) is a little strange. See some previous discussion in #744. Currently the spec has all dialogs being control group owner objects. This is meant to cause tabbing to cycle if you're inside the dialog---even if the dialog is non-modal. However, Chrome does not currently do this (and only Chrome implements dialogs). And it's worth noting that for modal dialogs, this doesn't really matter, since everything else being inert means it's not focusable. So maybe we don't need to worry about (3), assuming we are going to do (1). (Which seems very likely, since that was the original ask.)

Also, would the order of the stack determine the visual layering order? If calling pop() doesn't hide the element, what does it do?

As long as you are in the stack, you are in the top layer, and the order of the top layer is indeed determined by the order of the stack. (Maybe there are issues here with fullscreen, though, that make it nontrivial to just map the ordering?) But once you are popped from the stack, you are no longer in the top layer. You will be below everything inside the top layer, but still visible, unless you change your visibility (e.g. with CSS).

[alice]

So maybe we don't need to worry about (3), assuming we are going to do (1). (Which seems very likely, since that was the original ask.)

Seems fair to me. I'm still struggling with what a non-modal dialog looks like (and what is a dialog group?)

In theory we could tease them apart, so that you can block all other elements on the page without being in the top layer, but in practice that's probably not so useful.
...
But once you are popped from the stack, you are no longer in the top layer. You will be below everything inside the top layer, but still visible, unless you change your visibility (e.g. with CSS).

Yep, this works for me too. I definitely think tying (1) and (2) together is a good idea - the visual cue is an intrinsic part of the behaviour.

Still thinking about naming, by the way, but I don't want to sidetrack into that discussion until we're all on the same page with the core concepts (not least because I think they will affect what nomenclature makes sense).

[domenic]

An example of a non-modal dialog is at https://jsbin.com/tojolefele/edit?html,output (Chrome only). Per spec, once you pop open the dialog and focus the button labeled "dialog 1", your tabbing should cycle between "dialog 1" and "dialog 2" and not break out to the "1" and "2" and "Run with JS" buttons. (Unless, presumably, you used something like Esc or other keyboard shortcuts to pop up outside the dialog's control group.)

Dialog groups appear to be a rather confusing concept meant to express "all dialogs in a control group", to handle cases like a Document with multiple open dialogs? Focus fixup rule two and three seem most relevant...

[alice]

@domenic If the non-modal dialog did trap focus, what would the difference be between that and a modal dialog? i.e. what is the purpose/function of a non-modal dialog, if it is indistinguishable from a bug?

[domenic]

You can still activate (and focus) things that are outside the non-modal dialog, e.g. with the mouse most obviously, but also with the keyboard assuming your UA allows you to escape a focus group using a key like Esc or ctrl + up arrow or similar. It only affects normal sequential focus navigation (i.e. the tab key).

[alice]

That seems like pretty weird behaviour, but I'm going to assume it makes sense for reasons I just don't currently understand.

To get back to the current topic, then:

• open modal dialogs would automatically be on document.blockingElements, basically as if calling dialog.openModal() called document.blockingElements.push(dialog).
• similarly, closing a modal dialog would effectively call document.blockingElements.remove(dialog) (assuming such an API exists)
• what would be the effect of document.blockingElements.pop() if the top blocking element is a modal <dialog>? This seems ill defined currently - an open <dialog> must be part of the top layer, but pop() shouldn't automatically close it, as I understand it.

[domenic]

Open modal dialogs would automatically be on document.blockingElements, basically as if calling dialog.openModal() called document.blockingElements.push(dialog).

Yep

similarly, closing a modal dialog would effectively call document.blockingElements.remove(dialog) (assuming such an API exists)

Ah, interesting; it's not always the top, so such an API would be necessary to fully explain dialogs. We could add that... although we need to define what happens if you push the same element twice. I guess it gets moved to the top, instead of creating two entries.

what would be the effect of document.blockingElements.pop() if the top blocking element is a modal ? This seems ill defined currently - an open must be part of the top layer, but pop() shouldn't automatically close it, as I understand it.

It would remove it from the top layer, but it would still be visible, since you didn't actually change its visibility (e.g. with CSS).

If there is something else in the top layer then the dialog would be hidden underneath it.

[domenic]

It would remove it from the top layer, but it would still be visible, since you didn't actually change its visibility (e.g. with CSS).

In other words, it would transition the dialog to exactly the same state it would be in if you just called .show(), instead of .showModal().

[alice]

In other words, it would transition the dialog to exactly the same state it would be in if you just called .show(), instead of .showModal().

Ah - I'd missed that non-modal dialogs weren't in the top layer. Makes perfect sense in that case.

similarly, closing a modal dialog would effectively call document.blockingElements.remove(dialog) (assuming such an API exists)

Ah, interesting; it's not always the top, so such an API would be necessary to fully explain dialogs. We could add that... although we need to define what happens if you push the same element twice. I guess it gets moved to the top, instead of creating two entries.

Yep, I think that makes a lot of sense.

I think remove() also just makes sense if there is any case where a blocking element can become non-blocking while it's not the top blocking element.

[domenic]

Edited the OP to include .remove() and to note that when you .push() an element that is already in the stack, it moves to the top.