- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Thu, 03 Apr 2025 19:11:41 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[css-anchor-position] Behavior of positioned element when anchor is in top layer`, and agreed to the following: * `RESOLVED: Close no change. Use cases should be addressed through HTML` <details><summary>The full IRC log of that discussion</summary> <fantasai> TabAtkins: Asked what should happen to anchorpos when anchor is in top layer<br> <fantasai> TabAtkins: currently in implementations this fails<br> <fantasai> TabAtkins: if your anchorpos element is abspos or fixedpos, and anchor is promoted to top layer, can't find the anchor<br> <fantasai> TabAtkins: this is intentional and required behavior because things in top layer haven't been laid out during normal page layout, when a normal abspos or fixed pos is laid out<br> <iank_> q+<br> <fantasai> TabAtkins: In order to lay out abspos would need to be in same or higher top layer<br> <fantasai> TabAtkins: so I think this needs to be closed no change?<br> <fantasai> TabAtkins: not the best that you can't anchor random thing to top-layer dialog<br> <fantasai> TabAtkins: but we've had lots of discussions about stuff outside dialogs becoming inert<br> <fantasai> TabAtkins: and this would be asking to make such a thing not inert<br> <fantasai> TabAtkins: suggest to close no change<br> <astearns> ack iank_<br> <fantasai> iank_: falls out of resolution that top layer elements are processed after everything else<br> <fantasai> iank_: there's one caveat, if you have fixedpos in top layer thing, laid out after that thing<br> <fantasai> iank_: but that's subtle<br> <fantasai> iank_: Most people want to anchor things in top layer to something on the page, can't do other way around<br> <astearns> ack fantasai<br> <fantasai> "Would it make sense to automatically elevate positioned elements (and pseudo-elements) into the top layer when their anchors are also in the top layer?"<br> <TabAtkins> fantasai: q in the issue is if it makes sense to aiutomatically elevate positioned lemeents to the top layer when their anchors are in the top layer<br> <fantasai> TabAtkins: An element could have any number of anchors.<br> <kizu> q+<br> <fantasai> TabAtkins: so would have to be "if any" then goes to top layer<br> <fantasai> TabAtkins: that's fiddly<br> <iank_> q+<br> <fantasai> TabAtkins: but also, things in top layer should be inert<br> <fantasai> TabAtkins: if you want something to work in a modal dialog, then need to put it in the modal dialog<br> <fantasai> TabAtkins: don't want to circumvent the top layer inert modal paradigm<br> <astearns> ack kizu<br> <fantasai> kizu: I also wanted to do something like this, and I wonder if only elevating it for the default anchor<br> <fantasai> kizu: this is only one element<br> <fantasai> kizu: and then we move it to be rendered after the corresponding anchor element<br> <fantasai> kizu: But if it's complicated and don't want to handle inertness here, understandable<br> <fantasai> kizu: but I was playing with effects I wanted to do<br> <fantasai> kizu: One use case for this, when you have something like a focus ring which you want to use an element over another element<br> <fantasai> kizu: it works well for regular elements, but as soon as you have popover or dialog you can't do this<br> <fantasai> kizu: and you have to use a separate element inside every dialog etc.<br> <fantasai> TabAtkins: that's exactly the case I'm concerned about doing automatically<br> <fantasai> TabAtkins: that should be handled as part of popover stuff. Some way to elevate things together with the modal dialog.<br> <fantasai> TabAtkins: I think this is an HTML feature. Then we can adopt. But we shouldn't be working around existing top layer stuff automatically.<br> <astearns> ack iank_<br> <fantasai> kizu: More or less impossible to implement<br> <fantasai> s/kizu/iank/<br> <fantasai> iank_: Don't know when laying out the abspos if there is something in the top layer<br> <fantasai> iank_: or something in subtree<br> <fantasai> iank_: ...<br> <fantasai> iank_: gets very complex very quickly<br> <fantasai> astearns: proposed to close issue no change for fear of messing with top level stuff<br> <fantasai> TabAtkins: and if this is desired, pursue in HTMLWG<br> <bkardell> q+<br> <astearns> ack bkardell<br> <fantasai> bkardell: I think there's relationship with some of the things discussed around interactivity property and CSS inert<br> <fantasai> bkardell: but I agree it should be discussed in HTML<br> <fantasai> TabAtkins: exactly the issues I'm worried about us stepping into with this<br> <fantasai> RESOLVED: Close no change. Use cases should be addressed through HTML<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/11868#issuecomment-2776700550 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Thursday, 3 April 2025 19:11:41 UTC