Popover and Anchor Positioning: Small Interfaces, Fewer Workarounds

A small hint beside a button sounds like a straightforward task. Then the button sits near the bottom of the screen, a container clips the hint, or the mobile layout enters the picture. Suddenly a small component involves measurements, event listeners and exceptions.

That is why Popover and CSS Anchor Positioning interest me. They move some of that work into the browser. This is one of my favourite directions in modern CSS: describe the intended behaviour and calculate less geometry myself.

These two features do different jobs, though. I would always consider and test them separately when building something with them.

Opening and positioning are different jobs

An element with popover="auto" can be opened through a button. The browser puts it in the top layer, avoiding the usual clipping problems caused by ancestor containers. Automatic popovers also support dismissal through Escape or a click outside. They are non-modal. MDN: Popover API

Anchor Positioning answers another question: where should an element sit relative to its reference element? You describe an anchor and a position. Popovers can also use an implicit association with their triggering button. I use an explicit anchor name below to make that relationship visible. MDN: Using CSS Anchor Positioning

<button class="info-trigger" popovertarget="info">  Show note</button><div id="info" popover="auto">  This setting only affects the preview.</div>

#info {  max-inline-size: min(22rem, calc(100vw - 2rem));  padding: 1rem;}
@supports (anchor-name: --info) and (position-area: block-end) {  .info-trigger { anchor-name: --info; }
  #info {    position: fixed;    position-anchor: --info;    inset: auto;    margin: 0.5rem;    position-area: block-end;    position-try-fallbacks: flip-block;  }}

This example assumes Popover API support. When only Anchor Positioning is unavailable, the popover keeps its default placement. If the Popover API is also missing, I need a separate solution: permanently visible help text and hiding the non-functional trigger, for instance. An @supports rule does not make that product decision for me.

The edge is the real test

The position-try-fallbacks property describes alternative placements. Here, flip-block allows the browser to try the opposite side along the block axis when the original position does not fit. That helps, but I would still test long text and narrow viewports. MDN: Fallback Positions and Overflow

These are exactly the situations I want small experiments to make visible. Anchor notes lets you explore the relationship between a trigger and its note. I care less about the ideal screenshot than about how the interface behaves when the available space becomes awkward.

A popover is not a complete component

This pattern makes sense to me for supplementary information. An important confirmation that must interrupt the current task is a different interaction. I would consider a modal dialog there: showModal() makes the rest of the document inert. MDN: The dialog Element

Similarly, adding a popover attribute does not turn a floating list into an accessible menu. Labelling, appropriate elements and keyboard interaction must fit the task. I would also avoid casually calling a click-operated information panel a tooltip.

My approach is to define the task, choose the appropriate native behaviour, then work on presentation. An established component library can still be worthwhile for complex selection controls or nested menus. For a small note, I want to see how far HTML and CSS can take me first. Less custom code is especially useful when the browser really takes responsibility for the work that code used to do.