It's a big problem. In fact I wish a better layer stack API instead of having a special top-layer for dialog.
Problematic UI use cases:
- z-index is a hint, the real layering depends on the positioning of the parent element. The usual trick is to insert an element at the bottom of the DOM, and then use z-index.
- If you create a Dropdown or a popup UI (eg. a date picker), the accessibility of focus handling is hard. Your component needs to appear in a top-layer but by inserting it in a div at the bottom, you loose the tab order that goes from the trigger button to the popup. (there is an aria attribute to associate the control, but at least VoiceOver ignores it, and the browser doesn't respect the tab-order).
- The dialog element not only solves the positioning on top, it also solves the focus-trap that is needed for a keyboard navigable (accesible) UI.
- It's possible to use dialog for a non-modal popup. However, the specs doesn't say much about layering. (in fact a quick dialog test in Chrome/Firefox/Safari... they don't follow a predictable layer positioning).
The thing is, if you need to create a dialog, tooltip, dropdown, or popup today... you need a lot of hacks.
I agree. I was answering to the parent comment of: “I'm still trying to grasp the real use of this”.
This top-layer feature only solves the element at the bottom + positioning + z-index hack.
I wish to have a sort of programmatic stack API. But, the constraint of using HTML makes these things messy. The stack is implicit by nesting dialogs, and dialogs can be modeles, but is not a proper API for pop ups. (the article points to a pop up proposal, but my expectations are low)
Small businesses build their websites by setting up on a platform like Shopify or Squarespace. They use a template and fill in the content. They add functionality to the site, like an email opt-in, a "free shipping if you order over $50" bar at the top of the page, a "contact us" button floating at the bottom, a bunch of social media icons floating on the side... via plug-ins/apps/scripts. They don't ever touch code. All those plug-ins/apps/scripts that provide this functionality to non-technical website owners as a service have no idea what the webpage DOM will look like, how it's coded, what other scripts you're loading on the page. They end up fighting to be on top with z-indexes, and that's how you end up with the website's main navigation being on top of instead of behind a modal dialog like a popup contact form, when the site owner wants it to be behind. This "top layer" means the stuff that isn't part of the page and should always be above the page can really be on top.
Sounds like all that stuff which is now fighting over z-index, "implemented" by people with no clue at all, will be fighting over the top layer soon, when the people with no clue at all start throwing it together...
The problem is not these things fighting with each other, but fighting with the webpage design. It's fine if a contact form pops up over an email opt-in form, if the contact form is the more recent thing someone tried to open. It's not fine if the contact form appears behind the website's navigation menu because the website template designer gave the menu too high of a z-index value. Separating these third party overlays from the webpage is the improvement this offers.
