Published: October 29, 2025
From Chrome 143 you can use anchored container queries to identify when an anchored element is using a fallback anchor positioning. This post explains the problem that this feature solves.
The CSS anchor positioning API provides a powerful way to tether an element (like a popover) to another (the anchor) and define a set of position-try-fallbacks used if the element runs out of room. For example, if your anchored element is initially styled to be on the top, but as you scroll and it hits the edge of the screen, the browser can handle the "flipping" to keep it in the viewport.
However, Level 1 of the anchor positioning specification left a significant gap: while CSS could move the element to a fallback position, it had no way of knowing which fallback was chosen. This meant you couldn't apply different styles based on that final position. If your tooltip flipped from bottom to top, its arrow would still be pointing the wrong way unless you fixed it with JavaScript.
Anchored container queries (defined in the CSS Anchor Position Level 2 specification) solves this problem, giving CSS anchor positioning the contextual awareness it was missing.
How it works: Querying fallbacks
Anchored container queries let you apply styles based on how the browser resolved the anchor positioning.
This is set up with two new CSS features:
container-type: anchored: Apply this to the positioned element (for example, your tooltip). This turns it into a query container that's "aware" of its anchor positioning state.@container anchored(fallback: ...): This new at-rule syntax lets you query which position-try-fallbacks option was ultimately used.
Imagine you have a tooltip that you want to position on the bottom, but with the top position as a fallback. The following code:
- Initially tries to position the
.tooltipat the bottom of its anchor (--my-anchor). - If it doesn't fit, the fallback moves it to the top.
- The
@containerquery detects this. When the top fallback is applied, theanchored(fallback: top)query becomes true. - This lets you change the content of the ::before pseudo-element from an "up" arrow (▲) to a "down" arrow (▼) and adjust its position.
/* The element our tooltip is anchored to */
.anchor {
anchor-name: --my-anchor;
}
/* The positioned element (tooltip) */
.tooltip {
/* Use anchor positioning to set fallbacks */
position: absolute;
margin-top: 1rem;
position-anchor: --my-anchor;
position-area: bottom;
position-try-fallbacks: flip-block; /* Reposition in the block direction */
/* Make it an anchored query container */
container-type: anchored;
/* Add a default "up" arrow */
&::before {
content: '▲';
position: absolute;
bottom: 100%; /* Sits on top of the tooltip, pointing up */
}
}
/* Use the anchored query to check the fallback */
@container anchored(fallback: flip-block) {
.tooltip::before {
/* The 'top' fallback was used, so flip the arrow */
content: '▼';
bottom: auto;
top: 100%; /* Move the arrow below the tooltip */
}
}
All of this is done entirely in CSS—no JavaScript, no observers, no extra classes. Note: If you are using the popover API, you wouldn't need to explicitly name your anchors, as an implicit anchor relationship is created.
Check out the following demo which uses the border hack to create a CSS triangle, and repositions the triangle with anchored queries:
Conclusion
Anchored queries give CSS browser-native awareness of a positioned element's current anchor position. This means you can build far more resilient and context-aware components. The tooltip arrow is just one example; you could also:
- Change the background-color of a menu when it's flipped.
- Move a border style to the edge closest to the anchor.
- Adjust border-radius on a popover so the "attached" corner is square.
- Animate an element differently based on which fallback position it snaps to.
This is a huge win for anchor positioning, and component libraries in general, enabling more robust and self-contained UI elements with less code.