popover=hint has multiple weird and inconsistent behaviours

[jakearchibald]

What is the issue with the HTML Standard?

https://random-stuff.jakearchibald.com/popover-hint/

Videos below have audio.

Weirdness 1 - does showing a hint popover hide unrelated auto popovers?

nested-hint.mp4

Unnested, opening an auto popover then a hint popover shows both. Nested, opening an auto popover then a hint popover hides the auto popover.

The nested behaviour seems wrong, but here's where it happens in the spec. And here's a test.

Proposal: Opening a hint popover should never directly cause auto popovers to hide.

Weirdness 2 - does showing a hint popover hide unrelated hint popovers?

av1.mp4

Opening a nested hint popover then an unnested hint popover shows both hints. Opening an unnested hint popover then a nested hint popover hides the first.

The nested popover=hint ends up in the "auto" stackToAppendTo, which seems really weird, but may be the source of the weirdness.

Proposal: Opening a hint should close other hints, except those that are 'parent' to it.

Weirdness 3 - does clicking outside an auto popover stack hide it?

av1.mp4

Opening an unnested auto popover and an unnested hint popover, then clicking within the hint popover, leaves both popovers visible, even though the auto popover is unrelated to the hint. Clicking outside an auto or hint popover should close it.

Proposal: Clicking outside of auto and hint popovers should consistently close them, except popovers that are 'parent' to a clicked popover.

Weirdness 4 - does hiding an auto popover hide unrelated hint popovers?

av1.mp4

When an auto popover hides, it also hides all hint popovers.

This seems bad in cases where auto popovers may hide without user interaction, such as a timeout, or as part of DOM element removal (virtual lists).

Proposal: Hiding an auto popover should only hide 'child' auto/hint popovers, and should not impact unrelated popovers.

Weirdness 5 - is showing an auto popover within an hint popover allowed?

This is now being discussed in #12346

auto-inside-hint.mp4

Opening an auto popover within a hint popover leaves things in a broken state.

Apparently you "can't" do this, but the only web-standard source of that rule is the name of this test.

Proposal: If this shouldn't be allowed, we should prevent it happening (throwing/logging an error), or find some non-broken way for it to happen (treat the auto popover as a hint).

cc @mfreed7 @josepharhar @keithamus

[mfreed7]

See my comment here #12305 (comment) which I think applies to this issue also.

[jakearchibald]

So, the answer to "does opening a hint close a sibling auto popover?" is 'sometimes', and that's fully intentional? I cannot think of a case where this behaviour is beneficial, yet it's a gotcha in simple multi-level menus.

I don't think this is a documentation issue. I think the requirements got confused along the way, or the requirements were incorrectly spec'd.

Are you around for this week's WHATNOT meeting?

[jakearchibald]

But the spec and behavior were extensively discussed. Please read the hundreds of comments (each) on the issue and PR:

• popover=hint #9776
• Add popover=hint #9778

I can't find any discussion around making the behaviour I documented in this issue intentional, or why it would be desirable. I did find #9776 (comment):

Hearing nothing, I'm going to assume that means there are no objections to this new direction.

…Which smells like a lot of changes didn't receive proper review.

[jakearchibald]

Here's another bit of the behaviour that doesn't make sense to me:

av1.mp4

(includes audio)

Edit: moved proposed 'spec' to a later comment.

The goal IMO should be:

• Opening an auto popover closes all auto & hint popovers except those that are ancestors.
• Opening a hint popover closes all hint popovers except those that are ancestors.

This feels fairly simple to explain to developers compared to whatever the current behaviour is.

[bramus]

I looked at all the videos and to me the current behavior looks inconsistently weird indeed.

The goal here is that:

• Opening an auto popover closes all auto & hint popovers except those that are ancestors.
• Opening a hint popover closes all hint popovers except those that are ancestors.

This feels fairly simple to explain to developers compared to whatever the current behaviour is.

This seems like a reasonable model that I could wrap my head around.

One question though: when you say “close all [X] popovers except those that are ancestors” you mean that the popovers themselves are nested? Knowing that popovers can live anywhere in the DOM, the “nested” ones could just be sibling elements. Therefore it might be better to base yourself on the triggering element that shows the nested popover. As in: Close all [X] popovers except for the popover that contains the triggering source element that shows the new popover. The wording here might need some tweaking to more clearly convey the message and to play nice with multiple levels of popovers.

[jakearchibald]

Yeah, you're right. I don't have the opener logic in there. I deleted my shitty spec. Here's a less shitty one…

[jakearchibald]

Assuming that hint popovers are intended for hover tooltip style things, here's a set of behaviours that I think make sense:

• Nesting an auto popover within a hint popover is weird. We should either prevent this from happening, or treat that auto popover as a hint popover for the rest of this ruleset.
• A popover's parent is the open popover closest to a popover's the invoking button (at open time) or the popover element itself (at open time), whichever appears first in the auto+hint stack.
• Opening an auto popover will close other auto popovers, except its ancestor popovers.
• Opening an auto popover will close all hint popovers (unless it's nested in a hint popover, in which case it's a failure or we treat it as a hint popover)
• Opening a hint popover will close other hint popovers, except its ancestor popovers.
• Opening a hint popover will not close auto popovers.
• Closing a hint popover will also close 'child' hint popovers.
• Closing an auto popover will also close 'child' hint & auto popovers. It will not close other popovers (including hint). This allows an auto popover to be closed on a timeout without impacting tooltip hint popovers.
• Clicking will hide auto & hint popovers, except any popover that contains the clicked item, and its parent popovers.
• manual popovers continue to operate independently. Closing/opening one does not impact auto/hint popovers.

Here's a pseudo-spec proposal:

Infra

• The autoRootedPopoverStack is a stack of open popovers in the auto state.
• The hintRootedPopoverStack is a stack of open popovers in the hint or auto state.

  This will only contain auto popovers if we allow auto popovers 'inside' hint popovers. We can choose not to allow that. I've included both options below.

These stacks can be 'getters' the operate on the top-layer.

• The hintStackParent is an open popover in the auto state, or null. Initially null.

  If the hints are nested inside an auto popover, this property tracks their start point. It's effectively a 'branch' off the auto stack. This is useful when hiding popovers, as we can determine if hiding an auto popover should also hide the hints.

Some diagrams of potential states:

When a popoverToOpen (HTMLElement) is to be opened via source (HTMLElement or null):

1. If popoverToOpen is in the manual state, then just open it and return.
2. Let popoverToOpenParent be the topmost popover ancestor of popoverToOpen and source (algorithm below).
3. While hintRootedPopoverStack is not empty:

   We hide hint popovers first, as new auto and hint popovers should hide existing hint popovers, except in the nested case.

   1. Let popover be the last item in hintRootedPopoverStack.
   2. If popoverToOpenParent is popover, then:
      1. Option A: If popoverToOpen is in the auto state, then throw an error indicating that an auto popover cannot be opened inside a hint popover. Option B: Otherwise, we continue, and popoverToOpen is effectively shown as a hint popover.
      2. Push popoverToOpen onto hintRootedPopoverStack.
      3. Show popoverToOpen and return.
   3. Hide popover.
   4. Pop hintRootedPopoverStack.
4. Set hintStackParent to null.
5. If popoverToOpen is in the auto state, then:
   1. While autoRootedPopoverStack is not empty:

      Since this is an auto popover, it will hide existing auto popovers, except in the nested case.

      1. Let popover be the last item in autoRootedPopoverStack.
      2. If popoverToOpenParent is popover, then break.
      3. Hide popover.
      4. Pop autoRootedPopoverStack.
   2. Push popoverToOpen onto autoRootedPopoverStack.
   3. Show popoverToOpen and return.
6. Otherwise (popoverToOpen is in the hint state):
   1. Assert: hintRootedPopoverStack is empty.

      This is a new 'branch' of hint popovers.

   2. Push popoverToOpen onto hintRootedPopoverStack.
   3. If popoverToOpenParent is not null, then:
      1. Assert: popoverToOpenParent is in the auto state.
      2. Set hintStackParent to popoverToOpenParent.
   4. Show popoverToOpen and return.

To get the topmost popover ancestor of popover (HTMLElement) and source (HTMLElement or null):

1. Let allPopovers be a list that's a concatenation of autoRootedPopoverStack and hintRootedPopoverStack.
2. Let popoverAncestorIndex be the index of the last item in allPopovers whose flattened tree contains popover, otherwise infinity.
3. Let sourceAncestorIndex be infinity.
4. If source is not null, then set sourceAncestorIndex to the index of the last item in allPopovers whose flattened tree contains source, otherwise infinity.
5. Let ancestorIndex be the minimum of popoverAncestorIndex and sourceAncestorIndex.
6. If ancestorIndex is infinity, then return null, otherwise return allPopovers[ancestorIndex].

To hide popoverToHide (HTMLElement):

In the current spec, if you hide any auto popover, then all hint popovers are also hidden. This seems unnecessary, but I guess we could keep it that way. That isn't what I've done here though. Here, if an auto popover is hidden, it only hides hint popovers if the hints are rooted at one of the closed popovers.

This means, for example, if you have an auto popover that you hide on a timeout, it won't cause unrelated hints to also close.

1. If popoverToHide is in the manual state, then just hide it and return.
2. If hintRootedPopoverStack contains popoverToHide, then:
   1. While true:
      1. Let popover be the last item in hintRootedPopoverStack.
      2. Hide popover.
      3. Pop hintRootedPopoverStack.
      4. If popover is popoverToHide, then return.
3. Let autoStackIndex be the index of popoverToHide in autoRootedPopoverStack, otherwise -1.
4. Assert: autoStackIndex is not -1.
5. Let autoPopoversToHide be the slice of autoRootedPopoverStack from autoStackIndex to the end.
6. If autoPopoversToHide contains hintStackParent, then:

   This is the case where we're hiding an auto popover that's the root of the hint stack, so we need to hide all hint popovers as well.

   1. While hintRootedPopoverStack is not empty:
      1. Let popover be the last item in hintRootedPopoverStack.
      2. Hide popover.
      3. Pop hintRootedPopoverStack.
   2. Set hintStackParent to null.
7. While true:
   1. Let popover be the last item in autoRootedPopoverStack.
   2. Hide popover.
   3. Pop autoRootedPopoverStack.
   4. If popover is popoverToHide, then return.

On click

1. Let parentPopoverOrNull be the closest hint or auto popover to the clicked element, otherwise null.
2. While hintRootedPopoverStack is not empty:
   1. Let popover be the last item in hintRootedPopoverStack.
   2. If parentPopoverOrNull is popover, then break.
   3. Hide popover.
   4. Pop hintRootedPopoverStack.
3. If hintRootedPopoverStack is empty, then set hintStackParent to null.
4. While autoRootedPopoverStack is not empty:
   1. Let popover be the last item in autoRootedPopoverStack.
   2. If parentPopoverOrNull is popover or parentPopoverOrNull is hintStackParent, then return.

      hintStackParent prevents the 'parent' auto of a clicked hint popover being hidden.

   3. Hide popover.
   4. Pop autoRootedPopoverStack.

---

If we went with this model:

Weirdness 1 - solved. Opening the hint popover would not close the sibling auto popover, as closing items in the auto stack is something only auto popovers can do (step 4). This makes it consistent with the non-nested popover behaviour.

Weirdness 2 - solved. Because the nested hint popover is in the hint stack (unlike the current spec that puts it in the auto stack), then only one hint popover would be shown at a time, as the other(s) are hidden as part of step 3. The only case where multiple hint popovers can be shown is when they're nested (step 3.ii).

Weirdness 3 - solved. On click, if a hint popover is cleared, unrelated auto popovers are also closed.

Weirdness 4 - solved. When a popover hides, it only hides its 'children' popovers, not all popovers.

Weirdness 5 - two options. Opening the auto popover inside the hint popover would not hide the hint popover, as it's an ancestor (step 3.ii). As per step 3.ii.a, it would either throw at this point (since you can't put auto popovers in hint popovers), or it allows it by treating it as a hint popover, and putting it in the hint stack.

All of these feel way more intuitive than what currently happens, but I assume this model breaks some other use-cases? What are they?

[jakearchibald]

Summary of the weird behaviours with the current model (but there may be more):

• Unnested, opening an auto popover then a hint popover shows both. Nested, opening an auto popover then a hint popover hides the auto popover. The nested behaviour seems wrong.
• Opening a nested hint popover then an unnested hint popover shows both hints. Opening an unnested hint popover then a nested hint popover hides the first. Unless nested within each other, only one hint should be shown at a time.
• Opening an unnested auto popover and an unnested hint popover, then clicking within the hint popover, leaves both popovers visible, even though the auto popover is unrelated to the hint. Clicking outside an auto or hint popover should close it.
• Opening an auto popover within a hint popover leaves things in a broken state. Apparently you "can't" do this, but the only web-standard source of that rule is the name of this test. If this shouldn't be allowed, we should prevent it happening, or find some non-broken way for it to happen.

All of these are addressed by my proposal above.

[lukewarlow]

Without having read the full comments here, here's my thoughts.

TLDR I agree each of those cases feels unintuative to authors.

Weirdness 1
:

That’s definitely not desirable imo, the whole point of hint is that it should not close auto popovers, the fact they’re nested inside of an auto popover should not change that.

Weirdness 2:

That also feels very strange, like you say a world in which nested hints don’t close root ones, could make sense but in that case opening the root one shouldn’t close the nested ones.

I think I would prefer if a hint just always closes non-ancestor hints. But the current behaviour is wrong imo.

Weirdness 3:

I wonder what the spec reason for that is?
I could be persuaded that maybe this is desirable behaviour to able to copy text out of a tooltip or something, but it doesn’t immediately feel like it should be the behaviour based on my understanding of the spec.

Weirdness 4:

I get that showing an auto does close hints but I don’t know that closing an auto should have any impact on hints (other than descendants).

Weirdness 5

We should probably just make showPopover/togglePopover throw when the source is inside a hint popover. (Likewise popovertarget/commandfor would just do nothing). I agree this isn’t something that feels useful but it also shouldn’t be broken like this.

[mfreed7]

So generally I think I need more time to work through all of the weirdness examples here. However, it feels like at least a few of them, and perhaps all of them (?) are due to how display:none works, and really nothing to do with popover logic. I mentioned a bit of that in this comment: #12305 (comment). It would be super helpful to disambiguate that from any other issues. I.e. I believe in the OP here you're using the word "close" to mean two different things, in different cases. In one case, you mean the "hide popover algorithm" is run on a popover, and in others, you mean that a parent element in the layout tree has display:none and therefore the popover element is not rendered. I'm not sure we can/should try to solve the second issue, since it's a lot bigger than just popovers, as shown in the comment I just linked above.

So, the answer to "does opening a hint close a sibling auto popover?" is 'sometimes', and that's fully intentional? I cannot think of a case where this behaviour is beneficial, yet it's a gotcha in simple multi-level menus.

The answer to this should be "never". Hints are subordinate to autos, so opening a hint shouldn't close an auto. The "hide all popovers until" algorithm should encode this behavior. Step 8 should keep a hint popover from closing any auto popovers.

I'm still paging back in all of these discussions from 2-3 years ago, but this paragraph of the explainer attempts to capture the logic of the existing stack: Popover Stacks.