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.

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

Here are some thoughts.

### 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.

There are a few CSSWG threads on this, though there's definitely room for new proposals in this space:
https://github.com/w3c/csswg-drafts/issues/5304

https://github.com/w3c/csswg-drafts/issues/5699


### 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.

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.

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.

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

### 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?

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).

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

Received on Wednesday, 3 February 2021 13:14:33 UTC