[selectors] Add :modal-dialog pseudo-class

[tabatkins]

HTML defines that the <dialog> element has an "is modal" flag, and uses that as a styling hook. We just discussed adding some more properties to modal dialogs in the UA stylesheet, which would need to do the same.

This should just be handled as a real pseudo-class, rather than an abstract "pretend these styles were applied as if from the UA stylesheet".

@emilio @bfgeek @smfr

[bfgeek]

@mfreed7

[bfgeek]

@josepharhar

[mfreed7]

I'm strongly in favor of exposing a pseudo class for things in the top layer. So let's not call it :modal-dialog, let's call it :top-layer, and have it apply to modal <dialog>, full screen elements, and (in the future), anything else that is located in the top layer such as popup elements.

[tabatkins]

That's not possible in general, since "being in the top layer" is something that should be doable from CSS.

But we could certainly generalize it to anything built-in that forces itself (or at least defaults) into the top layer.

[vmpstr]

"being in the top layer" is something that should be doable from CSS.

Just to confirm, that is currently not possible in CSS right? But you're saying that in the future we may be able to put something in the top layer via CSS?

[tabatkins]

Yeah, it's been in the cards for a long time.

[mfreed7]

@tabatkins are there any artifacts you can point to for that idea (CSS-based top layer access)? I'm working on a proposal for exactly that, but CSS seems like a hard way to do it. I'm looking at an HTML attribute. But I'd love to see what's already been thought through.

Having said that, I don't see why there can't be a :top-layer pseudo. It would be independent from "how" an element gets to the top layer, right?

[vmpstr]

Having said that, I don't see why there can't be a :top-layer pseudo

I think the hard part is something like

div { top-layer: yes }
div:top-layer { top-layer: no }

[mfreed7]

Having said that, I don't see why there can't be a :top-layer pseudo

I think the hard part is something like

div { top-layer: yes }
div:top-layer { top-layer: no }

Precisely. You can't control access to the top layer via CSS, for this and other reasons, but I don't see why you can't select based on it.

[vmpstr]

Isn't it just the fact that you can have one but not both? That is, you either control access via CSS but can't select, or you can select but then you can't control access via CSS. I don't know what "other reasons" are though, so the choice of whether to allow selection or access is probably decided by something else

[SebastianZ]

For reference, there's a discussion around selectors that depend on layout in #5979.

Sebastian

[mfreed7]

Isn't it just the fact that you can have one but not both? That is, you either control access via CSS but can't select, or you can select but then you can't control access via CSS. I don't know what "other reasons" are though, so the choice of whether to allow selection or access is probably decided by something else

The basic issue is that the UA controls the top layer, and can “kick out” elements. E.g. both full screen elements and modal dialogs get forcibly removed from the top layer when you hit ESC. If access to the top layer were provided by CSS (say via a position:top-layer property), what would happen in this case? Would computedStyle still say position:top-layer? Worse, how would one re-request top layer access in this case? By removing the property and re-adding it? The issue is that CSS can’t really be modified by the UA. But if top layer access was provided by something like <div toplayer>, then the UA could just remove the attribute when needed.

[vmpstr]

I appreciate the difficulty in getting things into top layer with CSS. I'm just trying to reconcile this with @tabatkins reply that "top layer with CSS is probably coming". Adding a :top-layer selector is likely to cement the fact that we can't add things to top layer with CSS, so it's important to understand whether or not CSS will ever be able to add things to top layer :)

[tabatkins]

There's been several issues discussing it, but the most relevant one is #4645.

There's nothing inherently magical about the top layer. You can achieve identical effects today via the common strategy of putting elements as final direct children of body and abspos or fixposing them. The point of the top layer is just convenience - because we reparent the element's box, it avoids things like scrollable ancestor clips automatically so you can put the element where it's convenient rather than always making it a body child.

So removing things from the top layer similarly isn't a property of "being in the top layer", but rather "being a UA-provided feature, and thus not necessarily something the page author knows about". We don't want the video fullscreen button to mess up the entire page unless the author specifically handled exitting fullscreen; similarly with modals. If the UA provides, the UA should take away as well, for good user experience. But browsers don't have the ability to automatically dismiss home-brewed dialogs that are just abspos divs living at the end of body, because that's done entirely by the page author and it's their responsibility to control it and dismiss it.

---

So, yes, we can't have a selector that means "element is in the top layer" and a property that puts elements in the top layer. But we definitely want the latter, because it's a useful convenience primitive that has no reason not to be exposed to authors. And we don't actually need the former; what we need is a pseudo-class for detecting when a host-language specific element is in a host-language specific state that, as a side-effect, puts it in the top layer, because that's a useful semantic detail of the element's current state; that's completely doable. When a dialog is modal, when a video is fullscreened, etc. are all potentially foldable into here if we think it's useful.