- From: Chris Harrelson via GitHub <sysbot+gh@w3.org>
- Date: Tue, 25 Jan 2022 17:26:09 +0000
- To: public-css-archive@w3.org
> > 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? The reason why is the need for the UA-manipulated stuff to be on top. I don't have an objection to considering exposing another top layer to developers that is below the UA one, if there is a strong use case, so long as it doesn't get in the way of the UA one. > > 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. Ok. I think we're on the same page then: agreed that it's likely useful to developers to have their own top layer, and that the UA top layer should win. -- GitHub Notification of comment by chrishtr Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/6965#issuecomment-1021431830 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 17:26:11 UTC