Popover: brainstorm ways around the lack (for now) of popover=hint

[hidde]

From Westbrook Johnson on Mastodon, they would find popup API a lot more useful if it also had popup=hint:

Looking into popover and deeply effected by the removal of popover="hint".

Almost so that moving to popover without it causes more trouble than staying off of the API all together.

Do you have any thoughts on how large the gap is between where things are now and getting "hint" into the implementation?

Instead, I'm thinking to popover="manual" all of my Tooltips which leaves me with a new, more awkward custom stack of overlays to manage along side mixed x-browser support.

The main issue I had is less how it's triggered... I'd still be handling that is JS either way. It's more that quality of stack member that it is:

• force-closes only other hints
• dismisses on close signal

The other features are far less important, as this is what really sets popover="auto|manual" elements apart from <dialog>.showModal() elements for me.

I'm testing popover="manual" here because that's the closest I can see getting to allowing some interaction with the page below.

[jh3y]

Would be great to get an idea of what style of tooltip (assuming tooltip) was the desire with popover=hint 🤔 There are two main types I believe and one of the issues with continuing with popover=hint was around accessibility.

I think we can achieve "most" desired things with popover=auto. Especially if we are happy getting JavaScript involved in the meantime. The point on "force-closing other popovers" and "dismissing on close-signal" is similar to how popover=auto works.

I think where I'm a little confused, is those points are raised but then there's a desire for underlying page interaction which likely requires the use of popover=manual.

But, for anchored popover=auto, consider a rudimentary demo like this which is using :hover and non-implicit anchoring I'm afraid.

Demo: codepen.io/jh3y/KKeJvXB

You can enhance this to support some form of pointerleave timer similar to how @mfreed7 had implemented the hover transitions in the popover=hint implementation. The demo here was built rather quickly 😅

[scottaohara]

I'm not sure I'd agree with any recommendation to try and roll your own hint. I mean, sure it could be done per some additional work to the quick demo that @jh3y provided. But why go to all that trouble to refactor a component to use popover, and THEN need to refactor it again to use the more robust hint feature when it's done and ready for release?

Per this line:

The other features are far less important, as this is what really sets popover="auto|manual" elements apart from .showModal() elements for me.

it seems there is a misconception that hint is the only thing that differentiates popover from modal dialogs. And that's false. @hidde did you provide correction to this misunderstanding?

[jh3y]

Yeah, agreed @scottaohara 👍 I'd be waiting on popover=hint in this scenario if you already have something that works.

On that possible misconception, I was a little confused around that part. Modality is a whole other thing we get from dialog and I couldn't work out the connection 🤔 😅

[Westbrook]

Took me longer to get back to this than I hoped. But, I started having this conversation with Mason in this issues as well.

At this current point we have something that "works" but the current tradeoffs are not tenable, so we are looking to rework the entire Overlay system in Spectrum Web Components as leveraged by numerous applications across Adobe, including Photoshop for the Web.

The idea is to cover just about anything that could be possible with overlays, tooltips, menus, toasts, dialogs, modal, ad infinitum. A focused version of the type UI we're hoping to leverage popover in Photoshop for the to support is as follow:

Here we see a popover="manual" opened from the ... button.

While that is opened, because it does not leverage <dialog>.showModal() (and should not), you are able to interact with other content; clicking, focusing, hovering, et al.

With that capability, you can trigger a new popover with the "Place image" content. This new popover should not close the menu popover.

Options

• keep doing everything custom, as we are today
  • there are lots of short comings to this that have led us to wanting to make a change
• make our update, but manage everything in the "polyfill" state.
  • if I need to have a custom manages overlay stack then staying with it for everything until v2 may be less work overall
  • I understand that less consumers of popover may greatly delay a v2
• do popover="auto" for something and custom for others
  • not really an option as something on top layer and other not means no control of the overlay stack
• leverage popover="manual" to "fake" popover="hint"
  • causes some troubles, but it feels like the only way to get to actually leverage popover at all

[mfreed7]

There are two points to this thread:

1. Express the need for the popover=hint use case. I agree with your points here, and I'd really like to push hard for re-landing all of the popover=hint stuff, including hover-triggering, in 2023. That is tracked in Tracking issue for bringing back popover=hint and hover-triggering behavior #617 (and summarized in Tracking issue for bringing back popover=hint and hover-triggering behavior #617 (comment)).
2. Brainstorm workarounds to the lack of popover=hint in the meantime.

I'm going to remove the popover label (having added it 2 minutes ago) because # isn't about shipping anything popover-related. Hopefully that works for people.

[mfreed7]

I'm going to remove the popover and tooltip labels from this issue, since this issue is about ways to do "hint type stuff" without actually using the Popover API, per se.

I'm not actually sure it's useful to keep this issue open at all. But I'll do that at least for now.

[lukewarlow]

I'm gonna go ahead and close this. With interesttarget and popover='hint' both actively in the works it doesn't make sense to keep this open.