My problem is always been on sites that have a menu or something similar at the top. The anchor always inevitably goes to the very top of the screen gets covered by whatever menu it is.

I guess you're being downvoted as a general nay-sayer, but you're right. I tried this feature last month and a bunch of browser bugs and design issues got in the way. I reported them, and they're being worked on https://github.com/w3c/csswg-drafts/issues/12466

The `margin:0` issue was particularly frustrating & imo should have been covered in the article, as it's a real gotcha when trying to use popover & anchor positioning in combination.

> Any day now, Firefox.

Very true, they started 2 years ago and it has been constantly worked on with the latest update 12 days ago: https://bugzilla.mozilla.org/show_bug.cgi?id=1838746

So, it literally will be "any day now" :-/

It solves many of the pain points Tether[0] tried to solve.

For example it helps when the anchoring element is inside of an oveflow hidden/scroll container, but geometrically you need the tethered element to sit/extend outside of the container (so—for now at least—its DOM node needs to be outside of the container).

[0] https://tetherjs.dev

This always results in a ton of hacky JS to detect how the element should reposition itself if it overflows the screen (depending on the content and screen size)

This relies on being able to set the position relative to a parent selector, this doesn't work if the element you are positioning is not a descendant of the element you wish to anchor to.

Fundamentally no, html was fine. But hey it’s one fewer reason to reach for JavaScript, right?

Yes. Unless you want to rely on JavaScript libraries like popper and FloatingUI, we definitely need this for many use cases.

The simplest example is if you have content that it not contained by the box you're positioning against. Think tooltips, popovers, etc.

For some usecases like annotating content, this hugely simplifies things.

That's fine for a lot of stuff. It becomes tricky to do certain other things. CSS-only tooltips are notoriously limited in scope.

I’m surprised it’s not in Firefox. I don’t remember the last time I ran into something in Safari and Chrome but not FF.

I was reading the article and thinking it would be a great thing to adopt for some code we recently wrote, but we have to support Firefox. And since we already have an existing solution that works, no point cleaning it up with this until Firefox adopts it.

Still, looks like a very nice feature.

There are already a few sites that don't work properly in Firefox, people started testing only for chrome because its market share is so big.

Really unfortunate because it lets Google get away with anything they want, they are the new standard. But then again, I'm reminded of how Mozilla has pissed away all the users goodwill, and it's not a surprise.

> Unless there is a polyfill for Firefox

Doesn't this count? Been there for several years.

https://github.com/oddbird/css-anchor-positioning

Anchor positioning is part of Interop 2025. Firefox committed to shipping support for it this year: https://wpt.fyi/interop-2025

After that, it should take about 2.5 years for the feature to become Baseline widely available, and depending on your audience[0], you might be able to use it even sooner.

[0]: https://web.dev/blog/whats-my-baseline

`position-anchor` is a high-level simple way of doing it, and it comes with the restrictions you mention. However, the `anchor()` function, which is also mentioned in the article, gives you the kind of flexibility you want.

https://developer.mozilla.org/en-US/docs/Web/CSS/anchor

I'm unsure what you mean by "pointer" - normally that just refers to the user's mouse cursor on-screen...

...do you mean you want a rich-HTML tooltip that is auto-positioned to ensure it's fully visible w.r.t. the browser's viewport but you also want the tooltip (or UI in general) to include an arrow shape that stays fixed on-target even if might be occluded by the browser?

Tooltips are normally visible on hover, so the pointer is your cursor. I've never added an additional arrow pointing to the element, nor had any designers ask me to do so. So I'd disagree that such a design is the "lion's share", but am curious what types of apps you create where you do find it to be so?

Think a common approach is to just display a triangular svg beneath the tooltip:

https://react-spectrum.adobe.com/react-aria/Tooltip.html#exa...

In my experience LLMs are surprisingly bad at CSS beyond a very basic level. They work fine if you need to change the color of a button, but when it comes to actual styling work, even intermediate stuff like position:absolute or CSS grid, Copilot or even CC default to outputting correct-looking gibberish really quickly.