Feature Request: Top Layer Stack Management about html HOT 10 CLOSED

Inconsistent Stacking: Right now, elements in the top layer are added on top of each other based solely on the order they are added. This can cause issues for UI elements that need to stay on top, such as toast notifications or live chat. A new element added later might unintentionally cover them.

At Unsplash this issue is preventing us from migrating from react-modal to native modal <dialog>. We need the ability to show multiple different elements above the modal dialog:

• "Say thanks!" dialog/prompt that appears after downloading a photo
• Flash messages that appear when there's an error
• Global progress bar when we're loading data

All of these elements may appear before or after the modal dialog has been opened, but they should always sit on top of the modal dialog, and they should not be inert when the modal dialog is open.

If we implemented these components as manual popovers then I believe that—based on the discussion above—we would have the following issues:

• They would be inert because of the modal dialog.
• When the modal dialog is opened, they would appear behind, so we would need to re-insert them. This feels like a hack.

It feels like we need a way to control the order of elements in the top layer (like z-index but relative to a different stacking context). Then, any elements stacked above modal dialogs would not be inert—only elements stacked behind would be inert.

from html.

Another workaround I’ve seen authors do is the creation of predefined swimlanes (or layers) of empty divs with pointer-events set to none. These swimlands get shown in a single (manual) popover that is constantly active on the page.

To show something in the top layer, instead of triggering showPopover() on an Element, they move the targeted element to the correct swimlane. See https://codepen.io/bramus/pen/MWdbyNG for an example.

I don’t think this workaround is very practical to work and kinda defeats the whole purpose.

A practical use case where an author used this was to keep tooltips visible on top of toasts, while keeping the toasts on top of a dialog that gets shown later in the page’s lifetime.

from html.

An aspect I missed, thanks to @lcoronelp for pointing it out, is that non-modal items moved above a modal dialog will still be inert even if visually they are on top.

See https://jsfiddle.net/link2twenty/75xnL2ap/

For toast specifically this can be an issue if the toast contains a call to action or a dismiss button. A solution would be to not open any modals and handle inert manually, though this feels prone to accident.

from html.

I have the beginning of a musing

https://codesandbox.io/p/sandbox/modal-change-xpskc7

still feels a little hacky but perhaps may help.

The basic premise is to use a MutationObserver to listen for attribute changes over the entire body, we're listening for the open attribute and filtering the results down to just modal dialog elements. Then we can move the popover element into the newly opened dialog and trigger showPopover again.

I know this example is in React but I'm fairly certain it would be quite easy to implement in vanilla using appendChild this method also only works for dialogs not other popover elements and I'm dubious of how safe it actually is.

Again I'd feel much happier with an event on the window or the ability to watch for mutations in the top layer specifically.

from html.

This is tracked in #9075.

from html.

I don't believe #9075 lines up exactly with what I'm trying to solve, though does cover part.

API to get top layer elements

• Expose an API that allows checking which element is on top.

Top Layer Stack Management

• Expose an API to see entire top layer stack in render order.
• Add method for placing element already in the top layer back on top.
• Event or Mutation for tracking top layer changes.

What is the correct protocol here? Should I make more specific issues with no overlap, take my comments over to 9075 or just perhaps I've misunderstood and all the comments are covered?

from html.

What part do you think is not covered? Pretty sure it touches on all of that (though not all in OP).

from html.

I've just reread the other issue, maybe I'm missing something but it doesn't seem to have;

• a method for reordering items in the top layer (without having to close and open again). Something like whatwg/dom#1255
• a way to detecting changes to the top layer. There is no consistent way across all methods for promoting to the top layer to detect a change.

from html.

If you’re able to, you can insert those elements within the modal dialog which will ensure they’re not inert and they’ll layer correctly.

from html.

If you’re able to, you can insert those elements within the modal dialog which will ensure they’re not inert and they’ll layer correctly.

I considered doing this but it means we'd have to render the elements both inside and outside the modal dialog, so they appear even when the modal dialog is closed. It gets even more complicated when you consider that we have nested modal dialogs, so we'd have to render them inside there as well! 🤯

from html.