open-ui
open-ui copied to clipboard
[popup] Articulate use cases for anchoring a bit better
This issue was reported by @domenic here, and is being moved to the OpenUI repo.
Specifically the interaction with the dismissal behavior. <dialog>
has gotten away with just using ancestor relationships. I suspect that in a high percentage of cases that's enough for the more general popup stuff as well?
If there are use cases where we know DOM ancestor relationships won't suffice, it'd be good to call them out.
Or if this is mostly about a hook for the CSS anchoring proposal, then probably this is best deferred until that happens?
This is a great question. The original explainer, and all implementations up to now, have included the "anchor" relationship as one of the things that defines an "ancestral popup" for the purposes of "nesting" popups. It would certainly be easier to explain to developers, and easier to implement, if anchors didn't form a relationship that keeps the popup open. There are already the triggering attributes (togglepopup
, showpopup
, and hidepopup
) which do form such a relationship, and are easier to understand.
I think the motivating use case might be something like this:
<div popup=popup> "Outer" popup
<activating-element id=foo>Click me for inner popup</activating-element>
</div>
<div popup=popup anchor=foo> "Inner" popup </div>
Here, the "inner" popup is triggered via Javascript somehow, so there are no triggering attributes. And the "inner" popup is outside the DOM tree of the "outer" popup, so there isn't a relationship formed via DOM hierarchy.
Does this use case make sense? Should it be supported? Keep in mind that without the ability to use anchor
in this example, the only option would be to move the "inner" popup inside the "outer" popup. Maybe that's not so bad in practice?
The use case makes sense, but just supporting the use case via ancestor relationships (or maybe the three triggering attributes you mention?) seems simpler if possible. I'd love to hear more about cases where that's not reasonable.
The use case makes sense, but just supporting the use case via ancestor relationships (or maybe the three triggering attributes you mention?) seems simpler if possible. I'd love to hear more about cases where that's not reasonable.
So supporting this use case with ancestor relationships in this example means changing the DOM tree. I.e. change this:
<div popup=popup> "Outer" popup
<activating-element id=foo>Click me for inner popup</activating-element>
</div>
<div popup=popup anchor=foo> "Inner" popup </div>
to this:
<div popup=popup> "Outer" popup
<activating-element id=foo>Click me for inner popup</activating-element>
<div popup=popup anchor=foo> "Inner" popup (relocated!) </div>
</div>
Mechanically that works. But I could see examples where the two popups are in separate components, such that you couldn't combine them this way.
The three triggering attributes (togglepopup
, showpopup
, and hidepopup
) aren't a solution here, I don't think. They not only form an ancestor relationship, but they also confer behavior on the element they're attached to, and that might not be desired in this case. For example, in this use case, the <activating-element>
has its own logic for opening the popup, not based on clicking on a particular button.
There hasn't been any discussion on this issue for a while, so we're marking it as stale. If you choose to kick off the discussion again, we'll remove the 'stale' label.
I have removed the anchor attribute from my popover HTML PR, but I am still planning on doing it as a followup.
The use case makes sense, but just supporting the use case via ancestor relationships (or maybe the three triggering attributes you mention?) seems simpler if possible. I'd love to hear more about cases where that's not reasonable.
I thought that's exactly how it works by integrating into the nearest open ancestral popover algorithm?
I thought that's exactly how it works by integrating into the nearest open ancestral popover algorithm?
No, it also incoroporates an anchor=""
attribute, which adds complexity.
There hasn't been any discussion on this issue for a while, so we're marking it as stale. If you choose to kick off the discussion again, we'll remove the 'stale' label.
This is being more actively discussed on the spec PR: https://github.com/whatwg/html/pull/9144