- From: Mason Freed via GitHub <sysbot+gh@w3.org>
- Date: Wed, 26 Jan 2022 00:31:34 +0000
- To: public-css-archive@w3.org
> Browser-provided features like fullscreen, modal or popup should use the UA top layer. A potential developer top layer would always be below it. That suffices right? Well, fullscreen and modal dialog yes. But "popup" I'd expect to use this new thing, whatever it is. And I also don't think it suffices - again, if you have either fullscreen or modal dialog and want **that** to put something into the developer top layer, it won't work. It'll be underneath the fullscreen/modal. I.e. no way to put a tooltip on top of a modal dialog. > All of these questions/issues apply exactly equally to developers putting things "on top" today, by making them a final child of `body` with a high z-index. They'll be below the UA-provided "top layer" stuff, yeah. Why are these cases not problematic already? Well, yes and no. Today, if you have a fullscreen or modal dialog, you have to know that, and put your tooltip as the last child **of the fullscreen or dialog element** rather than the **body**, in order for it to show up on top. So it's a problem today. But I'd hate to make it worse by ushering in a whole new capability that was rife with the same problems. I would hope we could make this easier for developers by just having one top layer which behaves rationally. And in most normal situations, things "just work". In the corner case (e.g. user hits ESC), the UA has the power to pull things back out, but developers don't have to worry about that at all. Maybe I'm overthinking this. But some use cases sound common. A tooltip on a dialog sounds familiar. A pop-up volume slider on a fullscreen video sounds familiar. I'd just prefer to have a solution that covers these use cases and doesn't make them harder than they are today. -- GitHub Notification of comment by mfreed7 Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/6965#issuecomment-1021738406 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 26 January 2022 00:31:36 UTC