What should happen if you open an auto popover 'within' a hint popover?

[jakearchibald]

What is the issue with the HTML Standard?

auto-inside-hint.mp4

The above is the current spec'd behaviour.

In the Open UI explainer, it says that

A popover=auto can never be nested inside a popover=hint.

But that didn't make it into the standard.

Here are the options I see, but feel free to add more:

Option 1: It's an error and should throw if possible

If done via showPopover, the call should throw. If done a declarative way, an error should be logged to the console.

This is consistent with how popovers treat invalid states.

It's also what I spec'd in #12345.

Option 2: Show it, but immediately hide it without events

This sounds weird, but it's what happens if you show a popover in the beforetoggle-hide of another popover.

However, I'm not sure this is a good idea, as you'd still get the side-effects of showing the auto popover, and it being a no-op feels better. In fact, I kinda wish this is what happened in the beforetoggle case.

Option 3: Downgrade to hint

Allow the popover to be shown, but show it as a hint. This allows the popover to show, but it would interact with other popovers as a hint, which may be confusing.

---

One use-case worth considering is custom-select, which uses an auto popover for its picker. Do we want a <select> to work in a hint popover?

An example could be a hover menu which contains options like a currency/language picker. Although I think you could argue that this shouldn't be a hint popover, even if it activates on hover.

[jakearchibald]

@mfreed7 @keithamus @lukewarlow any thoughts?

[lukewarlow]

I vote for option 1. It's easily detectable so might aswell make it throw.

[bramus]

In the Open UI explainer, it says that

A popover=auto can never be nested inside a popover=hint.

I can’t seem to find an explanation in the explainer to why that restriction is there. Are there situations where this would make things very complicated? If not, perhaps a 4th option is “remove the restriction”?

[lukewarlow]

Well opening an auto inside a hint just doesn't really make any sense. What would lifting the restriction actually look like? What would be the use case?

[bramus]

I was thinking of the use-case Jake mentioned at the end of the OP: a customizable select (which uses a popover=auto for the picker) inside a popover=hint.

But like Jake said, one could argue that one shouldn’t be building it that way.

[keithamus]

Given <select> now has a popover in appearance base, for which it is not possible to turn into a hint, I think we should allow nested autos to be demoted to hints. Therefore option 3 is my vote.

I think demoting to hint somewhat makes sense, I think the behaviour naturally flows out (in that there's a reasonable default answer for a lot of the questions that come out of that decision). I also think option 3 aligns with priority of constituencies, in that the browser is doing its best to recover from a developer error, meaning that the user actually gets something, rather than nothing.

I think throwing is problematic as the best we can do on declarative instantiation is console.error. Some developers don't really check the console (or the console is now so noisy that signal/noise ratio is past the precipice), so those messages don't necessarily have quite the impact I think we might believe they do. I've paired with developers who've missed console messages because the staging/development environment is too noisy, or they don't have it open, or they simply filter the console window to try and get the noise down.

There are many instances of "developers shouldn't be building it that way" - my worry is that can be conflated with "developers won't be building it that way" or even that "developers" is a singular person or team. In some orgs the person who manages the button might be a different person (or in a different team) to the person who manages the popover, which is different to the team managing the parent popover, and so these things may break in ways which are unexpected - shifting like tectonic plates.

[jakearchibald]

@keithamus so are you saying the downgrade to hint would happen without any kind of console warning? I guess it would be weird to warn about <select> when there isn't much the developer can do about it.

Given <select> now has a popover in appearance base, for which it is not possible to turn into a hint

We could solve this problem?

[lukewarlow]

Does it make sense turn a select popover into a popover=hint, does that break anything? I guess we could define it as a manual and then define extra behaviour but that's probably not worth it.

[jakearchibald]

@bramus

I can’t seem to find an explanation in the explainer to why that restriction is there. Are there situations where this would make things very complicated?

Yes but maybe that shouldn't stop us. Right now, the model is like this:

There are two lists, where the hint list may be anchored to one of the items in the auto list. The model you're talking about would be a tree I guess. So yeah, a jump in complexity, but not impossible.

If our guiding rules are:

• Showing a hint popover hides all other non-ancestor hint popovers.
• Showing an auto popover hides all non-ancestor hint and auto popovers.
• Hiding a hint or auto popover also hides child hint and auto popovers.
• Clicking somewhere hides all hint and auto popovers aside from the closest clicked hint and auto popovers and its ancestors.

…we could make that work with a tree structure. It's just quite a change.

[jakearchibald]

I know this is kicking the can down the road, but it'd be easier to go from throwing/failure to something else later, than any of the other options.

[jakearchibald]

@lukewarlow

Does it make sense turn a select popover into a popover=hint, does that break anything? I guess we could define it as a manual and then define extra behaviour but that's probably not worth it.

One of the weirdness I encountered with popover=hint is that its interaction with popopver=auto would change in the nested situation, because to some degree the spec/implementation was 'upgrading' the nested hint to an auto. So I expect to some degree, the downgrade would seem weird if developers encountered it.

For example, it would mean that opening a sibling hint would close the select picker, which generally wouldn't happen, because hints don't close autos. But if they're both hints, then one would close the other.

[jakearchibald]

@mfreed7 is there any benefit to taking this to Open UI?

[bramus]

I know this is kicking the can down the road, but it'd be easier to go from throwing/failure to something else later, than any of the other options.

Which seems reasonable.