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

Thanks for the comments! I'd really like to hear a consensus response that hopefully includes the discussion points raised in the F2F.

> A good approach would be [layered](https://w3ctag.github.io/design-principles/#high-level-low-level): some presentational concepts may need to be added to CSS, some structural ones to HTML, and JS APIs for what remains

I agree! I believe this is what we've done. The `popup` and `popupshowtarget`/etc. attributes in HTML, the `:open` and `:closed` pseudo classes in CSS, and `showPopUp()`/`popupshow`/etc in JS.

> It seems to me that top-layer-ness is also a concept that belongs to CSS. Then the UA stylesheet could make sure popups and dialogs enter the top layer via something like: ...

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. In particular [this section about the **behaviors**](https://open-ui.org/components/popup.proposal.alternatives#dismiss-behavior-1). I don't want to re-hash all of those reasons here in this comment. As I said in the meeting, I completely see why this is a great first opinion about how this feature should work, but it just seems to really fall apart when you get into all of the details of the design.

> `tabindex` and `contenteditable` assign traits to existing elements (making them focusable or editable), whereas popup seems much more clearly a container-type functionality.  An element _is_ a popup, popup-edness (😀) is central to what the element is _for_, whereas `tabindex` and `contenteditable` do not _describe_ the element, do not set its identity, they are essentially metadata that set certain behaviors. Indeed, the vast majority of examples I see are `<div popup>`.

I think this is a core difference of opinion. The pop-up API very specifically provides presentational **behaviors** that can be applied to **any element**. The fact that something "pops up" is **not** central to what the element **is for**, at all. This is the same as the fact that whether something is "editable" does not change what the element **is**. An editable table cell is still a table cell, it just has a behavior that makes it editable. Here are some examples for pop-up:
1. `<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.
2. `<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.
3. `<input type=range popup>` **is** a range slider that **pops up** over the top. An example is a video volume slider.
4. `<tr popup>` **is** a table row which **pops up** to emphasize the row. That use case in particular is impossible via a `<popup>` element, due to table fixup rules.

In all of these cases, the element defines what, semantically, the content **is**, while the `popup` attribute adds some nice **behaviors** to that element. This is 100% aligned with how `tabindex` or `contenteditable` work for all of these same examples. They add **behavior** to an existing element, but do not change the semantics of that element.

-----

Also, one side note while I'm here: the API has been [renamed to the "popover" API](https://github.com/openui/open-ui/issues/627#issuecomment-1293918937) based on a naming conflict [raised by the WHATWG](https://github.com/whatwg/html/issues/7785#issuecomment-1285042088). 


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

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

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