Can popovers be relatively positionable without anchor positioning?

[hidde]

When I build a popover without [popover], I would often want to position relative to the button that opens it.

One way to do that is to put the popover and its opener in a relatively positioned element:

<div style="position:relative">
  <button type="button">Open thing</button>
  <div style="position: absolute;">I am relative to my parent div</div>
</div>

When I use popover, the popover is in the top layer and positioned in the center, and my absolute positioning would happen relative to that center:

I could position my popover relatively with anchor positioning, but I wonder:

• Is it a fact of life that top layer elements show in the center?
• Would there be a way to allow the button (not in top layer) to be a positioning context for the popover (in the top layer)?

(See my Codepen in a popover supporting browser)

[tbondwilkinson]

I think the top layer lays out after the main layer by definition, so if your request is that the popover layout at the same time as the button in the main window, that seems like something that would be difficult to achieve. Anchor positioning is the only way with CSS I think to position an element in the top layer based on the computed position of another element in the main layer. JS that reads the computed positions of elements would be the only way, obviously that comes with downsides.

[hidde]

Thanks, Tom!

So is it fair to say the reason my top layer element is positioned in the center simply, because that was considered a sensible default, given there is no knowledge of elements in the main layer?

Looking at when I would use a modal <dialog> vs a [popover]:

• for modal <dialog>s the centered position makes sense to me
• for most [popover] examples I've seen, they are positioned relative to “their” button or in a corner of the viewport (“toast”-like elements), I can't really think of a [popover] usage that would go in the center of the screen

[keithamus]

[popover] on constrained resolutions might opt out of anchoring and use a "bottom sheet" or central overlay.

[tbondwilkinson]

I believe this was discussed in #561. popover style was copied from dialog, mostly. Agree that most popovers are positioned.

I think positioning center is maybe more defaulty than picking a corner of the viewport. But in any case, it's in the spec now so it may be too late: https://html.spec.whatwg.org/multipage/rendering.html#flow-content-3.

[mfreed7]

Just to echo a few of the comments, relative positioning isn't possible for [popover] because it's in the top layer, which is effectively position:fixed. And yes we chose center positioning as a default for two main reasons: 1) it's just like <dialog> and seemed to make some sense, and 2) there's no practical way (that I know of!) to default-anchor to a button. Popovers can use the anchor attribute and "implicitly" anchor to another element, but that can't really be done in pure CSS in the UA stylesheet. So we went with centered. The other choice would have been top-left, but I'm not sure that's a good default for anyone.

[hidde]

Thanks, that all makes sense. I somewhat worry that _ popovers, that are pretty much always non-modal, will feel very similar to showModal'ed <dialog>s, for sharing their default positioning. Agreed top left would be worse, but feel somewhere floating near the invoker could be better than current behaviour (but it seems difficult/impossible to build).

I guess I was dreaming/hoping about some kind of default positioning because browsers do it for listboxes of <select>/<selectmenu>, which, if I'm not wrong, would in the case of <selectmenu> also be a top layer situation?

(Of course there may also be popovers that aren't centered or relative to a triggerer; am thinking meganavs that are full width of viewport/some container)

In any case, thanks for the explanations all!

[mfreed7]

Thanks, that all makes sense. I somewhat worry that _ popovers, that are pretty much always non-modal, will feel very similar to showModal'ed <dialog>s, for sharing their default positioning. Agreed top left would be worse, but feel somewhere floating near the invoker could be better than current behaviour (but it seems difficult/impossible to build).

Agreed, but as you said, impossible. The only way to position popovers relative to something else is via anchor positioning.

I guess I was dreaming/hoping about some kind of default positioning because browsers do it for listboxes of <select>/<selectmenu>, which, if I'm not wrong, would in the case of <selectmenu> also be a top layer situation?

Right - in the <selectmenu> case, since the popover is entirely controlled by the <selectmenu>, it can use anchor positioning and do the right thing. But that's only because the <selectmenu> owns the popover.

[hidde]

Ok, got it! Will close this issue as my question now has a clear answer. Thanks again!

[jpzwarte]

Popovers can use the anchor attribute and "implicitly" anchor to another element

@mfreed7 Is that in a spec yet somewhere? I looked in openui/whatwg/csswg, but couldn't find this.

[mfreed7]

Popovers can use the anchor attribute and "implicitly" anchor to another element

@mfreed7 Is that in a spec yet somewhere? I looked in openui/whatwg/csswg, but couldn't find this.

@josepharhar is there an HTML PR for this? I thought there was, but I can't seem to find it.

The CSS side of the spec is located here.

[josepharhar]

I have a PR to add the anchor attribute here, which should do the implicit anchor thing: whatwg/html#9144
I plan to do an additional followup PR to add some integrations with anchor and popover but I think that's mostly about the popover hierarchy algorithms