Re: [csswg-drafts] [selectors] Add :modal-dialog pseudo-class (#6965)

> So there's something somewhat magical about the top layer. It provides a guaranteed-on-top paint order, regardless of max(z-index) on the page.

I mean, that's just the definition of it, sure. Nothing about that implies that it can't be used by author-level CSS.

>  However, if you provide access to the top layer via a CSS property, similar concerns will exist: the UA will need the power to remove those elements from the top layer in some cases

Why? I don't see why this is required - top-layer is just a *somewhat more reliable/convenient* version of what authors can already do today, by putting their "top-layer" elements as final children of `body` and giving them a high z-index. The UA doesn't need the ability to remove *those* elements - what's different here?

> I don't think it's ok to have CSS put something in the top layer. The top layer is a stacking context that is managed by the UA, and enables it to implement features such as fullscreen and dialog reliably on behalf of the user and developer. If the developer were able to put things into the top layer that the UA did not understand, the UA would lose its ability to reliably implement the features it does have for the top layer, because it wouldn't be sure that the fullscreen or dialog was on top of other content.

Yes, having the UA features always sit *further* on top (the "UA top layer", I suppose) is fine and reasonable. But none of this requires us to deny authors the ability to reliably put things in *a* top layer with the same convenient ancestor-escaping capability; authors should be able to make their own `dialog`-equivalents, for example.

-- 
GitHub Notification of comment by tabatkins
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/6965#issuecomment-1020764697 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Tuesday, 25 January 2022 03:07:39 UTC