- From: CSS Meeting Bot via GitHub <noreply@w3.org>
- Date: Thu, 02 Apr 2026 22:20:22 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[css-anchor-position-1] anchors-visible still needs more details`, and agreed to the following: * `RESOLVED: If the anchored element is in the same CB as the anchor, it doesn't get hidden by anchors-visible` * `RESOLVED: An anchor with non-zero area also requires a non-zero intersection area to be considered visible` <details><summary>The full IRC log of that discussion</summary> <fantasai> Almost all the restrictions we have on styling derive from not being able to control / read layout. Which is basically the restriction we're indexing on.<br> <emilio> TabAtkins: emilio pointed out that there were issues with anchors-visible<br> <emilio> ... intended to hide your anchored element when your anchor is e.g. scrolled away<br> <emilio> ... he had two points, both addressed in the spec, one by rejecting one by accepting<br> <emilio> ... the spec used `IntersectionObserver` logic to talk about things, which uses edge-inclusive intersection, which means that if your anchor is positioned right at the top edge so that the bottom line overlaps, it's not visible, but with edge-inclusive intersection it still counts<br> <emilio> ... we decided that didn't make a lot of sense, so we put a requirement so that if the anchor has a non-zero area it needs a non-zero intersection are<br> <emilio> ... still allows a zero-area anchor to sit on the edge<br> <emilio> ... are we fine with that?<br> <emilio> q+<br> <TabAtkins> emilio: I think that's fine<br> <Rossen> ack emilio<br> <TabAtkins> emilio: did we also... the other thing that IO does is looking at ink overflow rather than border box of the element<br> <TabAtkins> emilio: IO does border box<br> <TabAtkins> fantasai: that's what we want<br> <TabAtkins> emilio: okay then yeah that sounds good<br> <emilio> TabAtkins: emilio asked also about if both are in the scroller, the spec excludes it<br> <emilio> ... it's not a problem here<br> <emilio> ... because the anchored element will get hidden by the scrollport<br> <emilio> ... not necessary to blink out the anchor-pos'd element<br> <emilio> ... can remain there<br> <emilio> ... conclusion was that it was intentional<br> <TabAtkins> emilio: I think that's fine<br> <TabAtkins> emilio: fwiw in gecko we use the ink overflow rect for this check<br> <TabAtkins> emilio: this also seems fine<br> <TabAtkins> emilio: framing it in terms of scrollers doesn't make much sense to me maybe... if they're in the same CB instead<br> <TabAtkins> TabAtkins: If the anchor is in a different scrollers, then it's definitely in a different CB right now<br> <TabAtkins> emilio: right, but some additions to positioning letting your control the CB might violate the assumptions here<br> <TabAtkins> TabAtkins: right, we'll have to make sure we track that<br> <dshin-moz> (We started using ink overflow rects when we landed the change to handle fragmented anchors)<br> <emilio> PROPOSED: Accept changes in the spec<br> <TabAtkins> (we should file an ink-overflow question as a separate issue)<br> <emilio> PROPOSED: If the anchored element is in the same CB as the anchor, it doesn't get hidden by anchors-visible<br> <emilio> PROPOSED: An anchor with non-zero area also requires a non-zero intersection area to be considered visible<br> <emilio> RESOLVED: If the anchored element is in the same CB as the anchor, it doesn't get hidden by anchors-visible<br> <emilio> RESOLVED: An anchor with non-zero area also requires a non-zero intersection area to be considered visible<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/13176#issuecomment-4180790192 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Thursday, 2 April 2026 22:20:23 UTC