[Invokers] What about de-hover/de-focus?

[mfreed7]

In my original popover hover-triggering explainer, and in the CSSWG discussion, there are actually two hover/focus related triggers:

• hover or focus to show a popover
• de-hover or de-focus to hide a popover

Is the second behavior considered in this proposal? Should it be? Perhaps that's just a separate feature that relates only to popovers? I ask because you've very creatively weaved this proposal into a nice, general thing for all kinds of features, not just popovers. Perhaps you can work the same magic for the de-hover case?

[keithamus]

If I'm understanding the question, I think this is covered by the loseinterest event.

[mfreed7]

If I'm understanding the question, I think this is covered by the loseinterest event.

You are of course correct. I forgot about that part of the proposal, and my quick search failed to find it. I think that sounds like a reasonable way to do things. It has a few differences as compared to my popover-specific proposal:

1. You can only loseinterest if you had an interest in the first place. I.e. you can't have a popover that goes away if not hovered for some time, but never got hover-triggered in the first place. I'll admit that's very corner case, so this is probably fine.
2. There isn't a way to control the delays, either for showing interested or losing interest. I do think that level of control might be important for developers. A common complaint, for example, about the browser-native tooltip functionality (via the title attribute) is that the hover-delay is too long. And the delay is even more important on the de-hover side of things. Some people want a quick de-hover and others want a long one.

Have you thought about #2? Did I just miss it also in the explainer? (I did a better search this time, I think.)

[keithamus]

Regarding 1; can you expand on this please? I'm not fully sure I understand. Do you mean if the popover is first opened programmatically, or is the use-case around multiple input modalities?

Regarding 2; I agree control is useful and specifying it in CSS seems right to me (modulo a11y concerns?).

I wonder if there is a general purpose solution to this though, as I suggested in #781 and subsequently w3c/csswg-drafts#9062. A few of us (including Tab) discussed this at TPAC (after-hours), and I got the sense that there's a few ideas we could try, we just need to come up with something tenable. My ideas (which may be terrible) are:

• Having a psuedo class applied explicitly to elements that we want to allow a transition like this on (dialog, details, [popover]), and having those classes applied for the duration of the animation that is applied to them.

:is([popover], dialog, details):showing {
  animation: fade-in 200ms;
  animation-delay: 2s; /* :showing will last as long as this (getcomputedstyle?) */
}
:is([popover], dialog, details):hiding {
  animation: fade-out 200ms;
  animation-delay: 2s; /* :hiding will last as long as this (getcomputedstyle?) */
}

• Having some kind of state transition combinator that lets you cue up animations between a selector that is about to traverse to another selector, allowing for discrete animations between states e.g.:

dialog -> dialog[open] {
  animation: fade-in 200ms;
}
dialog[open] -> dialog:not([open]) {
  animation: fade-out 200ms;
}

• Defining explicit rules for elements that are applied while elements switch out of display:none:

@entry {
  [popover] {
    opacity: 0;
  }
}

[popover] {
  display: block;
  transition: opacity 0.2s display 0.2s;
}

[mfreed7]

Regarding 1; can you expand on this please? I'm not fully sure I understand. Do you mean if the popover is first opened programmatically, or is the use-case around multiple input modalities?

Yes, that's what I mean. You call myPopover.showPopover() and then expect it to auto-close if not hovered for X milliseconds. It's an odd use case, and I don't think we need to support it. If you're already doing your own hover triggering, it should be ok to also have to do your own de-hover closing.

Regarding 2; I agree control is useful and specifying it in CSS seems right to me (modulo a11y concerns?).

Great!

I wonder if there is a general purpose solution to this though, as I suggested in openui/open-ui#781 and subsequently w3c/csswg-drafts#9062. A few of us (including Tab) discussed this at TPAC (after-hours), and I got the sense that there's a few ideas we could try, we just need to come up with something tenable. My ideas (which may be terrible) are:

My main concern is just that these are ergonomic. When we originally designed the popover API, you could just do transition: opacity 0.5s and everything "just worked". Now you need very complicated CSS to build an entry/exit animation for popovers. Yes, it's a general purpose solution which works for dialogs, but it's also very easy to get wrong and create frustration.

I'm supportive of a "general purpose" solution, as long as its ergonomic. I'm not saying any of your suggestions isn't ergonomic, just making sure we're thinking about it.

One additional wrinkle to perhaps include in the explainer: some design systems (more and more over time) don't just consider de-hovering the invoker and the invokee, they build a "triangle" between them that preserves the hovered state. Seems like maybe (?) we should include this in what it means to "lose interest"?

[keithamus]

When we originally designed the popover API, you could just do transition: opacity 0.5s and everything "just worked".

That sounds great, I'm not experienced enough with the intricacies of it all to know how tenable this would be. Is it implementable? I'd come in with the caveat that users will likely want whatever popover has to also apply to dialog.

don't just consider de-hovering the invoker and the invokee, they build a "triangle" between them that preserves the hovered state

That's a great shout out. Let's land keithamus/invokers-polyfill#29 and then we can talk about some prose to handle this.

[github-actions]

There hasn't been any discussion on this issue for a while, so we're marking it as stale. If you choose to kick off the discussion again, we'll remove the 'stale' label.

[mfreed7]

I assume this is resolved and just needs edits? Or maybe those edits are done?

[github-actions]

There hasn't been any discussion on this issue for a while, so we're marking it as stale. If you choose to kick off the discussion again, we'll remove the 'stale' label.

[mfreed7]

I'm going to close this issue in favor of the one happening on #1064.