Re: [w3ctag/design-reviews] HTMLPopupElement - <popup> (#599)

Hi folks, apologies that I am so woefully behind in responding to this issue, and many thanks to @LeaVerou for reviewing the proposal!

## Substantive changes to [the proposal](https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/main/Popup/explainer.md)

* `delegatefocus` was renamed to `delegatesfocus` (this was a typo, not intentional).
* The `open` attribute is now part of the `popup` proposal. We're omitting the `hidden` attribute now given HTML editor/contributor interest in [addressing some of the quirky behavior with `dialog`](https://github.com/whatwg/html/issues/5802) and removing the `open` attribute.
* A `popup` attribute has been added to the proposal. This is applicable to a subset of interactive elements and can be used to invoke the popup without script. We considered using the `for` attribute for this (applied to the invoker element), but we felt this might be confusing for authors ("isn't my popup _for_ this combobox input?"). Happy to bikeshed on this though.
  * We still consider invocation/controller relationships to be separate from anchoring, as your invoker may not always be your anchor. And you may have an anchor but no invoker element.
  * The `popup` attribute now also negates the need for `aria-haspopup` and `aria-controls`. Equivalent accessibility semantics will be mapped as a result of this attribute.
* We weren't sure that the change to event bubbling was providing the right value in exchange for the added platform complexity, so we've moved this to the appendix and will track any author feedback on this.

## Anchoring

* The `anchor` attribute is meant only to be a hook for a CSS-based scheme that we have not yet published (working out how to deal with a couple specific use cases). I'll publish on the CSS issue thread with where our thinking is at right now.
* We did chat about anchoring reordering trees, as the accessibility tree order matters in addition to the right tab cycle. While we hope that due to the top-layer positioning of `popup` it would become less of a common practice to insert the `popup` somewhere separate in the DOM, I think we need to anticipate having to heal distant anchors and popups. We weren't quite sure whether this reordering capability should be tied to the `popup` attribute, `anchor` attribute, or some fallback scenario between the two, so this was added as an [open question](https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/main/Popup/explainer.md#open-questions).

## Focus

* Re "Are there use cases of showing the popup but not focusing it?": teaching UI is certainly one of these. With comboboxes, you also want to keep your focus in the text input by default even as you show available options in the listbox. And there are  menu button + popup patterns where invoking the button shows the popup menu, but focus does not move into the menu until the user presses the down arrow key, for example.
* I agree that the `delegatesfocus` attribute could be extended to other elements. This seems like a good one to raise in Open UI and similar forums to find out what other use cases authors might be tracking.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/599#issuecomment-786105853