dialog element under overflow

[idoros]

I'm not sure if this is not handled by the spec or a problem in the implementation (although I can see the same behavior in both Chrome, Opera and Firefox under flag).

Having a dialog element under a containing block with overflow will affect the dialog content. For me the biggest value in such an element would be to finaly have content pop out of its layout without being affected by it. But it seems to be cut as you can see in this example

[domenic]

After looking into this a bit, I think this is working as intended, as your example is using the non-modal mode of dialog. The non-modal dialog isn't really much more powerful than a div.

Here is a modal example that seems to do what you want. https://codepen.io/anon/pen/XwmzVK

Closing, but happy to continue discussing in the comments!

[idoros]

Thank you for responding! So there is a difference between setting the open attribute and calling showModal(). I didn't realize that.

I was hoping to use the dialog element as a way to have floating menus that can be inside the context of the element that opens them. A way to make a drop-down or a popup-menu that can be styled, work properly with events and have regular keyboard navigation instead of using custom layers with JavaScript portals.

Do you have any thoughts about this type of thing with the dialog element or if there is any spec or discussion on a solution for such a thing. Because the most difficult issue is the escape from the "overflow trap" (I'm writing something on the issue I'm trying to solve here).

[domenic]

I think dialog is specifically meant for dialogs, and won't serve your purposes well when it comes to non-dialogs, like menus.

I think the best path forward is for us to investigate exposing the primitives that make up dialog. #897 explores that a bit, especially #897 (comment).

[idoros]

When you look at non-modals UI, like the opened calendar of a date input, It does control the focus navigation, but the rest of the page is still accessible around it. I feel that such "ui-extension" should't cause the rest of the page be inert.

Can the blockingElements API allow for a top layer that doesn't make the rest of the page inert, or are you referring to even lower level primitives?

[domenic]

Right, as noted in the comment I linked to, there are 2-3 different primitives involved.

[idoros]

Looking at the comment you referenced to, @alice talked about 3 things, out of which I think the second point is especially relevant for this issue.

• (1) "Being at the top of the stack effectively means everything else on the page is inert." - this feels like it goes against what I'm trying to achieve by disabling all UI outside the top layer.
• (2) "Everything on the stack is in the top layer" - this appears to be the functionality that I'm after. If I'm looking at the dialog API of show() and showModal(), I can imagine another API which would be similar to the show() API but would also include the 7th step of the showModal() (If subject's node document's top layer does not already contain subject, then add subject to subject's node document's top layer).
• (3) "The top blocking element is a control group owner object." - I'm not sure about this part, my intuition is that focus should be "expanded" to the new UI elements exposed without disabling the "background" UI.

Also later in the discussion there is talk about tying (1) and (2) together, which make a lot of sense for the blockingElements API, but you've also mentioned the possibility of breaking them apart which I think could be very relevant for this issue.

Hope I've managed to get my thoughts across, curious to hear if I got it right. Is there anything I could do on my end to try and further this issue?

[domenic]

Yes, you've captured the essence of the problem space. I think the most helpful thing you could do, you've already done, which is make it clear this is a problem affecting you and your work. That should bump it up the priority for standards folks and browser implementers to work on; I know my team on Chrome is definitely starting to investigate what we can do here.

In terms of helping out with that process, personally I see one key blocker, which is researching how existing frameworks and native UI toolkits handle this idea. I need that data before we can start proposing a top layer solution. Your help there would be definitely appreciated, if you have the bandwidth.

I'll start a new issue, and CC you and some others, with my take on how to do that research.