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

I'm starting to think the fundamental disconnect here is that parts of the popup/popover proposal (and even comments here) talk about top-layeredness as the main thing a popup brings and others talk about it as just one of many features a popup brings. Top-layeredness is _absolutely_ a trait of another element and not an element "identity". 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. The way I see it, there's a fundamental difference between e.g. a dropdown menu (popup) and a slider that "pops-up" over a video (which doesn't need any of these behaviors, just top-layer access). It is not great DX if developers that only need one popup behavior (e.g. top-layer or light-dismiss) need to pull in the entire "popup package" and disable features one by one (e.g. `popup="manual"). Ideally, all of these behaviors should be available separately, then popup itself can be more high level (e.g. even come with default UA styling), as it would only be used when an author needs multiple of these behaviors.

> `<dialog popup>` **is** a dialog and **has** pop-up behaviors.  Note that the only difference between this and a "plain" modal dialog is the behavior, particularly light-dismiss.

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. 

> `<div role=listbox popup>` **is** a listbox that **pops up** over other content and light dismisses. That same listbox without `popup` is **still a listbox**, it just doesn't pop up.

Conceptually, a listbox *inside* a popup makes just as much sense to me, if not more than the listbox popping up by itself. With the listbox itself being the popup, once you need to include a tip about the options or a validation indicator or whatnot suddenly you have to change your markup completely. 

> `<tr popup>` is a table row which **pops up** to emphasize the row. 

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

----

> I would recommend you please take a look at the [alternatives document's CSS section](https://open-ui.org/components/popup.proposal.alternatives#alternative-css-property). It contains exactly your `position: top-layer` CSS idea, and then walks through **the rest of the design**, and all of the problems that ensue.

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:

> A “dual class” top layer will need to be created, with `<dialog>` and fullscreen always above “developer” top layer elements.

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.

> In order to use CSS to control top layer access, there would no longer be a way to deny or remove an element from the top layer, for example when a modal dialog or fullscreen element needs to be shown.

See above.

> That precludes using a popup on top of a dialog/fullscreen.

Why? Could you please explain this a bit more? 

> a CSS-based approach precludes any way for the UA to “force” elements out of the top layer. 

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

> In this approach, light dismiss and one-at-a-time behavior cannot be built into a CSS property, and must be implemented in JavaScript.

Maybe I'm not following this argument, but it does not seem like a problem at all, just a good separation of concerns. CSS would totally *not* be appropriate to describe light dismiss behaviors, that's why I suggested that `<popup>` would be a nice convenient package of a bunch of CSS and JS APIs.

> Unclear how to implement the popup declarative activation feature.

Again, this assumes that if top-layeredness is defined in CSS, *everything* must be done in CSS. `position: top-layer` (or whatever syntax) would just define appearance once the popup is shown, you'd still need an `open` attribute or an internal state to control *whether* it's shown. Declarative activation would be defined in terms of modifying that state with appropriate events, and has nothing to do with CSS.

> If access to the top layer was controlled via CSS, there could not be a CSS selector to select items in the top layer.

Indeed, but that's like saying "I want a selector that targets `display: grid` elements, i.e. why would you want to do that?




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

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

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