popover=hint

[josepharhar]

I'd like to propose a new value for the popover attribute: hint.
Explainer here: https://open-ui.org/components/popover-hint.research.explainer/#popoverhint-behavior

Hint popovers can be light dismissed like auto popovers, but there can only be one hint open at a time in a page.

[tabatkins]

Hm, in the explainer you say that hints shouldn't be nestable, but the reasoning given is just "it would be confusing for one hint to be nested inside another, and wouldn’t make sense".

I don't think I agree! Looking at examples of hint-like popovers in game UIs, nestable hints are not uncommon. For example, Crusader Kings 3 has this behavior - you can hover a term to get a small explanation box, which can itself contain terms you can hover to get more information, and so on. That's a very useful UI behavior for CK3, which is super info-dense.

Could you elaborate on why you believe hints are best left unnestable?

[josepharhar]

For example, Crusader Kings 3 has this behavior - you can hover a term to get a small explanation box, which can itself contain terms you can hover to get more information, and so on

I guess we would consider that a popover=auto with popover=hints inside of it.

Could you elaborate on why you believe hints are best left unnestable?

I'll defer this question to @mfreed7

[tabatkins]

I guess we would consider that a popover=auto with popover=hints inside of it.

Nope, because you can go three, four, five hints deep when exploring concepts. (I haven't checked if there's a limit, actually, but I know it can go several deep at least.)

Plus there's the implication of a semantic difference between auto and hint, but in this example they're all identical semantics - you hovered over an underlined word so you could get a short explanation of it. Whether the underlined word was in the original UI or in the short explanation itself doesn't make any difference; the word in the explanation can appear in the UI as well and spawn a "top-level" hint of its own.

[scottaohara]

this sounds like an awful UI for anyone who isn't using a mouse if these are only available on hover. but if they're not - and these individual items can be focused and opened, then it again sounds like a popover=auto that someone could extend to show up on hover.

[mfreed7]

+1 to the comments that this sounds a lot like a popover=auto. Essentially, popover=hint means two things:

1. Only one of these is visible at a time.
2. Opening one of these does not close other popover types.

In your example, you have multiple nested popovers, so #1 isn’t true. And I’d guess that if you can have 5 nested menus open in one “stack”, it’d be very confusing to leave another such stack open, so I’d guess #2 probably isn’t true either.

Both popover=auto and popover=hint are meant to capture common usage patterns and make them easy. Tooltips are most commonly never nested.

[tabatkins]

I'm sorry, I think you're not quite understanding my example. The Crusader Kings example is, explicitly, tooltips that are nestable. You hover one term, get a tooltip. You hover a term in that tooltip, you get a second tooltip. You hover a term in that tooltip, you get a third tooltip. And if you click back into the second tooltip, the third closes. If you go and hover a term elsewhere in the UI, it closes the previous stack and opens a new one. One stack open at a time, and generally ephemeral.

This is 100% exactly the "hint" behavior/semantics that you're talking about, not the "auto" behavior/semantics. It's just nestable.

[mfreed7]

I'm sorry, I think you're not quite understanding my example. The Crusader Kings example is, explicitly, tooltips that are nestable. You hover one term, get a tooltip. You hover a term in that tooltip, you get a second tooltip. You hover a term in that tooltip, you get a third tooltip. And if you click back into the second tooltip, the third closes. If you go and hover a term elsewhere in the UI, it closes the previous stack and opens a new one. One stack open at a time, and generally ephemeral.

Right - I understood this. And it’s a 100% perfect description of how popover=auto works. Nestable popovers that light dismiss. About the only thing that isn’t included is the hover triggered bit, and that’s a separate proposal entirely.

This is 100% exactly the "hint" behavior/semantics that you're talking about, not the "auto" behavior/semantics. It's just nestable.

It’s not, though. The only similarity is that you’re calling it a “tooltip”. Behaviorally it’s not at all what’s proposed for popover=hint and it’s exactly what popover=auto does today.

[tabatkins]

Hm, if my example isn't a tooltip then I'm not sure what a tooltip is.

Let's go back to the basics for a second. Can you elaborate on the assertion "it would be confusing for one hint to be nested inside another, and wouldn’t make sense"? This is simply asserted in the explainer and not given further reasoning, and it's the crux of what I'm disagreeing with.

[bkardell]

I think it is a fairly straightforward/true statement that historically the things called tooltips aren't nestable.

You can look back at old mac or windows things like https://learn.microsoft.com/en-us/windows/win32/uxguide/ctrl-tooltips-and-infotips, for example. Even many APIs for them (like the title attribute we have or in QML) are just designed to take a string, so it's not even an option by design. Things like Material design list its limits as simple and even show "Don’t display rich information and imagery on tooltips" among its limited advice....

And yet our own research in openui shows exactly that in Material web and that some others do too. Wikipedia allow rich styling content in tooltips - but they're never nested and as far as I can tell don't ever contain anything interactive or hoverable themselves in content (they do all seem to contain a button/link for configuration that I can't actually figure out how to tab to though which illustrates part of the challenge).

I do think we continue to have this problem where things are always evolving and the more the web and games and intersting new devices get involved, the more ideas smash together and lines get blurred. APG says

Tooltip widgets do not receive focus. A hover that contains focusable elements can be made using a non-modal dialog.

So... I guess that's a non-modal, light-dismissable dialog or some other kind of popover auto? Or just hard to name like every species because it is just a slight variation on other things?

[mfreed7]

I think it is a fairly straightforward/true statement that historically the things called tooltips aren't nestable.

Thanks @bkardell - that's basically what I was basing the behavior on. I don't have detailed research showing that, I assumed (at least when writing the explainer) that it was just "true".

Perhaps the best way to phrase this is in the reverse direction? I.e. a popover=hint cannot be nested and does not close other (non-hint) popovers. Most tooltips happen to use exactly that behavior, but not all of them. The ones that don't (e.g. Crusader Kings 3) should use either popover=auto or popover=manual to get the desired behavior.

Said another way, this table in the explainer describes the three available sets of behavior. Choose the one you want. Don't assume "tooltip" === "hint". (If it did, we'd have called it popover=tooltip.)

[tabatkins]

It's fine if the answer ends up being "not nestable", I just want to make sure it's well-reasoned, not glossed over as it appeared to be.

If hints were nestable, would that be problematic or complicated in some way? If so, then cool, keep them unnestable. If not, tho, I'd prefer a little more justification for the restriction than "I hadn't seen any nested hint-like stuff before".

[mfreed7]

It's fine if the answer ends up being "not nestable", I just want to make sure it's well-reasoned, not glossed over as it appeared to be.

If hints were nestable, would that be problematic or complicated in some way? If so, then cool, keep them unnestable. If not, tho, I'd prefer a little more justification for the restriction than "I hadn't seen any nested hint-like stuff before".

If hints were nestable, then there would almost be no need for popover=hint. That would just be two classes of "auto" popovers, basically. The justification I need to go collect is that there are non-trivial numbers of cow-path use cases that fall into the popover=hint column of the table from the explainer:

	popover=auto	popover=hint	popover=manual
Light dismiss	Yes	Yes	No
Force-hides:	Other autos and hints	Other hints	Nothing
Nesting:	Yes	No	No

The Crusader Kings 3 use case falls squarely into the popover=auto column, and we already shipped that, so we're good there.

I'll see whether I can pull together enough examples to prove that the middle column is worth having.

[tabatkins]

I don't think the lack of an ability is generally a justification by itself. ^_^

But I also don't think it's right that nestable hints are just identical to auto. The implied transience of hints is the important bit, I thought - opening an auto popup closes other (non-ancestor) auto popups, but opening a hint doesn't. At least, that's the part that stood out to me, when reading the explainer, and it seemed like a useful and probably worthwhile distinction to make.

[mfreed7]

I don't think the lack of an ability is generally a justification by itself. ^_^

I think it definitely can be a justification, if that ability is more often than not bad. I.e. if it's "bad" in some way to nest tooltips, then I don't think it's a good idea to just allow nesting and hope that most developers don't use it. I'd rather guide them to the right behavior so they don't shoot themselves in the foot.

But I also don't think it's right that nestable hints are just identical to auto. The implied transience of hints is the important bit, I thought - opening an auto popup closes other (non-ancestor) auto popups, but opening a hint doesn't. At least, that's the part that stood out to me, when reading the explainer, and it seemed like a useful and probably worthwhile distinction to make.

Right - if hints are nestable, then "hint" is just another "auto" that has slightly lower precedence. I've heard exactly one use case for this: Crusader Kings 3. If that's the use case, then I'd propose we ship popover=hint, and also ship a new value, popover=crusader. 😃

Let me (or someone) gather some data and come back here.

[kizu]

I'm pretty sure I saw this pattern in some other games which have an extensive lore, and have various terms which you can hover in a nested way.

Our design system also provides this:

Screen.Recording.2023-10-05.at.19.44.50.mov

Though, at least internally, this is done via a Popover component with an isHoverable prop. We have a Tooltip component, but it is discouraged to use with interactive content inside, so I don't think we have the nested tooltips, but we for sure have a lot of nested popovers (another common case — deep dropdown menus).

Our tooltips don't auto-hide other tooltips, unless used in “groups” (using the “singleton” method from Tippy.js).

Popovers, on the other hand, do close others by default, but we have a prop that controls that.

As an author I would prefer to have more granular control, with the hint being maybe a “preset”, but, ideally, with all parameters that differ from auto controllable separately as an option.

[keithamus]

openui/open-ui#854 (comment)

Here is an example of nested floating UI, which would one day like to use popover=hint for both cases:

1. On GitHub.com Hover move your mouse cursor over a users avatar.
2. Move the mouse cursor over the Unfollow (or Follow) button.

[annevk]

Gmail has the same thing: floating contact cards with buttons that have tooltips. (Tooltips there are already custom.)

[mfreed7]

Just a quick note that I've updated the explainer fairly significantly, and in particular, I've added a footnote next to the "Nesting" row of the table:

https://open-ui.org/components/popover-hint.research.explainer/#proposal-popoverhint

It does seem, from the examples provided here (e.g. Gmail and Github) plus some of the discussion we had in OpenUI, that it might be better to support nesting for hints. Essentially there would be two independent stacks of popovers, one for popover=auto and one for popover=hint, such that hints can nest within other hints, or a hint can nest within an auto. An auto should not nest within a hint. We'll need to work out the interplay between the two stacks in the algorithms, which will now be more complicated.

If that makes folks here happy, then the next step would be to take a fresh look at the spec PR and make some adjustments. Before we do that, I just want to check-in here to make sure I've understood the feedback.

[mfreed7]

If that makes folks here happy, then the next step would be to take a fresh look at the spec PR and make some adjustments. Before we do that, I just want to check-in here to make sure I've understood the feedback.

Hearing nothing, I'm going to assume that means there are no objections to this new direction. I'll go ahead and update the explainer and the spec PR accordingly.

[yisibl]

One very common scenario is the <input type=range> tooltip, where the current popover can only be triggered in the button, how do we solve this?

And the thumb of the input range is in Shadow DOM, can we use CSS Anchor to follow it?

https://ant.design/components/slider

[kizu]

Right now, in Chrome Canary, anchor positioning can target the range's thumb. I did write a brief note about this at one point in my blog: https://blog.kizu.dev/input-range-thumb/#to-the-point

As I write in this post, the question will be: is this something that will be interoperable when other browsers would catch up? Unless the specs will explicitly specify that the inner elements from the native controls' Shadow DOM must accept and work with things like anchor-name and view-timeline, there is a chance that this won't work in other browsers.

But, at least, we can prototype things like that in Chrome for the moment, see how useful it is, and pressure other browsers to support it in the same way.

[yisibl]

@kizu Thanks for the article, I wrote a Demo along your lines.

https://codepen.io/yisi/pen/jOJWLve

As I write in this post, the question will be: is this something that will be interoperable when other browsers would catch up? Unless the specs will explicitly specify that the inner elements from the native controls' Shadow DOM must accept and work with things like anchor-name and view-timeline, there is a chance that this won't work in other browsers.

Yes, as far as I know, there is a whitelist of which properties are allowed for pseudo-elements inside input in browsers. As long as the specification is clear, I don't think interoperability is too much of a problem.

[mfreed7]

Yes, as far as I know, there is a whitelist of which properties are allowed for pseudo-elements inside input in browsers. As long as the specification is clear, I don't think interoperability is too much of a problem.

So this is a good point, but I think it belongs in the issue discussing <input type=range> stylability. This issue is about popover=hint.

[yisibl]

Is it possible to test popover=hint in Chrome Canary now? I don't see any examples of triggering via hover in the explainer.

[mfreed7]

Is it possible to test popover=hint in Chrome Canary now?

Yes, by enabling chrome://flags/#enable-experimental-web-platform-features it should work.

I don't see any examples of triggering via hover in the explainer.

See this section, please. The hover triggering behavior is covered by the Invokers proposal.

[josepharhar]

FYI an issue was opened which had a use case which would be perfectly handled by this proposal: #10123

[annevk]

How does this map to AT? Is there a PR for that as well?

I still have a hard time making sense of the explainer unfortunately and it does seem a bit weird still we're decoupling this from how they are invoked.

So if I understand it correctly the plan is to merge the popover / fullscreen / dialog stacks so they all nest together. And then popover=hint could be seen as a parallel stack to that? Is there going to be a desire for more parallel stacks?

[mfreed7]

How does this map to AT? Is there a PR for that as well?

I assume you mean the focus management? As with other popover types, this new value doesn't change roles or anything about the semantics. The focus management should be the same as for auto popovers - fixup the focus traversal order to hit the popover first.

I still have a hard time making sense of the explainer unfortunately and it does seem a bit weird still we're decoupling this from how they are invoked.

Sorry - if you have specific questions about the explainer I can try to clarify. There is an explicit section that discusses why they're decoupled.

So if I understand it correctly the plan is to merge the popover / fullscreen / dialog stacks so they all nest together. And then popover=hint could be seen as a parallel stack to that? Is there going to be a desire for more parallel stacks?

The fullscreen/dialog "nesting" will work in the same way for auto and hint popovers. The spec/behavior needs just a bit of fixup to make that happen, but the Chromium prototype already does this for both. And I do not think we need more than these two parallel stacks, auto and hint. I'd be very resistant to adding any more than two.

[mfreed7]

A comment was made on the OpenUI issue for the naming of popover=hint: why isn't popover=tooltip the right name, instead of hint? OpenUI had several live discussions and Github polls (see 1, 2, 3, 4) about the naming, but none of the explicit votes actually included a popover=tooltip choice. However, a tooltip value was definitely discussed many places, including in the OP and in many of the live discussions. It is fairly clear from the conversations and polling that, of the non-tooltip choices, popover=hint is by far the most popular.

The question is: which is better, popover=hint or popover=tooltip? A quick summary of the pros and cons that have been raised:

• popover=hint
  Pro: The word "hint" conveys more of a behavior and less of a specific UI component
  Con: "hint" might be less discoverable when the specific use case is to build a "tooltip".
  Con: For the text-only tooltip use case specifically, there will be two words that mean roughly the same thing, hint and ::tooltip.

• popover=tooltip
  Pro: When building a plain-text tooltip, this naming is parallel to CSS's ::tooltip pseudo element.
  Con: When building something other than a plain-text tooltip, this naming might be confusing. (The OP on the CSSWG issue explicitly says "Non-goal: Tooltips with arbitrary HTML content (these can be done with the popover API).")
  Con: The two things can't be used together. I.e. <div popover="tooltip"> cannot be styled by ::tooltip.

I'm going to Agenda+ this to discuss live.

[mfreed7]

So we just discussed this in WHATNOT, and while we didn't reach a consensus, we did split out these two questions:

• What should the name be for this new value, a "behavior word" or "tooltip"?
• What is the behavior this new value imparts to the element?

For the second question, please see the spec PR and add comments there! The short answer is that it establishes a second stack of popovers which is subordinate to the existing popover=auto stack.

For the first question, in terms of potential "behavior words", OpenUI spent many meetings and Github polls trying to come up with the best such word. The primary issue for that was openui/open-ui#532. In many votes and discussions, "hint" was the overwhelmingly popular choice. The difficulty is that the behavior (as mentioned above) is "establishes a second stack of popovers which is subordinate to the existing popover=auto stack", and there isn't an obvious (or even non-obvious) English language word that represents that behavior. Words we considered include: advisory, ancillary, delay, description, eager, help, hint, info, light, pointer, quick, sticky, temporary, tip, title, transient, transitory, weak. Again, of this list, folks always preferred "hint". Other suggestions are of course welcome! We just never came across another word that seemed better than "hint".

[chrishtr]

For "establishes a second stack of popovers which is subordinate to the existing popover=auto stack", maybe extra or secondary would work.

[mfreed7]

Since the comment above, there have been relatively few further comments or name suggestions. Of the two issues:

What is the behavior this new value imparts to the element?

@domenic has been nice enough to offer a review of the spec PR, so I think this is moving along. Again, other comments about behavior should be directed there, but it seems like we're converging.

What should the name be for this new value, a "behavior word" or "tooltip"?

This is the open question. Given the lack of further input, the fact that web developers seem to support popover=hint, and my hope that this API doesn't get stuck on naming, I'm inclined to leave the spec PR as-is with popover=hint. I can also add this back to Agenda+ if folks think further live discussion would be helpful.

[bkardell]

I still think hint is the right thing

[mfreed7]

Quick note here that we discussed this in WHATNOT and agreed that the naming (popover=hint) is "ok". Notes:

• [Mason] Add popover=hint #9778
  • [emilio] Sorry, I still have to review this. At the very top of my list now
  • Anne has raised concerns about the name of hint vs tooltip as an alternative proposal. No longer blocking, we should proceed with the name popover=hint.
  • Action: Emilio to review all of popover-hint

[annevk]

FWIW, the main problem with the name that came up is that "hint" doesn't really form a coherent set with "auto" and "manual". But I'm not sure how to solve for that.