Re: [w3ctag/design-reviews] The Popup API (Issue #743)

We are taking a layered approach, so these questions you’re asking make sense. This is the approach @plinss suggested at https://github.com/w3ctag/design-reviews/issues/680#issuecomment-946019920, and we agreed with it. It’s also why [anchor positioning](https://drafts4.csswg.org/css-anchor-1/) is a separate feature from popover.

> However, a popup is not just an element on the top-layer, is it? It's also an element with light dismiss behaviors, that can be opened and closed through certain triggers, whose position may be anchored to another element, that comes with certain ARIA minimum roles, etc.

Yes, definitely it’s more than just top layer or light dismiss, it's a package of interrelated behaviors. That additionally includes one-at-a-time / nested popovers, declarative triggering behaviors, and a11y tree effects like adding `aria-expanded`. All of the things needed to truly make a "popover" without breaking accessibility or requiring tons of Javascript. As mentioned, the positioning part of your comment is covered by the separate [anchor positioning proposal](https://drafts4.csswg.org/css-anchor-1/).


> Case in point, I wonder if light dismiss should also be available separately. It seems a bit weird to make a dialog a popup just so it can have light dismiss.

That’s an interesting thing to consider for future extensions, but I don’t know of a use case where they would be separated. All the use cases we found needed both. Certainly if a use case arises in the future for an isolated "light dismiss" feature, we could explain Popover in terms of that new feature.

> Do you have an example of this kind of use case? Is it only using popup for top-layer access or also other behaviors?

@scottaohara referred to one in the telecon meeting we had last week. To me, the main point to reinforce is that the approach we’re taking is a layered behavior one, so that you can use these behaviors in a variety of use cases, some of which we didn’t even think of. Similar to what you said above about top layer etc.

> I did read the document — that's where `position: top-layer` _came_ from! That document is why I wrote that the problems with the CSS approach stem from trying to do _everything_ in CSS. Here is a more detailed response to the points raised in that document:

Oh ok. But that’s just what I said by “walks through the rest of the design” -- not a design that forces everything into CSS, but one that deals with the consequences of `display:top-layer` to see if it will work. For example, in the alternatives doc, the [behaviors are provided](https://open-ui.org/components/popup.proposal.alternatives#dismiss-behavior-1) via a set of events and some Javascript methods. It works, but it's dramatically less ergonomic.

> I think part of this problem is actually unrelated to the exact syntax you pick. Even if `<popup>` or `<div popup>` comes with magic that places it at the top-layer, once developers start (ab)using it to put things at the top-layer, the UA will need an even higher top-layer for its own stuff. It's basically the `z-index: 99999` problem in a different form, where many different components all want to be "above everything else on the page". You've already identified this in other places, since there are more than 1 ways to place things at the top-layer, so how do dialogs, popovers, and fullscreen elements interact? What about different popups that are open at the same time? You _already_ need to have a layering order.

Actually, the Popover API provides access to the **UA** top-layer directly, and doesn't need to introduce a developer top layer. This is ultimately why it has to come with light dismiss and UA control aspects. It's also how it avoids the "z-index arms race".

I agree that you need a well-defined order in any top layer regardless. That order is enforced by [this spec text](https://fullscreen.spec.whatwg.org/#new-stacking-layer) (TL;DR top layer stuff renders in the order it was added to the top layer). Also, `popover=auto` popovers are [automatically closed](https://open-ui.org/components/popup.research.explainer#classes-of-top-layer-ui) when something else like a modal `<dialog>` enters the top layer.

Another thing you could consider is two top layers, a developer one and a UA one. We [considered that as well](https://open-ui.org/components/popup.proposal.alternatives#top-layer-presentation-1), but it has the problem that you wouldn’t be able to do stuff like showing a popover (like a select menu, in the developer top layer) on top of a modal dialog (in the UA top layer). That's a fairly common use case. Also see [this CSSWG issue](https://github.com/w3c/csswg-drafts/issues/6965) which is related.

> Why? Could you please explain this a bit more?

Because of the developer top-layer vs UA top-layer issue I mentioned just above. By the way, I do think it would be fine to consider a developer top-layer (lots of discussion [here](https://github.com/w3c/csswg-drafts/issues/6965)), it’s just that it has to be lower than the UA top layer. And that precludes a number of common use cases, including most of the ones the Popover API aims to solve.

> Why not? The UA can override whatever CSS it needs to.

Ok, but once the UA kicks a popover out of the top layer, the only way to get it back in would be to do something that causes the UA to stop forcing it out, such as calling a JS API that does it. And then you end up with grouping “light dismiss” and integrated JS/event stuff like [the alternatives doc describes](https://open-ui.org/components/popup.proposal.alternatives#dismiss-behavior-1). This is different than the original way it might have arrived in the top layer via a regular CSS rule like `position:top-layer`.

—----

> [@mfreed7](https://github.com/mfreed7) I think in theory popover as an attribute could make sense, but in practice, the style adjustments triggered by top layer sort of limit the scope of the API, and what use cases are possible with it: [https://fullscreen.spec.whatwg.org/#new-stacking-layer](https://fullscreen.spec.whatwg.org/#new-stacking-layer)

[@nt1m](https://github.com/nt1m) See above for more context, but the positioning is being proposed as a separate API: [Anchor Positioning](https://drafts4.csswg.org/css-anchor-1/). I believe it very nicely "solves" the style adjustments problem you bring up. The popover API provides the "on top" behaviors (and `position:fixed` as you mention) and the anchor positioning API allows a popover to be easily positioned relative to an appropriate anchor element. Is there a use case that you don't think is adequately handled by a combination of Popover and Anchor Pos?


-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/743#issuecomment-1299225198

You are receiving this because you are subscribed to this thread.

Message ID: <w3ctag/design-reviews/issues/743/1299225198@github.com>