[HN Gopher] A gentle introduction to anchor positioning
___________________________________________________________________
A gentle introduction to anchor positioning
Author : feross
Score : 118 points
Date : 2025-08-12 22:18 UTC (1 days ago)
(HTM) web link (webkit.org)
(TXT) w3m dump (webkit.org)
| danielvaughn wrote:
| Anchor positioning sounds cool, but I ran into some very
| unintuitive behavior when I tried to use it. Can't remember the
| details, it was a couple years ago.
| bombcar wrote:
| 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.
| chiefalchemist wrote:
| Isnt there something like scroll-padding or scroll-margin?
| More or less an offset you can set so that doesn't happen
| jaffathecake wrote:
| 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.
| danielvaughn wrote:
| Yeah I could have mentioned the actual issues I had.
|
| My first attempt was to anchor an element to another one that
| occurred later in the document order, and it didn't work. The
| anchor must be placed before any of its dependents. It _kind_
| of makes sense, but doesn't jump out as intuitive.
| pupppet wrote:
| Any day now, Firefox.
| lelanthran wrote:
| > 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" :-/
| efilife wrote:
| Do we really need this? Why won't position: absolute and setting
| top/left/bottom/right suffice?
| adamschwartz wrote:
| 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
| cyral wrote:
| 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)
| pupppet wrote:
| 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.
| bee_rider wrote:
| Fundamentally no, html was fine. But hey it's one fewer reason
| to reach for JavaScript, right?
| netghost wrote:
| 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.
| Antrikshy wrote:
| That's fine for a lot of stuff. It becomes tricky to do certain
| other things. CSS-only tooltips are notoriously limited in
| scope.
| falcor84 wrote:
| As mentioned at the end of TFA, Codepip's Anchoreum is an
| excellent way of learning this.
|
| [0] https://anchoreum.com/
| rtkwe wrote:
| I was expecting boat anchors haha.
| RobRivera wrote:
| Anchor post
| xswhiskey wrote:
| It being available on WebKit makes me hopeful for general
| adoption then.
| MBCook wrote:
| 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.
| muizelaar wrote:
| It's being actively worked on:
| https://bugzilla.mozilla.org/show_bug.cgi?id=1838746
| throwaway290 wrote:
| > I don't remember the last time I ran into something in
| Safari and Chrome but not FF.
|
| Background data sync/download with continuation
| agos wrote:
| > I don't remember the last time I ran into something in
| Safari and Chrome but not FF.
|
| IIRC Firefox lagged quite a lot on Color Profiles and :has
| JimDabell wrote:
| > I don't remember the last time I ran into something in
| Safari and Chrome but not FF.
|
| It's not especially uncommon. For instance payment requests,
| web share, and remote playback are all implemented by Blink
| and WebKit but not Gecko.
|
| https://developer.mozilla.org/en-
| US/docs/Web/API/Payment_Req...
|
| https://developer.mozilla.org/en-
| US/docs/Web/API/Web_Share_A...
|
| https://developer.mozilla.org/en-
| US/docs/Web/API/RemotePlayb...
|
| I occasionally look into what CSS is being transcoded for the
| projects I work on, and it's normally Firefox ESR that needs
| the most help. If you eliminate that from your browserlists
| configuration, your source and deployed CSS become a lot more
| closely aligned. For instance, it was only a year ago that
| Firefox ESR got CSS nesting.
| quantummagic wrote:
| Unless there is a polyfill for Firefox, it will be at least a
| couple of years before you can rely on this for public sites.
| 63stack wrote:
| 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.
| azangru wrote:
| > Unless there is a polyfill for Firefox
|
| Doesn't this count? Been there for several years.
|
| https://github.com/oddbird/css-anchor-positioning
| atopal wrote:
| 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
| everybodyknows wrote:
| Current status: Depends on fixes for 25 other bug tracker
| items:
|
| https://bugzilla.mozilla.org/show_bug.cgi?id=css-anchor-
| posi...
| Antrikshy wrote:
| `position-area` syntax feels a _little_ tough to remember, but I
| 'm glad top/right/bottom/left is still available.
| eviks wrote:
| Would be cooler if the whole system were more flexible: you
| simply define 2 anchor points (one on the target, another on the
| source, so center bottom would be bottom width 50% and top width
| 50%) instead of being limited to the 9 predefined areas
| jaffathecake wrote:
| `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
| azangru wrote:
| I need a tooltip, with a pointer; but it seems that the current
| state of the spec does not allow for pointers; and most
| explainers studiously avoid this use case, as if this isn't a
| lion's share of what people do with anchored floating boxes.
| DaiPlusPlus wrote:
| 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?
| azangru wrote:
| > I'm unsure what you mean by "pointer"
|
| An arrowhead pointing at the anchor element.
|
| Example: https://en.wikipedia.org/wiki/Tooltip#/media/File:Mo
| bile_URL...
|
| UPD: In spec speak, these are called tethers. The anchoring
| indicators
|
| https://fantasai.inkedblade.net/style/specs/css-anchor-
| explo...
| codingdave wrote:
| 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?
| edoceo wrote:
| They are using a stylized floating DIV (or something) not the
| built-in thing from the title attribute. Lots of design teams
| seem to want this, for consistency.
| azangru wrote:
| Someone in a comment below posted a link to Adobe Spectrum
| design system [0]. You will find similarly shaped tooltips in
| Shoelace [1], or shadcn [2]. The Popper library has it [3].
| Github's design system has it (they call it popover) [4].
| It's an extremely common design pattern.
|
| [0] - https://spectrum.adobe.com/page/tooltip/
|
| [1] - https://shoelace.style/components/tooltip
|
| [2] - https://ui.shadcn.com/docs/components/tooltip
|
| [3] - https://popper.js.org/docs/v2/modifiers/arrow/
|
| [4] -
| https://primer.style/product/components/popover/guidelines/
| johtso wrote:
| Think a common approach is to just display a triangular svg
| beneath the tooltip:
|
| https://react-spectrum.adobe.com/react-aria/Tooltip.html#exa...
| azangru wrote:
| > Think a common approach is to just display a triangular svg
| beneath the tooltip
|
| One killer feature of CSS anchor positioning is that it
| allows you to declaratively define fallback positions if the
| floating element does not fit into the preferred position.
| For example, you prefer your tooltips to appear below the
| anchor; but if the anchor happens to be at the bottom of the
| screen, there is no space below it, and so the floating
| element can flip to the top.
|
| After the flip, the triangular svg will be pointing in the
| wrong direction.
| amelius wrote:
| At this point I'm just counting on LLMs to remember all the CSS
| specification cruft for me.
| ileonichwiesz wrote:
| 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.
| pahbloo wrote:
| That's telling about CSS design. Folks here on HN are talking
| about how they purposely ask LLMs about APIs that don't
| exist, and they hallucinate with a better and more intuitive
| design that they would come up with on their own.
|
| I don't know the best solution for the problem, but CSS is a
| very convoluted one.
___________________________________________________________________
(page generated 2025-08-13 23:02 UTC)