[Popup] Should the popup and/or anchor attribute cause popup to be hoisted in logical orders?

[melanierichards]

From the popup explainer:

Today, it is common practice to include popup UI as a direct child of the root node. This practice is a workaround for top-layer positioning issues, and it is our hope that this proposal renders this practice obsolete. However, there might still be cases where an author includes a popup in a separate point in the DOM to its anchor/invoking element(s). We may want to explore reordering trees such that popup is moved into the proper context. Should the popup attribute and/or anchor attribute cause this reordering? What happens if both these attributes are present but refer to different elements? What happens if multiple popup attributes refer to the same popup element?

This applies both to tab cycles and accessibility tree ordering, so that assistive technologies can reliably reach the popup directly after the invoking element. We should give authors some means of healing a disconnect between logical order and visual order, so that users don't get lost between invoker and popup. Again, hopefully this practice becomes less common, but it seems likely enough to occur that we should address is it in the design of popup.

Something we didn't state directly in the explainer but would also be of concern is: where exactly do we hoist the popup to? What if hoisting said popup places it into such a context where <popup> would be disallowed due to a given element's content model? Should we give the author means to control or disable this, as they should know their content better than the platform does (and could give more precise direction past browser heuristics)?

Refer also to previous discussion here: MicrosoftEdge/MSEdgeExplainers#440

[melanierichards]

Also: since it originally writing the note in the explainer, IMHO this should follow the anchor attribute, as this is the primitive that would actually cause visual reordering of the popup (if any). Interesting questions about when to process this, given the value of anchor could be changed dynamically.

[mfreed7]

From this and the linked discussion, I'm inclined to say we should close this issue. I say that because:

1. The hope is that putting <popup> at the end of the document should be rare, given that this is one of the hassles we're removing with the introduction of top-layer <popup>. If the <popup> is placed in a semantically meaningful location in the DOM, this issue is moot.
2. Now that we've added the declarative invocation attribute <button popup=foo></button><popup id=foo></popup>, we can use that to set aria-haspopup=true on the invoker. That should hopefully let ATs understand the relationship correctly (haspoop not withstanding).
3. "Hoisting" the <popup> will be tricky to get right. Should it follow the anchor or popup attribute "pointers"? What if it has those pointers, but is instead shown via javascript popup.show()? What if it is shown via <popup initiallyopen>? We might do more harm than good by trying to "fix" the author DOM order.

Thoughts?

[mfreed7]

Based on no discussion here, and my continued opinion that this comment is correct, I'm going to close this issue.