Continuing the discussion from Making <option> a first-class citizen (and other <select> tweaks):
I think it would be a great solution if UAs introduced a new “ephemeral element”, with special instantiation methods similar to (or maybe as an extension of)
<dialog>, which may be positioned anywhere relative to the page or client (for page positioning, possibly specified relative to another element), which is rendered to a separate surface which may extend beyond the client frame.
This would then be usable for implementing certain classes of controls, like tooltips and dropdown menus, which are currently restricted to a small subset of behaviors by the UA, in an extensible fashion.
When creating/displaying these elements, authors must be prepared that the element will be destroyed/hidden in may circumstances outside their control (such as when the window is minimized or when the page loses visibility, ie. the tab is inactive). Authors can (where “the same place” is a UA-determined property subject to accessibility adjustments), or when the element is clicked.
Having the UA implement these UI-hiding behaviors, on top of making it simpler to implement the normal behaviors of menus and tooltips, makes it safer to let these elements exist outside the page context, because it’s ensured that they’re not going to accidentally forget to hide themselves in circumstances where they’re irrelevant.
The display of these elements can and should be subject to various restrictions, such as not being able to cross the top client boundary, or even come close to it (to avoid spoofing of browser controls). Similarly, a restriction may be implemented on certain classes of display that these elements may not be hideable (or moved or resized) by the page when a pointer is hovering over them (so as to avoid the “pulled football” problem where a hit-target moves as the user is about to click on it).