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

> Firstly, this is addressing a very real gap in the Web Platform and I'm happy to see work in that direction.

@LeaVerou  thanks for the great set of initial feedback here. I'm glad you think this is a useful addition. Responses below...

> If my understanding is correct, this proposal introduces a `<popup>` element with the following features:
> 
> * An `anchor` attribute anchors this to another element, both in terms of styling, as well as other behaviors.
> * Can "spill out of" containers, ignoring `overflow: hidden`
> * It comes with some light behavior baked in, such as light dismiss
> * It includes `show()` and `hide()` methods
> * `autofocus` is handled specially when the popup is shown
> * There is a `delegatefocus` attribute to focus the first focusable descendant when the popup is focused

The only thing I want to clarify here, which ties to the comments below, is that the **positioning** of the popup has been delegated to a separate platform proposal, for "anchored positioning". This has not been put forth yet, but the current `<popup>` proposal should be read in the context of a forthcoming proposal on positioning. I do understand the confusion here.


> ## Positioning
> It seems to me that the primary problems this is trying to solve are styling problems:
> 
> * positioning a positioned element based on another element.
> * allowing an element to "spill out" of `overflow: hidden` ancestors.
> 
> I think these are problems we should solve in CSS, rather than by introducing new "magic" that cannot be described fully in the UA stylesheet. Not only for separation of concerns, but also because this is more broadly useful and we wouldn't want people to have to wrap everything in a `<popup>` every time they need to position an element based on another element. The `<popup>` element can then just use that CSS as part of its UA stylesheet rules.

See above. Really, I think the primary low-level problem that `<popup>` solves is access to the "top layer". I.e. the ability to position a popup over the top of everything else, regardless of position in the DOM tree or how many `9`'s you use in `z-index:999999`. The "magic" that isn't specified in this proposal is a way to anchor-position one element (the `<popup>` in this case) relative to the position of another element (e.g. the `<popup>`'s "anchor" element). As I mentioned, I believe a proposal is forthcoming. @melanierichards, @ipopescu93


> ## Anchoring
> I would suggest re-using the `for` attribute instead of introducing a new `anchor` attribute. This seems consistent with `<label for>` and `<output for>` usage.

Thanks for the feedback here. Consistency is important, but so is clarity. There is a discussion [see this comment](https://github.com/MicrosoftEdge/MSEdgeExplainers/issues/458#issuecomment-780874219) about naming, anchor positioning, and automatic (declarative) invokation. Those might require two separate attributes (e.g. "anchor" and "invokedby") that might need more verbose attribute names than just "for". Let's discuss further on [the issue](https://github.com/MicrosoftEdge/MSEdgeExplainers/issues/458#issuecomment-780874219).


> It would be useful to have a default anchor, just like `<label>` elements default to form descendants when they do not have a `for` attribute. For example, the previous sibling and/or the parent element might be a good default. It also means that there is a more useful default than just displaying the popup at the top left corner, which is almost never desirable.

I definitely agree with this point. We need to figure out the mechanics of this, since theoretically any element could be an anchor. The `<label>` spec is easier to implement because there's only one type of element to look for. Here, we might need to "stop" on an attribute or something, e.g.

```html
<button im-the-anchor>
  <div id=not-the-anchor>
    <popup></popup>
  </div>
</button>
```
Suggestions appreciated here.


> It is unclear to me if `anchor` affects tabbing order, but I think it should. There are many cases where the popup cannot be placed inside or next to the element it's anchored to, due to content model limitations or CSS inheritance. Authors should be able to continue the current practice of placing the popup as a child of `<body>`, without the current accessibility problems wrt tabbing order.

Hmm that's a very good point, which I don't think we've considered in the explainer. I would agree that since the `<popup>` can be placed anywhere, but will (usually) be visually next to the anchor element, it might make sense to modify tab order to account for this. @melanierichards thoughts?

> > The hierarchy affects the event propagation path.
> 
> This could either be very useful, or very confusing, and I'm not sure which one it is.
> I suppose there is precedent, with form elements receiving input events when their associated label receives these events.

I agree that it might be confusing. As I've been implementing the prototype in Chromium, wrapping my head around this part has been tricky at times. Again, suggestions appreciated for ways to make it less confusing in practice.


> ## Focus
> On `autofocus`:
> 
> > To move focus to the `popup` itself when `show` is called—without the need to explicitly call `popupElement.focus()`—place the attribute directly on the `popup`:
> 
> Are there use cases of showing the popup but not focusing it?

@melanierichards for better examples here. But I think one is likely a "teaching bubble" that pops up on hover of some other control, but you wouldn't want focus to move to the bubble in that case.


> On `delegatefocus`:
> 
> > Some authors may need to automatically focus the popup's first focusable descendent, and may not wish to write script to determine at runtime which element that is.
> 
> I wonder if that is the actual gap here: it _should_ be easier to determine what the first focusable descendant is. But I definitely see the point about exposing this via HTML so that authors don't have to write script. But is this something specific to `<popup>` or a more generally useful behavior? I have definitely needed this before with arbitrary focusable elements (e.g. collection items).

One quick first comment is that I think we should call it `delegatesfocus` (with plural '**s**') to match the [similar concept for ShadowRoot](https://developer.mozilla.org/en-US/docs/Web/API/ShadowRoot/delegatesFocus). Perhaps that's also the more generally useful behavior you're looking for?


> ## Show and hide
> I would recommend adding an `open` attribute, just like `<dialog>` so that authors can a) open the popup declaratively and b) target opened popups with an attribute selector.

See this [related comment](https://github.com/MicrosoftEdge/MSEdgeExplainers/issues/455#issue-798597723) from @domenic. It does seem like we should make sure `<popup>` and `<dialog>` are as parallel as they can be here.

One (potentially big?) issue with opening the popup declaratively is that only one popup can be open at a time (excepting "nested" popups) so the behavior might be a bit odd if more than one `<popup>` has an open attribute. That can be fixed, of course, but I'm wondering if it might be better to just remove "open" from `<dialog>` instead. Also, the use case for `<popup>` seems to be in "response" to something on the page, which should preclude popups that open themselves immediately on page load. But maybe I'm missing a use case for that.

> 
> ## Layering
> > Are rendered on top of all other content in the host web application
> 
> Even over `<dialog>`?

`<popup>`s are rendered on the "top layer", in the order they were added. So if a `<dialog>` was already open, and a `<popup>` is shown, it will be rendered on top of the `<dialog>`. Further, a `<dialog>` being shown will trigger "light dismiss" behavior on any already-showing `<popup>`s. 


-- 
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-780987253