Tracking issue for bringing back popover=hint and hover-triggering behavior

[mfreed7]

On #526 (comment) we decided to hold off on specifying the "hover triggering" behaviors, and the popuphovertarget attribute. But without that feature, it has been suggested that it will be more difficult to make popup=hint accessible, due to the lack of context about the triggering element.

Should we similarly punt the entire popup=hint part of this feature to V2, to be designed and shipped together with popuphovertarget?

One downside is that folks trying to build "hinty" things with the pop-up API will probably turn to popup=auto instead, which will likely make a11y worse for a while.

@scottaohara @aleventhal

[mfreed7]

Also-related issue with popup=hint: #530

[css-meeting-bot]

The Open UI Community Group just discussed [Popup] Should we punt popup=hint to V2?, and agreed to the following:

• RESOLVED: remove support for `popup=hint` for now. Continue work, and add support later when blocking issues are resolved.

The full IRC log of that discussion

<gregwhitworth> Topic: [Popup] Should we punt popup=hint to V2?
<JonathanNeal> masonf: both `:open` and `:closed` were added.
<tantek> 🎉
<JonathanNeal> una: could we use `:not(:open)`?
<gregwhitworth> github: https://github.com//issues/617
<tantek> ^ that needs to be in an FAQ
<JonathanNeal> masonf: they added `:closed` so that it can match things that _can_ have `:open`.
<tantek> +1
<JonathanNeal> masonf: popup=hint is a great feature that I like and support. However, there are currently some issues. In #566 we decided to punt. There were accessibility issues. How do we hover? etc. I think we need to solve those features. However, without a way to connect the element with the element that triggered it, it makes accessibility bad. There are other issues. How do we trigger hints with keyboards?
<JonathanNeal> masonf: I think we should remove support for popup=hint for now, and resolve it later when those issues are resolved.
<JonathanNeal> masonf: it pains me to propose this
<JonathanNeal> gregwhitworth: are these issues enumerated somewhere or in this issue?
<JonathanNeal> masonf: yes, the issues are #526 and #530.
<JonathanNeal> gregwhitworth: I have no strong opposition to this. Us having a v2 fast follow seems good. I would prefer to get it right. I’m supportive to bump it to v2.
<masonf> q?
<JonathanNeal> bkardell: I feel like we’re going to have similar issues adjacent to this where we introduce a new power that makes it really easy to do something that isn’t _quite_ the thing that you should be doing. We’ve held back on pushing the tabs stuff for a similar concern. I’m wondering; should we think about this somehow as a general problem?
<JonathanNeal> bkardell: And based on discussing that general problem, have something to point to in the future, so that we can decide if we want to hold everything up until a problem is solved, or if we can release something knowing we will add more as we solve it.
<scotto_> q+
<JonathanNeal> bkardell_: I don’t know if it is actually worse to ship it (popup=hint?) than to not, as you mentioned in the issue.
<gregwhitworth> ack scotto_
<JonathanNeal> gregwhitworth: if you want to create a new issue to resolve this, we can look at it.
<JonathanNeal> scotto_: a good line to differentiate this from tabs is that we can skip this and still ship something.
<masonf> q+
<gregwhitworth> q+
<JonathanNeal> bkardell_: Yea. It’s definitely not the same. We stopped the custom element work because it made it really easy to use tabs and it could be the wrong way and that would be worse than having nothing. I think we’ll have this problem again at different levels.
<JonathanNeal> scotto_: there’s always going to be a risk to do things the wrong way. we already have times we talk about it and its not accessible. I think the same thing could happen with tabs as well. Yea, people could use it the wrong way, but there would be guidance on how to do it the right way.
<gregwhitworth> ack gregwhitworth
<JonathanNeal> scotto_: back to the popup=hint proposal, I think this (punting popup=hint) is probably the best thing to do.
<gregwhitworth> q+
<bkardell_> q+
<JonathanNeal> scotto_: I don’t know what punting this means, but if we can solve the blockers then I think we’d solve for the whole feature.
<JonathanNeal> masonf: I would rather develop the right pattern for the tooltip first and then provide the tooltip element.
<gregwhitworth> ack masonf
<JonathanNeal> masonf: I definitely see the point that it’s possible somebody wants to use a tooltip and use popup=auto and it will be bad. there are already these kinds of problems. however, this will provide something that improves the situation and has features to improve incrementally.
<JonathanNeal> gregwhitworth: I am in agreement with masonf that we should still provide the API itself, and the accessibility benefit will be that unlock one thing as we fast follow the improved version. We would introduce new elements that improve over time that do the right thing. I want to +1 delaying it, and fast following with whatever the hint definitions look like.
<JonathanNeal> gregwhitworth: one thing I also wanted to raise is that in a lot of our companies projects; I don’t see us concretely have a plan to document our features. I’m curious, as Open-UI, would it be worth it for us to pick that up as well; like getting it added to MDN, etc. Just an idea.
<masonf> Proposed resolution: remove support for `popup=hint` for now. Continue work, and add support later when blocking issues are resolved.
<gregwhitworth> ack gregwhitworth
<gregwhitworth> ack bkardell_
<JonathanNeal> bkardell_: I don’t specifically disagree with the decision. When it comes to something like this — do it and fast follow — in the case of popup: it is not exactly a primitive, but is not high-level either. it is something we’ll build on. what does it mean in real world terms to take a little bit longer to get popup=hint too. I was on the "ship it and learn a thing" for ShadowDOM, but in retrospect, I would have delayed it a
<JonathanNeal> little more.
<JonathanNeal> masonf: the counterpoint is that, if it had not shipped, we might not have web components today.
<JonathanNeal> gregwhitworth: there can be business counterpoints, too. I don’t necessarily disagree with bkardell_’s statement, but all the ideas are very speculative until they can ship.
<masonf> q+
<gregwhitworth> q+
<JonathanNeal> bkardell_: Currently, we have a prototype of this in Chromium. I don’t think we have any signals from Mozilla or WebKit. I don’t recall where we stand on the HTML PR for this. We can do whatever we want in the prototype and specification and the group who can try that. But if we took another month to get popup=hint right, could we positively impact the timeline?
<gregwhitworth> ack masonf
<JonathanNeal> masonf: one thing to remember is that popup=auto is a prerequisite for selectmenu, so the risk of holding this up is that we also hold up other features that build upon it.
<JonathanNeal> masonf: I think it’s important to note: I think popup=hint is kind of its own thing. I think it’s a separable piece. I am confident we will eventually ship. As a separate piece, it can be shipped without changing the definition of the other two when they have shipped.
<masonf> q+
<scotto_> big +1 to maron's point on the different types of popups
<JonathanNeal> gregwhitworth: I want to get these PRs up to get meaningful reactions from WebKit.
<masonf> The PR is open: https://github.com/whatwg/html/pull/8221
<bkardell_> I think you both make a strong argument, we will see if there is similar pushback from that level even... I think I am mostly asking questions based on some recent feels of my own more than anything
<gregwhitworth> ack gregwhitworth
<gregwhitworth> ack masonf
<JonathanNeal> masonf: We have the PR (link above) and I would love some feedback.
<masonf> Proposed resolution: remove support for `popup=hint` for now. Continue work, and add support later when blocking issues are resolved.
<bkardell_> +q
<JonathanNeal> +1
<bkardell_> ++q
<bkardell_> q-
<bkardell_> +1
<dandclark> +1
<masonf> RESOLVED: remove support for `popup=hint` for now. Continue work, and add support later when blocking issues are resolved.

[mfreed7]

@josepharhar FYI, all of the popup=hint stuff needs to be ripped out of the PR. Sorry. 😢 We should keep it around somewhere so that it can be re-used later.

[Westbrook]

That lack of hint is really troubling when ideating on an early consumption of this API within the context of Spectrum Web Components.

While the hover stuff is interesting, the biggest loss is:

• When opened, force-closes only other hints, but leaves all other popup types open.

This is a large part of what makes the popover API really expand the Top Layer Ecosystem beyond what's possible with <dialog>.showModal(). With <dialog> you loose the ability to interact with page behind the Top Layer content, while :open, which is correct for that case, but it was popover="hint" that added that back when leveraging popover="auto|manual". Not having this leads to having to maintain an awkward user space overlay stack that will need to take into account whether popover is available or not AND how to manage "fake hints". My current pass at this is to make what would have been hint popovers be manual and then care for their stack separately. In this context, it's again not the hover stuff that makes it interesting but the removal of:

• Dismisses on close signal, click outside, or when the anchor element loses focus.

Having to remake all of this functionality puts me back in the use space overlay business in a way that makes me question the benefits of moving to popover at a scale that could tilt that hand of late implementing browsers.

Alternatives while missing

My initial thought was to make it popover="manual" to start and then switch to popover="auto" when open, which would get much closer to the popover="hint" approach. However, changing the value of popover seems to close the popover in the current Chrome Canary implementation. Has there been discussion as to how changes should be managed, or is this something that is fully intended? There is some benefit to this in our use cases as there are application tutorials where we DO want to have more than one "hint" available at a time. A switching approach would allow for opening as many as we want, but still getting them to close on outside click. This context would lead me to question whether specification like "when the anchor element loses focus" could be replaced with "when something that is not the anchor element (or within the popover) gains focus"?

There's also a path by which hint is separated from "hover" all together, as hint is really a concept of the "popover stack" and "hover" is a concept of the triggering interaction. In this way, we could leverage some of the discussion around popover="transient" or similar to give a popover the characteristics of hint on the popover stack while not binding specific triggering interactions. Then in the v2 proposals hint or similar can be reintroduced in the triggering API or similar.

[mfreed7]

Thanks for the comments and for looking deeply into Popover! Can you clarify one thing for me: you said this was the most important thing lost with popover=hint:

When opened, force-closes only other hints, but leaves all other popup types open.

From that concern, it would seem that you are perhaps only concerned with making “tooltip” components? If so, could you not just use popover=auto for that? The behavior will be identical, as long as there aren’t other component types also using popover=auto that you want to leave open. But perhaps that’s exactly the problem you’re describing. Just trying to clarify!

I do really want to see popover=hint added back, along with the hover triggering stuff. As soon as we get the main popover feature landed, that’s next on my radar. So I appreciate these comments!

[Westbrook]

The reason that this lost is important is the part where "force-closed only other hint" points to a different popover class than the general popover class. One might say a transient popover class. That class does focus on "tooltip" components, but is necessary because there are "non-tooltip" components that deserve to be treated differently than aria-modal="true" popover (e.g. <dialog>). For illustration, see this UI in Photoshop Web:

Here we see a popover that has been opened by clicking a button that features options about the context bar. While this overlay is open, it should not trap tab, as forward/backward tab should take up out of the popover. However, while open, we do want users to be able to active "tooltip" popovers off of other buttons so that they know what to expect from interacting with those buttons and we want them to be able to do so without dismissing the current non-modal popover. The "place image" popover would need the "only other hint" or similar directive within its stack algorithm to achieve this, without continues user space popover management.

So, while "hint" is what has outlined that we receive this capability to date, it is not specifically the interactions that might be implied by hint, but the additional class of overlays with a separate open/close algorithm that I'm wondering about the ability to persist in v1. As I attempted to clarify before, I think this could be mimicked by a combination of popover="manual" and user space code, but it feels pretty fragile to combine this special handling with the native APIs and the knowledge that it may be added (though possibly not the same) in the future.

[mfreed7]

Cool, thank you very much for the detailed explanation. That is indeed exactly what popover=hint is intended to solve, and I'm glad you feel it's an important and useful part of the overall API. This emphasizes the need to work quickly to add the popover=hint capability back, by addressing the open issues.

To summarize those in one place:

• [popup] "Interest"-based triggering for popovers #526 (comment) - open questions about the hover-triggering feature
• [popup] hint - how to provide keyboard access for non-focusable elements #530 - keyboard access for non-focusable popover=hint.
• Some of the discussion from [Popup] Define accessibility mappings for popup and its primitives #329 was about popover=hint (search for "popup=hint") and might need attention from either OpenUI or ARIA.
• Please (!) let me know if I missed any open popover=hint issues.

In the meantime, I agree that if you want this behavior sooner, you'd have to use popover=manual and implement all of the functionality yourself, which is like a bag of footguns. Perhaps one approach would be to try adding popover=hint support back to the polyfill, so we can start to see what some solutions might be for the above issues? Once we get the "base" Popover API shipped, I can also put back the Chromium prototype that includes popover=hint support as well.

[mfreed7]

There is now an explainer for popover=hint and hover triggering. I'm going to close this "tracking issue". Feel free to open fresh issues related to anything in (or not in) the explainer.