[popup] More crisply define the interactions between popup=popup, popup=hint, and popup=async

[mfreed7]

The explainer has a section dedicated to the behaviors of each of these popup types, but there are some gaps:

1. Should "nested" popup=hint (tooltips) be allowed, in the same way that popup=popup is allowed to nest? It seems like tooltips and other popup=hint UI should really be constrained to be exactly "one at a time", with nested tooltips prohibited. But are there use cases for tooltips nested within tooltips?
2. Should popup=popup be allowed to "nest" inside tooltips? Again here, it seems like the answer should be no, but perhaps there are use cases?
3. When a tooltip is shown while there are open popups, and then the topmost popup is hidden (either with light dismiss or via hidePopup()), should the tooltip be hidden also? It seems like "yes", but what do UI folks think?
4. How should initiallyopen (maybe renamed to defaultopen soon) behave when there are all three popup types. It would seem that only the first occurence of either <div popup=popup initiallyopen> or <div popup=hint initiallyopen> should be shown upon page load. It would also seem that an unlimited number of <div popup=async initiallyopen> should be auto-shown on load, independent of popup=popup or popup=hint.

I have a CL up to implement my best guesses at the above questions, so perhaps an easy way to get answers is for folks to wait for that to land in a Chromium Canary and test it out. But thoughts appreciated.

[scottaohara]

1. nested tooltips shouldn't be allowed. Generally if someone is in a position where they might need something like that, then it's very likely that the initial tooltip popup should be a different type of popup, so that a user can directly enter/interact with the content (and thus be able to invoke the second tooltip popup).
2. again no, because a tooltip should not be receiving focus / contain any interactive elements. if someone has a need for their popup to receive focus / contain sub-popups, then they should use the default popup behavior.
3. from what i gather here i also think yes? but maybe it'll be more clear once i see a demo of the use case?
4. Agreed on async. Agreed that only the first instance of popup=popup should be respected. Seriously wondering if a hint should even be allowed to be open by default?

Since a hint/tooltip would otherwise only be revealed on hover/focus of the element it describes, and auto-dismiss when someone hovered or moved focus away from the invoking element, wouldn't having it open by default result in an immediate closure once someone starting moving keyboard focus or moving their mouse? What if an element was set to have its tooltip opened by default, but it wasn't the first element on the page that had an associated tooltip popup. Someone navigating the page sequentially with keyboard would come to that other element first, its tooltip popup would be invoked, and then would that not close the initially opened tooltip popup? (yes the same would happen for a standard popup - but only if the user specifically invoked another element's popup, rather than passively invoking a hint popup merely by hover/focus). If others don't agree and think there's a use case for a hint to be exposed by default, I'd really like to hear those use cases. I'm just stuck on the awkwardness of it / how the behavior of its displaying (auto-dismiss on mouseout) would change compared to other initially opened popups.

[mfreed7]

@scottaohara thanks for the very helpful input!

4. Agreed on async. Agreed that only the first instance of popup=popup should be respected. Seriously wondering if a hint should even be allowed to be open by default?

Since a hint/tooltip would otherwise only be revealed on hover/focus of the element it describes, and auto-dismiss when someone hovered or moved focus away from the invoking element, wouldn't having it open by default result in an immediate closure once someone starting moving keyboard focus or moving their mouse?

This is a great point, and I think I agree with you. Perhaps only <div popup=popup> and <div popup=async> should be allowed to use defaultopen (renamed from initiallyopen). This also raises other points about how popup=hint works, and I've opened #526 to discuss that further.

[css-meeting-bot]

The Open UI Community Group just discussed [popup] More crisply define the interactions between popup=popup, popup=hint, and popup=async.

The full IRC log of that discussion

<gregwhitworth> Topic: [popup] More crisply define the interactions between popup=popup, popup=hint, and popup=async
<gregwhitworth> github: https://github.com//issues/525
<bkardell_> masonf: this one is a bit involved.. there are 3 types of popup.
<bkardell_> masonf: there are 4 things... let me lay them out
<bkardell_> masonf: 1) I think there is concensus that we should outlaw nested hints
<bkardell_> 2) I think also no popups inside a tooltip
<bkardell_> 3) if you showpop with a tooltip and then you hide the popup, the tooltip should go
<flackr> q+
<scotto_> q+
<bkardell_> 4) defaultopen will cause it to be automatically open, but it should also work on async (toast) with N defaultopen
<gregwhitworth> ack flackr
<bkardell_> flackr: Is there a usecase for defaultopen tooltip that helps someone understand what to do first. It feels 'tooltip like', reasonable
<bkardell_> masonf: the diff between a popup and a tooltip is about lightdimiss - in that case don't you probably want it to be a popup and then that is fine
<gregwhitworth> ack scotto_
<bkardell_> flackr: correct
<bkardell_> scotto_: I agree that is a popup, it's not likely going to be the description associated always with that form control, probably
<bkardell_> scotto_: I've already said i think it is _probably_ ok to have N for async/toast - but again I would like to stress that we are very much circling around a lot of questions about what is a toast and how should it work altogether. There are a lot of questions that need to be answered, if you think about live regions, for example...
<Travis> (Notification API ref: https://github.com/WICG/aom/blob/gh-pages/notification-api.md)
<gregwhitworth> q?
<bkardell_> scotto_: this is going to be directly tied into moving forward with the notification api proposal. I don't want to get into all of that right now, but I do want to just say "we keep edging up to this, but we aren't having that conversation"
<bkardell_> masonf: I am worried about those as well, but that question is relevant either way about can we show N. I think in terms of this issue can we not decide?
<bkardell_> scotto_: I don't want to stop anything that can be open later, but yeah, we need to talk about other bits or at least think about author guidance about how to not make it actively bad
<masonf> Proposed resolution: We should adopt this behavior: a) outlaw "nested" `popup=hint`, b) outlaw "nesting" `popup=popup` inside `popup=hint`, c) if you show `popup=popup`, then show `popup=hint`, then hide the `popup=popup`, the `popup=hint` should be hidden, d) using `defaultopen` on `popup=hint` should have no effect, and e) *all* `popup=async` elements with `defaultopen` should be shown on page load.
<scotto_> i think that makes sense
<bkardell_> q+
<gregwhitworth> ack bkardell_
<flackr> q+
<gregwhitworth> bkardell_: what does it mean to outlaw?
<gregwhitworth> bkardell_: it'll still be there, but it'll throw or something?
<gregwhitworth> masonf: it will make them hidden or not
<gregwhitworth> bkardell_: is it possible to rephrase it so that outlaw means something?
<masonf> Proposed resolution: We should adopt this behavior: a) outlaw "nested" `popup=hint`, b) outlaw "nesting" `popup=popup` inside `popup=hint`, c) if you show `popup=popup`, then show `popup=hint`, then hide the `popup=popup`, the `popup=hint` should be hidden, d) using `defaultopen` on `popup=hint` should have no effect, and e) *all* `popup=async` elements with `defaultopen` should be shown on page load. Here, "outlaw" means a second popup closes th[CUT]
<gregwhitworth> bkardell_: you're talking about nested
<gregwhitworth> bkardell_: the outer one appears in the outer layer?
<gregwhitworth> masonf: popups have this complicated rules of what ancestor popup means, it doesn't have to be a direct parent (eg: anchor element)
<gregwhitworth> masonf: that's what I'm talking about here
<gregwhitworth> bkardell_: I have no intention to blocking this
<gregwhitworth> bkardell_: but I can't add a +1 to this
<gregwhitworth> masonf: how about this
<gregwhitworth> masonf: there seems to be general agreement, how about we get a crisp response and then we can resolve on next week
<gregwhitworth> flackr: I would like to +1 to having more clarity
<masonf> Proposed resolution: we agree in spirit with this comment: https://github.com//issues/491#issuecomment-1113607241.
<bkardell_> flackr: I was going to ask about point c
<bkardell_> flackr: is the hint outside. of the popup?
<bkardell_> masonf: the definition of hint is that it doesn't close existing popups - the popup stack stays open, that's really the difference between popup and hint
<bkardell_> flackr: then I think I don't agree with c because it seems like... (missed it)
<bkardell_> masonf: it kind of fell out of the implementation - I would love some dev feedback on this, both seem to have interesting challenges
<bkardell_> masonf: it's kind of not always clear
<bkardell_> masonf: (talks himself into agreeing with flackr)?
<bkardell_> scotto_: I have a calendar widget that pops up
<bkardell_> s/scotto_ /masonf
<bkardell_> masonf: if you hover something on the calendar popup ..
<bkardell_> bkardell_: apologies, scribe is lost
<bkardell_> masonf: I guess I need to go back and get details on these two things
<bkardell_> gregwhitworth: yeah, it seems like 'generally' we are in agreement, and we have some things to tweak
<gregwhitworth> Zakim, end meeting
<Zakim> As of this point the attendees have been masonf, JonathanNeal, dandclark, miriam, scotto_, gregwhitworth, Travis, una, bkardell_, flackr
<Zakim> RRSAgent, please draft minutes
<RRSAgent> I have made the request to generate https://www.w3.org/2022/05/05-openui-minutes.html Zakim
<Zakim> I am happy to have been of service, gregwhitworth; please remember to excuse RRSAgent. Goodbye

[mfreed7]

Ok, so in the meeting today, I took an action item to more-crisply define the proposed behavior. This comment is that definition.

---

First, some terminology:

• I'll use "default popup" to mean an element with popup=popup (or its replacement value).
• I'll use the word "tooltip" to mean an element with popup=hint.
• I'll use the word "toast" to mean an element with popup=async.
• I'll use the word "popup" to mean a default popup, a tooltip, or a toast.
• I'll use "triggering element" to mean a supported activatable element (e.g. a button) containing one of these content attributes: togglepopup, showpopup, or hidepopup, and "target" to mean the popup with id matching the value of the triggering attribute.
• I'll use the verb "show" to mean either calling .showPopup() on a popup, or showing the popup via activating a triggering element.
• I'll use the word "open" to mean a popup that has been shown.
• For a given open popup (call it P), an "ancestral" popup is another open popup (call it A) where any of the following is true:
  1. A is a DOM ancestor of P.
  2. P has an anchor attribute whose value is equal to A's id or any descendent of A's id.*
  3. A has a descendent triggering element whose target is P.

* See this issue for a discussion generally about whether anchor should form an ancestral relationship.

Ok. Now, the proposed behavior:

1. If a tooltip is shown, it should hide any other open tooltips, including ancestral tooltips. ("You can't nest tooltips".)
2. If a default popup is shown, it should hide any open tooltips, including if the tooltip is an ancestral popup of the default popup. ("You can't nest a popup inside a tooltip".)
3. If you: a) show a default popup (call it D), then b) show an ancestral tooltip of D (call it T) , then c) hide D, the tooltip T should be hidden. ("A tooltip can be nested inside a popup.")
4. If you: a) show a default popup (call it D), then b) show an non-ancestral tooltip (call it T) , then c) hide D, the tooltip T should be left showing. ("Non-nested tooltips can stay open when unrelated popups are hidden.")
5. The defaultopen attribute should have no effect on tooltips. I.e. this attribute cannot be used to cause a tooltip to be shown upon page load.
6. The defaultopen attribute can be used on as many toasts as desired, and all of them will be shown upon page load.
7. Only the first default popup (in DOM order) containing the defaultopen attribute will be shown upon page load. (This is per-explainer, and included here for completeness.)

---

Clearly I need to fold a lot of this into the explainer, which needs work. But are there thoughts about the above? Objections?

[scottaohara]

there may need to be an exception for tooltips to always be on top.

thinking a menu popup which has a menuitem that both invokes a tooltip/submenu, where the submenu could be positioned atop the tooltip and then the descriptive information would be obscured

[css-meeting-bot]

The Open UI Community Group just discussed [popup] More crisply define the interactions between popup=popup, popup=hint, and popup=async, and agreed to the following:

• RESOLVED: we agree with the proposed rules https://github.com/openui/open-ui/issues/525#issuecomment-1119093412

The full IRC log of that discussion

<gregwhitworth> Topic: [popup] More crisply define the interactions between popup=popup, popup=hint, and popup=async
<gregwhitworth> github: https://github.com//issues/525
<gregwhitworth> q?
<hdv> masonf: 525 is kind of a complicated issue about the rules we use for light dismiss
<hdv> masonf: that we talked about last time
<hdv> masonf: resolution from last time was for me to write out more clearly
<hdv> masonf: in summary it was: popup=hint is a tooltip, popup=async is a toast; the summary is you can't next tooltips, you can't nest a popup inside of a tooltip, non nested tooltips can stay open when unrelated popups are hidden
<hdv> masonf: so if you have a popup on one side of the page and a tooltip shows up, if that popup closes the tooltip stays open
<hdv> masonf: the other is about defaultopen, which causes a popup to show on pageload. Won't happen for popup=hint/tooltips, but for popup=async/toasts they will
<BoCupp> q?
<masonf> Proposed resolution: we agree with the proposed rules https://github.com//issues/525#issuecomment-1119093412
<scotto_> q+
<BoCupp> q+
<gregwhitworth> ack scotto_
<hdv> scotto_: does there need to be a rule about an async inside of an async?
<hdv> masonf: interesting question… asyncs right now don't close anything else when they open, and they don't light dismiss on their own
<hdv> masonf: so the closest thing to a non modal dialog that we have
<hdv> masonf: I don't see an issue with nesting them, because if you open that second one it wouldn't close anything else
<hdv> scotto_: I don't have anything where that would be a problem at the moment I think… aside from the possibility of timeouts
<hdv> scotto_: so say… if the first async has a timeout of 8 seconds and every one inside of that has timeouts of 4 seconds…
<hdv> scotto_: that's the only thing I can think of where that would be a bit awkward
<hdv> masonf: there is no functionality where we would close via some kind of timeout so this would exist in developer land
<hdv> masonf: I do agree that would be a problem but would treat it as a developer's bug
<gregwhitworth> ack BoCupp
<hdv> BoCupp: I agree with the rules as you have them written… wanted to ask are interaction rules specified for the layering of these different types of popups? last is topmost but not sure if that applies with hint and toast cases?
<hdv> masonf: great question… my plan would be to use the existing toplayer rules, which is last = top.
<hdv> masonf: we could probably flush that out more in the explainer, good point
<hdv> BoCupp: what did you say about tooltips and open popups, even if they're not nested, they don't dismiss?
<hdv> masonf: yes if you open a tooltip it does not close a popup
<hdv> masonf: once that's the case, the tooltip stays up
<gregwhitworth> q?
<hdv> masonf: that last point was actually a change from the last meeting we had
<masonf> Proposed resolution: we agree with the proposed rules https://github.com//issues/525#issuecomment-1119093412
<dandclark> +1
<hdv> +1
<JonathanNeal> +1 to the rules. Also want to note I appreciate Scott’s comments about async popups.
<hdv> RESOLVED: we agree with the proposed rules https://github.com//issues/525#issuecomment-1119093412
<scotto_> i just added comment to the issue, but pending that, agree

[mfreed7]

there may need to be an exception for tooltips to always be on top.

thinking a menu popup which has a menuitem that both invokes a tooltip/submenu, where the submenu could be positioned atop the tooltip and then the descriptive information would be obscured

@scottaohara So at first I thought this was a good idea. But on reflection, I think it might not matter. Given the resolution to adopt these rules, there can only be one popup=hint displayed on a page at a time, and it must be the last-opened popup on the page. I.e. if you have a popup=popup displayed, and then you display a popup=hint, it'll be topmost. If you then open another popup=popup, that will close thepopup=hint. So I don't think we need a special exception to make sure tooltips are on top, I think that's the only place they can be within the rules. But maybe I missed a way for this to happen?

[mfreed7]

Based on the resolution, I'm going to close this issue.

[scottaohara]

@mfreed7, makes sense. if an unwanted situation actually comes up in reality, we can always discuss then

[mfreed7]

@mfreed7, makes sense. if an unwanted situation actually comes up in reality, we can always discuss then

Awesome, thanks!