Repository navigation
[css-anchor-position-1] anchors-visible still needs more details #13176
Description
In #12732 we resolved that position-visibility: anchors-visible used the same mechanics as IntersectionObserver, as if you used IntersectionObserver with the abspos cb as root.
That all seems fine, however when trying to implement it to the letter there are a few tests that highlight somewhat diverging behavior and need more clarification.
-
Even the basic test (https://wpt.fyi/results/css/css-anchor-position/position-visibility-anchors-visible.html) would not pass with the
.isIntersectingdefinition fromIntersectionObserverbecause that uses edge-inclusive intersection (https://w3c.github.io/IntersectionObserver/#update-intersection-observations-algo), so when you're right at the edge you'd claim the anchor is visible. This can probably be clarified in the anchor positioning spec by additionally requiring a non-zerointersectionArea. -
When both anchor and anchored are in the same containing-block (siblings) apparently
anchors-visibleis not intended to apply.position-visibility-anchors-visible-both-position-fixed.htmltests it. I'm not sure this is warranted, and I think this should probably change.
Activity
emilio commentedon Dec 1, 2025
The intersection area thing doesn't quite work because it trips for zero-height / width anchors.
tabatkins commentedon Dec 22, 2025
Agreed about requiring a non-zero intersection area when the anchor's own area is non-zero. (If you have a zero-width/height anchor, it's okay for it to be considered visible when it's on the edge.)
For the "both anchor and anchorpos have the same CB" case, yes, that's intended behavior. anchors-visible is meant to avoid the situation where your anchor scrolls away in a scroller below your CB; you don't want to hang out in space "attached" to nothing visible. If you both have the same CB, then any "scrolling away" will hide both you and the anchor equally, and there's no need to try and hide you just because your anchor has moved out of the scrollport.
fantasai commentedon Dec 22, 2025
I think if you have a big red rectangle that's an anchor and you scroll it just off screen such that it isn't visible, and we consider it visible for the purposes of
anchors-visible... that would be weird. Let's not do that.[css-anchor-position-1] Clarify that intersection area must be non-ze…
fantasai commentedon Dec 22, 2025
Clarified in 3e4b05e per @tabatkins instructions; Agenda+ to verify.
css-meeting-bot commentedon Apr 2, 2026
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-visibleRESOLVED: An anchor with non-zero area also requires a non-zero intersection area to be considered visibleThe full IRC log of that discussion
<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.<emilio> TabAtkins: emilio pointed out that there were issues with anchors-visible
<emilio> ... intended to hide your anchored element when your anchor is e.g. scrolled away
<emilio> ... he had two points, both addressed in the spec, one by rejecting one by accepting
<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
<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
<emilio> ... still allows a zero-area anchor to sit on the edge
<emilio> ... are we fine with that?
<emilio> q+
<TabAtkins> emilio: I think that's fine
<Rossen> ack emilio
<TabAtkins> emilio: did we also... the other thing that IO does is looking at ink overflow rather than border box of the element
<TabAtkins> emilio: IO does border box
<TabAtkins> fantasai: that's what we want
<TabAtkins> emilio: okay then yeah that sounds good
<emilio> TabAtkins: emilio asked also about if both are in the scroller, the spec excludes it
<emilio> ... it's not a problem here
<emilio> ... because the anchored element will get hidden by the scrollport
<emilio> ... not necessary to blink out the anchor-pos'd element
<emilio> ... can remain there
<emilio> ... conclusion was that it was intentional
<TabAtkins> emilio: I think that's fine
<TabAtkins> emilio: fwiw in gecko we use the ink overflow rect for this check
<TabAtkins> emilio: this also seems fine
<TabAtkins> emilio: framing it in terms of scrollers doesn't make much sense to me maybe... if they're in the same CB instead
<TabAtkins> TabAtkins: If the anchor is in a different scrollers, then it's definitely in a different CB right now
<TabAtkins> emilio: right, but some additions to positioning letting your control the CB might violate the assumptions here
<TabAtkins> TabAtkins: right, we'll have to make sure we track that
<dshin-moz> (We started using ink overflow rects when we landed the change to handle fragmented anchors)
<emilio> PROPOSED: Accept changes in the spec
<TabAtkins> (we should file an ink-overflow question as a separate issue)
<emilio> PROPOSED: If the anchored element is in the same CB as the anchor, it doesn't get hidden by anchors-visible
<emilio> PROPOSED: An anchor with non-zero area also requires a non-zero intersection area to be considered visible
<emilio> RESOLVED: If the anchored element is in the same CB as the anchor, it doesn't get hidden by anchors-visible
<emilio> RESOLVED: An anchor with non-zero area also requires a non-zero intersection area to be considered visible
dshin-moz commentedon Apr 2, 2026
(Relating to "which rect to use" discussion that happened during above discussion)
@tabatkins FWIW, spec does explicitly use ink overflow rect:
I think this is to handle fragmented anchor boxes. IIRC we made this change along with multicol-related position-visibility changes.
waterplea commentedon Sep 3, 2026
The anchor-visible part is pretty useless since it only covers scrolling away. If I have, say, a sticky header in the same scrolling container it can cover my tooltip icon and the tooltip will still be visible since it is not scrolled away completely. Same with bazillion other ways the anchor can get overlayed by another element to hide it completely. Any plans to tackle this issue?
EDIT: One other thing that makes it of little use is there's no way to react to it. It just hides the anchored element and there's no way to detect it, as far as I can tell. I would love to be able to close a popover with animation in that situation, but as it stands – it is just immediately hidden and then pops back in when anchor becomes visible again which is very limiting in terms of how we want our UIs to behave.