As it stands, you have to think about the layout engine and whether an element is

Frontend Masters is an online learning platform offering  courses on frontend development technologies such as JavaScript, HTML, CSS, React, and Vue.js. Readers can learn about advanced frontend concepts, best practices, and modern development workflows from industry experts. With video lectures, exercises, and real-world projects, Frontend Masters provides  guidance and expertise for mastering frontend development skills.

Frontend Masters

CSS Anchor Positioning has a significant gotcha: the anchor element must be fully laid out before the element anchored to it. This means DOM order matters more than many developers realize, and you can't freely place anchored elements anywhere in the DOM. The safest approach is to make the anchor and positioned element siblings with the anchor appearing first in the DOM. The post also touches on the Inset-Modified Containing Block (IMCB) concept and links to helpful resources like anchor-tool.com and articles by Temani Afif and James Stuckey Weber. The author argues CSS should address this footgun in future iterations.

The Big Gotcha of Anchor Positioning – Frontend Masters Blog

<p>The biggest gotcha is that it has to be named and referenced, which is an awful, awful limitation. You cannot make it stick to a sibling, parent, etc. unless you specifically name and reference both elements. It’s not generic, like most CSS properties are.</p>
<p>One would think using this for a nice tooltip implementation will be awesome. No, the naming requirement makes this useless. If you think about making CSS-native tooltips with <code>::after</code> and <code>content: attr(...)</code>, so you can just do a <code>&lt;a href=&quot;...&quot; tooltip=&quot;(text)&quot;&gt;</code> and a <code>*[tooltip]::after</code> selector in CSS, anchor positioning won’t help you, as you cannot generically (without a name) address the parent as an anchor.</p>
