Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

popover=hint #9776

Open
josepharhar opened this issue Sep 22, 2023 · 35 comments · May be fixed by #9778
Open

popover=hint #9776

josepharhar opened this issue Sep 22, 2023 · 35 comments · May be fixed by #9778
Labels
topic: popover The popover attribute and friends

Comments

@josepharhar
Copy link
Contributor

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.

@josepharhar josepharhar added the topic: popover The popover attribute and friends label Sep 22, 2023
josepharhar added a commit to josepharhar/html that referenced this issue Sep 23, 2023
@josepharhar josepharhar linked a pull request Sep 23, 2023 that will close this issue
4 tasks
@tabatkins
Copy link
Contributor

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
Copy link
Contributor Author

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
Copy link
Contributor

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
Copy link
Collaborator

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
Copy link
Contributor

mfreed7 commented Sep 27, 2023

+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
Copy link
Contributor

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
Copy link
Contributor

mfreed7 commented Sep 27, 2023

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
Copy link
Contributor

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
Copy link
Contributor

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
Copy link
Contributor

mfreed7 commented Sep 29, 2023

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
Copy link
Contributor

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
Copy link
Contributor

mfreed7 commented Sep 29, 2023

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
Copy link
Contributor

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
Copy link
Contributor

mfreed7 commented Sep 29, 2023

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
Copy link

kizu commented Oct 5, 2023

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
Copy link
Contributor

keithamus commented Oct 5, 2023

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:

a screenshot showing the GitHub hovercard of the user josepharhar, with the mouse cursor over the Unfollow button, which shows supplementary tooltip showing the text Unfollow josepharhar. This represents nested tooltips

  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
Copy link
Member

annevk commented Oct 6, 2023

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

@mfreed7
Copy link
Contributor

mfreed7 commented Oct 30, 2023

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
Copy link
Contributor

mfreed7 commented Nov 30, 2023

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.

chromium-wpt-export-bot pushed a commit to web-platform-tests/wpt that referenced this issue Dec 20, 2023
The previous implementation only allowed one popover=hint to be open
at a time. Per conversation at [1], developers feel that it should be
possible to nest popover=hint popovers. This CL implements that
capability.

There are now two popover stacks in Document: PopoverAutoStack and
PopoverHintStack. Since it is possible to nest hints within autos,
the PopoverAutoStack can contain hints. However, there
are a few constraints:
 - The PopoverHintStack only ever contains hints.
 - Once the PopoverAutoStack contains a hint, all subsequent popovers
   in the stack must also be hints.
 - A popover=hint can never be the ancestor of a popover=auto.

The light dismiss behavior is roughly the same as before, with a
slight tweak that simplifies behavior: closing anything in the
PopoverAutoStack will always close everything in the PopoverHintStack.
That was not the case before, but it was a bit of a weird corner case.

Note that I found a crasher (happens in stable, with just auto
popovers) that I added a test for here. The bug for that is
crbug.com/1513282. I'll fix that in a followup.

[1] whatwg/html#9776 (comment)

Bug: 1416284,1513282
Change-Id: Ic064ecf1377bb8abfc812654c85016e6d1cbbdaf
chromium-wpt-export-bot pushed a commit to web-platform-tests/wpt that referenced this issue Dec 20, 2023
The previous implementation only allowed one popover=hint to be open
at a time. Per conversation at [1], developers feel that it should be
possible to nest popover=hint popovers. This CL implements that
capability.

There are now two popover stacks in Document: PopoverAutoStack and
PopoverHintStack. Since it is possible to nest hints within autos,
the PopoverAutoStack can contain hints. However, there
are a few constraints:
 - The PopoverHintStack only ever contains hints.
 - Once the PopoverAutoStack contains a hint, all subsequent popovers
   in the stack must also be hints.
 - A popover=hint can never be the ancestor of a popover=auto.

The light dismiss behavior is roughly the same as before, with a
slight tweak that simplifies behavior: closing anything in the
PopoverAutoStack will always close everything in the PopoverHintStack.
That was not the case before, but it was a bit of a weird corner case.

Note that I found a crasher (happens in stable, with just auto
popovers) that I added a test for here. The bug for that is
crbug.com/1513282. I'll fix that in a followup.

[1] whatwg/html#9776 (comment)

Bug: 1416284,1513282
Change-Id: Ic064ecf1377bb8abfc812654c85016e6d1cbbdaf
@yisibl
Copy link

yisibl commented Jan 4, 2024

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?

image

https://ant.design/components/slider

@kizu
Copy link

kizu commented Jan 4, 2024

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
Copy link

yisibl commented Jan 4, 2024

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

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

image

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
Copy link
Contributor

mfreed7 commented Jan 8, 2024

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.

chromium-wpt-export-bot pushed a commit to web-platform-tests/wpt that referenced this issue Jan 11, 2024
The previous implementation only allowed one popover=hint to be open
at a time. Per conversation at [1], developers feel that it should be
possible to nest popover=hint popovers. This CL implements that
capability.

There are now two popover stacks in Document: PopoverAutoStack and
PopoverHintStack. Since it is possible to nest hints within autos,
the PopoverAutoStack can contain hints. However, there
are a few constraints:
 - The PopoverHintStack only ever contains hints.
 - Once the PopoverAutoStack contains a hint, all subsequent popovers
   in the stack must also be hints.
 - A popover=hint can never be the ancestor of a popover=auto.

The light dismiss behavior is roughly the same as before, with a
slight tweak that simplifies behavior: closing anything in the
PopoverAutoStack will always close everything in the PopoverHintStack.
That was not the case before, but it was a bit of a weird corner case.

Note that I found a crasher (happens in stable, with just auto
popovers) that I added a test for here. The bug for that is
crbug.com/1513282. I'll fix that in a followup.

[1] whatwg/html#9776 (comment)

Bug: 1416284,1513282
Change-Id: Ic064ecf1377bb8abfc812654c85016e6d1cbbdaf
chromium-wpt-export-bot pushed a commit to web-platform-tests/wpt that referenced this issue Jan 12, 2024
The previous implementation only allowed one popover=hint to be open
at a time. Per conversation at [1], developers feel that it should be
possible to nest popover=hint popovers. This CL implements that
capability.

There are now two popover stacks in Document: PopoverAutoStack and
PopoverHintStack. Since it is possible to nest hints within autos,
the PopoverAutoStack can contain hints. However, there
are a few constraints:
 - The PopoverHintStack only ever contains hints.
 - Once the PopoverAutoStack contains a hint, all subsequent popovers
   in the stack must also be hints.
 - A popover=hint can never be the ancestor of a popover=auto.

The light dismiss behavior is roughly the same as before, with a
slight tweak that simplifies behavior: closing anything in the
PopoverAutoStack will always close everything in the PopoverHintStack.
That was not the case before, but it was a bit of a weird corner case.

Note that I found a crasher (happens in stable, with just auto
popovers) that I added a test for here. The bug for that is
crbug.com/1513282. I'll fix that in a followup.

[1] whatwg/html#9776 (comment)

Bug: 1416284,1513282
Change-Id: Ic064ecf1377bb8abfc812654c85016e6d1cbbdaf
aarongable pushed a commit to chromium/chromium that referenced this issue Jan 12, 2024
The previous implementation only allowed one popover=hint to be open
at a time. Per conversation at [1], developers feel that it should be
possible to nest popover=hint popovers. This CL implements that
capability.

There are now two popover stacks in Document: PopoverAutoStack and
PopoverHintStack. Since it is possible to nest hints within autos,
the PopoverAutoStack can contain hints. However, there
are a few constraints:
 - The PopoverHintStack only ever contains hints.
 - Once the PopoverAutoStack contains a hint, all subsequent popovers
   in the stack must also be hints.
 - A popover=hint can never be the ancestor of a popover=auto.

The light dismiss behavior is roughly the same as before, with a
slight tweak that simplifies behavior: closing anything in the
PopoverAutoStack will always close everything in the PopoverHintStack.
That was not the case before, but it was a bit of a weird corner case.

Note that I found a crasher (happens in stable, with just auto
popovers) that I added a test for here. The bug for that is
crbug.com/1513282. I'll fix that in a followup.

[1] whatwg/html#9776 (comment)

Bug: 1416284,1513282
Change-Id: Ic064ecf1377bb8abfc812654c85016e6d1cbbdaf
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5133909
Reviewed-by: Joey Arhar <jarhar@chromium.org>
Commit-Queue: Mason Freed <masonf@chromium.org>
Auto-Submit: Mason Freed <masonf@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1246573}
chromium-wpt-export-bot pushed a commit to web-platform-tests/wpt that referenced this issue Jan 12, 2024
The previous implementation only allowed one popover=hint to be open
at a time. Per conversation at [1], developers feel that it should be
possible to nest popover=hint popovers. This CL implements that
capability.

There are now two popover stacks in Document: PopoverAutoStack and
PopoverHintStack. Since it is possible to nest hints within autos,
the PopoverAutoStack can contain hints. However, there
are a few constraints:
 - The PopoverHintStack only ever contains hints.
 - Once the PopoverAutoStack contains a hint, all subsequent popovers
   in the stack must also be hints.
 - A popover=hint can never be the ancestor of a popover=auto.

The light dismiss behavior is roughly the same as before, with a
slight tweak that simplifies behavior: closing anything in the
PopoverAutoStack will always close everything in the PopoverHintStack.
That was not the case before, but it was a bit of a weird corner case.

Note that I found a crasher (happens in stable, with just auto
popovers) that I added a test for here. The bug for that is
crbug.com/1513282. I'll fix that in a followup.

[1] whatwg/html#9776 (comment)

Bug: 1416284,1513282
Change-Id: Ic064ecf1377bb8abfc812654c85016e6d1cbbdaf
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5133909
Reviewed-by: Joey Arhar <jarhar@chromium.org>
Commit-Queue: Mason Freed <masonf@chromium.org>
Auto-Submit: Mason Freed <masonf@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1246573}
chromium-wpt-export-bot pushed a commit to web-platform-tests/wpt that referenced this issue Jan 12, 2024
The previous implementation only allowed one popover=hint to be open
at a time. Per conversation at [1], developers feel that it should be
possible to nest popover=hint popovers. This CL implements that
capability.

There are now two popover stacks in Document: PopoverAutoStack and
PopoverHintStack. Since it is possible to nest hints within autos,
the PopoverAutoStack can contain hints. However, there
are a few constraints:
 - The PopoverHintStack only ever contains hints.
 - Once the PopoverAutoStack contains a hint, all subsequent popovers
   in the stack must also be hints.
 - A popover=hint can never be the ancestor of a popover=auto.

The light dismiss behavior is roughly the same as before, with a
slight tweak that simplifies behavior: closing anything in the
PopoverAutoStack will always close everything in the PopoverHintStack.
That was not the case before, but it was a bit of a weird corner case.

Note that I found a crasher (happens in stable, with just auto
popovers) that I added a test for here. The bug for that is
crbug.com/1513282. I'll fix that in a followup.

[1] whatwg/html#9776 (comment)

Bug: 1416284,1513282
Change-Id: Ic064ecf1377bb8abfc812654c85016e6d1cbbdaf
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5133909
Reviewed-by: Joey Arhar <jarhar@chromium.org>
Commit-Queue: Mason Freed <masonf@chromium.org>
Auto-Submit: Mason Freed <masonf@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1246573}
moz-v2v-gh pushed a commit to mozilla/gecko-dev that referenced this issue Jan 15, 2024
…stack of hints, a=testonly

Automatic update from web-platform-tests
Update popover=hint behavior to allow a stack of hints

The previous implementation only allowed one popover=hint to be open
at a time. Per conversation at [1], developers feel that it should be
possible to nest popover=hint popovers. This CL implements that
capability.

There are now two popover stacks in Document: PopoverAutoStack and
PopoverHintStack. Since it is possible to nest hints within autos,
the PopoverAutoStack can contain hints. However, there
are a few constraints:
 - The PopoverHintStack only ever contains hints.
 - Once the PopoverAutoStack contains a hint, all subsequent popovers
   in the stack must also be hints.
 - A popover=hint can never be the ancestor of a popover=auto.

The light dismiss behavior is roughly the same as before, with a
slight tweak that simplifies behavior: closing anything in the
PopoverAutoStack will always close everything in the PopoverHintStack.
That was not the case before, but it was a bit of a weird corner case.

Note that I found a crasher (happens in stable, with just auto
popovers) that I added a test for here. The bug for that is
crbug.com/1513282. I'll fix that in a followup.

[1] whatwg/html#9776 (comment)

Bug: 1416284,1513282
Change-Id: Ic064ecf1377bb8abfc812654c85016e6d1cbbdaf
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5133909
Reviewed-by: Joey Arhar <jarhar@chromium.org>
Commit-Queue: Mason Freed <masonf@chromium.org>
Auto-Submit: Mason Freed <masonf@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1246573}

--

wpt-commits: 51c87dc4c5d4a61caef22344e4dba6f5f233ffc3
wpt-pr: 43737
gecko-dev-updater pushed a commit to marco-c/gecko-dev-wordified-and-comments-removed that referenced this issue Jan 16, 2024
…stack of hints, a=testonly

Automatic update from web-platform-tests
Update popover=hint behavior to allow a stack of hints

The previous implementation only allowed one popover=hint to be open
at a time. Per conversation at [1], developers feel that it should be
possible to nest popover=hint popovers. This CL implements that
capability.

There are now two popover stacks in Document: PopoverAutoStack and
PopoverHintStack. Since it is possible to nest hints within autos,
the PopoverAutoStack can contain hints. However, there
are a few constraints:
 - The PopoverHintStack only ever contains hints.
 - Once the PopoverAutoStack contains a hint, all subsequent popovers
   in the stack must also be hints.
 - A popover=hint can never be the ancestor of a popover=auto.

The light dismiss behavior is roughly the same as before, with a
slight tweak that simplifies behavior: closing anything in the
PopoverAutoStack will always close everything in the PopoverHintStack.
That was not the case before, but it was a bit of a weird corner case.

Note that I found a crasher (happens in stable, with just auto
popovers) that I added a test for here. The bug for that is
crbug.com/1513282. I'll fix that in a followup.

[1] whatwg/html#9776 (comment)

Bug: 1416284,1513282
Change-Id: Ic064ecf1377bb8abfc812654c85016e6d1cbbdaf
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5133909
Reviewed-by: Joey Arhar <jarharchromium.org>
Commit-Queue: Mason Freed <masonfchromium.org>
Auto-Submit: Mason Freed <masonfchromium.org>
Cr-Commit-Position: refs/heads/main{#1246573}

--

wpt-commits: 51c87dc4c5d4a61caef22344e4dba6f5f233ffc3
wpt-pr: 43737

UltraBlame original commit: fcb792a0665afea5e736dd56c36dc1d59340362a
gecko-dev-updater pushed a commit to marco-c/gecko-dev-comments-removed that referenced this issue Jan 16, 2024
…stack of hints, a=testonly

Automatic update from web-platform-tests
Update popover=hint behavior to allow a stack of hints

The previous implementation only allowed one popover=hint to be open
at a time. Per conversation at [1], developers feel that it should be
possible to nest popover=hint popovers. This CL implements that
capability.

There are now two popover stacks in Document: PopoverAutoStack and
PopoverHintStack. Since it is possible to nest hints within autos,
the PopoverAutoStack can contain hints. However, there
are a few constraints:
 - The PopoverHintStack only ever contains hints.
 - Once the PopoverAutoStack contains a hint, all subsequent popovers
   in the stack must also be hints.
 - A popover=hint can never be the ancestor of a popover=auto.

The light dismiss behavior is roughly the same as before, with a
slight tweak that simplifies behavior: closing anything in the
PopoverAutoStack will always close everything in the PopoverHintStack.
That was not the case before, but it was a bit of a weird corner case.

Note that I found a crasher (happens in stable, with just auto
popovers) that I added a test for here. The bug for that is
crbug.com/1513282. I'll fix that in a followup.

[1] whatwg/html#9776 (comment)

Bug: 1416284,1513282
Change-Id: Ic064ecf1377bb8abfc812654c85016e6d1cbbdaf
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5133909
Reviewed-by: Joey Arhar <jarharchromium.org>
Commit-Queue: Mason Freed <masonfchromium.org>
Auto-Submit: Mason Freed <masonfchromium.org>
Cr-Commit-Position: refs/heads/main{#1246573}

--

wpt-commits: 51c87dc4c5d4a61caef22344e4dba6f5f233ffc3
wpt-pr: 43737

UltraBlame original commit: fcb792a0665afea5e736dd56c36dc1d59340362a
gecko-dev-updater pushed a commit to marco-c/gecko-dev-wordified that referenced this issue Jan 16, 2024
…stack of hints, a=testonly

Automatic update from web-platform-tests
Update popover=hint behavior to allow a stack of hints

The previous implementation only allowed one popover=hint to be open
at a time. Per conversation at [1], developers feel that it should be
possible to nest popover=hint popovers. This CL implements that
capability.

There are now two popover stacks in Document: PopoverAutoStack and
PopoverHintStack. Since it is possible to nest hints within autos,
the PopoverAutoStack can contain hints. However, there
are a few constraints:
 - The PopoverHintStack only ever contains hints.
 - Once the PopoverAutoStack contains a hint, all subsequent popovers
   in the stack must also be hints.
 - A popover=hint can never be the ancestor of a popover=auto.

The light dismiss behavior is roughly the same as before, with a
slight tweak that simplifies behavior: closing anything in the
PopoverAutoStack will always close everything in the PopoverHintStack.
That was not the case before, but it was a bit of a weird corner case.

Note that I found a crasher (happens in stable, with just auto
popovers) that I added a test for here. The bug for that is
crbug.com/1513282. I'll fix that in a followup.

[1] whatwg/html#9776 (comment)

Bug: 1416284,1513282
Change-Id: Ic064ecf1377bb8abfc812654c85016e6d1cbbdaf
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5133909
Reviewed-by: Joey Arhar <jarharchromium.org>
Commit-Queue: Mason Freed <masonfchromium.org>
Auto-Submit: Mason Freed <masonfchromium.org>
Cr-Commit-Position: refs/heads/main{#1246573}

--

wpt-commits: 51c87dc4c5d4a61caef22344e4dba6f5f233ffc3
wpt-pr: 43737

UltraBlame original commit: fcb792a0665afea5e736dd56c36dc1d59340362a
ErichDonGubler pushed a commit to erichdongubler-mozilla/firefox that referenced this issue Jan 19, 2024
…stack of hints, a=testonly

Automatic update from web-platform-tests
Update popover=hint behavior to allow a stack of hints

The previous implementation only allowed one popover=hint to be open
at a time. Per conversation at [1], developers feel that it should be
possible to nest popover=hint popovers. This CL implements that
capability.

There are now two popover stacks in Document: PopoverAutoStack and
PopoverHintStack. Since it is possible to nest hints within autos,
the PopoverAutoStack can contain hints. However, there
are a few constraints:
 - The PopoverHintStack only ever contains hints.
 - Once the PopoverAutoStack contains a hint, all subsequent popovers
   in the stack must also be hints.
 - A popover=hint can never be the ancestor of a popover=auto.

The light dismiss behavior is roughly the same as before, with a
slight tweak that simplifies behavior: closing anything in the
PopoverAutoStack will always close everything in the PopoverHintStack.
That was not the case before, but it was a bit of a weird corner case.

Note that I found a crasher (happens in stable, with just auto
popovers) that I added a test for here. The bug for that is
crbug.com/1513282. I'll fix that in a followup.

[1] whatwg/html#9776 (comment)

Bug: 1416284,1513282
Change-Id: Ic064ecf1377bb8abfc812654c85016e6d1cbbdaf
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5133909
Reviewed-by: Joey Arhar <jarhar@chromium.org>
Commit-Queue: Mason Freed <masonf@chromium.org>
Auto-Submit: Mason Freed <masonf@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1246573}

--

wpt-commits: 51c87dc4c5d4a61caef22344e4dba6f5f233ffc3
wpt-pr: 43737
@yisibl
Copy link

yisibl commented Jan 24, 2024

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
Copy link
Contributor

mfreed7 commented Jan 26, 2024

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
Copy link
Contributor Author

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

@annevk
Copy link
Member

annevk commented Feb 9, 2024

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
Copy link
Contributor

mfreed7 commented Feb 9, 2024

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
Copy link
Contributor

mfreed7 commented Feb 10, 2024

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 mfreed7 added the agenda+ To be discussed at a triage meeting label Feb 10, 2024
@mfreed7
Copy link
Contributor

mfreed7 commented Feb 22, 2024

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".

@past past removed the agenda+ To be discussed at a triage meeting label Feb 22, 2024
@chrishtr
Copy link
Contributor

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

marcoscaceres pushed a commit to web-platform-tests/wpt that referenced this issue Feb 23, 2024
The previous implementation only allowed one popover=hint to be open
at a time. Per conversation at [1], developers feel that it should be
possible to nest popover=hint popovers. This CL implements that
capability.

There are now two popover stacks in Document: PopoverAutoStack and
PopoverHintStack. Since it is possible to nest hints within autos,
the PopoverAutoStack can contain hints. However, there
are a few constraints:
 - The PopoverHintStack only ever contains hints.
 - Once the PopoverAutoStack contains a hint, all subsequent popovers
   in the stack must also be hints.
 - A popover=hint can never be the ancestor of a popover=auto.

The light dismiss behavior is roughly the same as before, with a
slight tweak that simplifies behavior: closing anything in the
PopoverAutoStack will always close everything in the PopoverHintStack.
That was not the case before, but it was a bit of a weird corner case.

Note that I found a crasher (happens in stable, with just auto
popovers) that I added a test for here. The bug for that is
crbug.com/1513282. I'll fix that in a followup.

[1] whatwg/html#9776 (comment)

Bug: 1416284,1513282
Change-Id: Ic064ecf1377bb8abfc812654c85016e6d1cbbdaf
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5133909
Reviewed-by: Joey Arhar <jarhar@chromium.org>
Commit-Queue: Mason Freed <masonf@chromium.org>
Auto-Submit: Mason Freed <masonf@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1246573}
@mfreed7
Copy link
Contributor

mfreed7 commented Apr 1, 2024

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
Copy link
Contributor

bkardell commented Apr 2, 2024

I still think hint is the right thing

@mfreed7
Copy link
Contributor

mfreed7 commented May 23, 2024

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
Copy link
Member

annevk commented May 24, 2024

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
topic: popover The popover attribute and friends
Development

Successfully merging a pull request may close this issue.

12 participants