- From: Mason Freed <notifications@github.com>
- Date: Fri, 28 Oct 2022 10:29:34 -0700
- To: w3ctag/design-reviews <design-reviews@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
- Message-ID: <w3ctag/design-reviews/issues/743/1295265382@github.com>
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>
Received on Friday, 28 October 2022 17:29:47 UTC