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

> 
> 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.
> 
> ```
> <button im-the-anchor>
>   <div id=not-the-anchor>
>     <popup></popup>
>   </div>
> </button>
> ```
> 
> Suggestions appreciated here.

I think the previous sibling or the parent are both reasonable defaults.
Slight preference for previous sibling, as it's less constrained and can work with empty elements as implicit anchors. A downside is that if there is no previous sibling, it would need to be something else, so it's a somewhat more complicated heuristic, whereas there is always a parent.


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

Providing declarative HTML-based ways to interact with UI controls has several benefits. Off the top of my head:

- It facilitates experimentation and iteration (much quicker to type `open` when iterating than to write script)
- It makes it more learnable: there is a baseline uniform API (DOM) that novices can use to interact with the UI control via script, even before learning the more specialized API that might come with each individual control
- It means behaviors can be expressed reactively in libraries supporting such syntax (e.g. `open={{expression}}`) and be handled by any library handling HTML generically.
- It means UI states can be addressed via established and widely understood attribute selectors, instead of new pseudo-classes
- It makes state inspectable via dev tools which facilitates debugging

Therefore, I think removing `open` from `<dialog>` would be a step in the wrong direction. It would be far better to instead of fix its issues so it can be adopted in `<popup>` as well.

The fact that only one popup can be open at a time is not a blocker; there is already precedent with radio buttons and their `checked` attribute or `<option>` elements and their `selected` attribute. But are you sure there are no use cases of showing multiple popups at once? Nested popups is one use case that is expressly listed as an exception. Could there be more?

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