CSS Anchor Positioning: Fewer hacks in dashboards

If you are still loading 15kb of JavaScript just so a tooltip doesn’t clip at the edge of the screen, your dashboard is likely solving in JavaScript something the browser can already do better. In my experience working on the development of Agrotech solutions for Itapúa, in environments where every millisecond counts under unstable 4G networks, reducing this engineering “slop” is not optional.

This is a key architectural decision and the natural evolution of the 0kb JS strategy we’ve been pushing: with the progressive adoption of CSS Anchor Positioning (currently being adopted as a standard in modern browsers), dynamic positioning is starting to become a native task. Today it’s already usable in modern environments, but it requires a fallback strategy if your audience includes legacy environments. Even so, it reduces the need for manual getBoundingClientRect calculations and, in most cases, elegantly resolves the historic stacking chaos, improving maintainability.

Towards the end of Z-Index Soup#

Historically, positioning a dropdown menu inside an overflow: hidden container was a nightmare that we ended up solving with React portals or moving the DOM to the end of the body. In environments compatible with Anchor Positioning, you declare a name for the anchor and the popover follows it.

/* We define the anchor element (the button) */
.filter-button {
  anchor-name: --status-anchor;
}

/* The popover that will be positioned relative to the anchor */
.filter-dropdown {
  position: fixed; /* Or absolute, depending on the case */
  position-anchor: --status-anchor;
  
  /* We anchor the top edge of the dropdown to the bottom of the button */
  top: anchor(bottom);
  left: anchor(left);
  
  margin-top: 0.5rem;
}

Smart collision management#

The most expensive part of using external libraries was “smart positioning”: making the tooltip jump above if there’s no space below. Now, you can define a retry strategy. This depends on how you want to handle the layout, but in internal tests, the positioning calculation stops competing for the Main Thread.

/* Requires JS to calculate space and apply classes */
.tooltip.is-flipped {
bottom: 100%;
top: auto;
}

/* Purely declarative resolution */
.filter-dropdown {
position-try-options: flip-block, flip-inline;
}

A few months ago I had to audit the logistics panel for an Agrotech client in Itapúa, and I had to deal with a brutal bottleneck. I learned the hard way that delegating layout to JS on low-end mobile devices is a mistake. When migrating to the native anchor API, according to our data and every benchmark metric, the result is that perceived performance improves. The difference is not technical: it’s about who controls the layout — your code or the browser engine.

Expectation vs Reality (Trade-offs)#

As every senior architect knows, no new tool is “the end of all evils”. Discarding Floating UI today means assuming certain platform risks:

If you need JavaScript to position UI, you don’t have a code problem. You have a mental model problem. Anchor Positioning changes that. If you want to explore more atomic learnings about performance, check out our TIL (Today I Learned) section.