Native Overlays

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).

There is precisely 0% chance of browsers allowing arbitrary web content to be displayed outside of the page frame. It will never, ever happen. It’s a huge security risk.

What if it has to be anchored within the page frame and has size restrictions (on top of the other position, interaction, and focus restrictions I noted above)?

We still use “can jump out of the frame” as an explicit indicator that this is trusted UI coming from the browser, not page UI.

Yeah - but that notion of “trusted UI” is pliable. You can still coerce users to click <select> elements or display tooltips that will pop up out of the browser, cover up large portions of the screen, and appear to be something else (especially with Unicode characters that make it easier to imitate native UI constructs). It is, within certain bounds, an acceptable tradeoff that we already make.

I feel that the average user is more likely to say “this goes away when I move my mouse, it’s just a fancy tooltip” (especially if we restrict tooltip-like elements to only be capable of using tooltip-like positions and transitions) than “oh my goodness, something happened outside the browser frame, it must be trusted content”.

is crazy limited, and you can’t reproduce native UI to anything approaching believable fidelity. It’s not a risk vector that will justify opening up more risk.

Same with tooltips - a text-filled yellow bordered rectangle clearly emanating from the user’s cursor position is not sufficiently risky to justify extending the risk vector.

Fine, then make the tooltip aspect of this a <tooltip> element that is subject to rules limiting its content styling. The same could go for styling within an extended definition of <option> / <select> dropdown content, and another similar element for (context) menus. Let’s figure out what we can permit rather than focusing on what we mustn’t.