[popup] "Interest"-based triggering for popovers

[mfreed7]

The explainer currently says this about the behavior for popup=hint (which I'll call "tooltips" for clarity):

Hint/Tooltip (popup=hint)

• When opened, force-closes only other hints, but leaves all other popup types open.
• Dismisses on close signal, click outside, when no longer hovered (after a timeout), or when the anchor element loses focus.

For the light dismiss triggers, everything except when no longer hovered is well defined. However, since we haven't discussed a declarative way to trigger tooltips, it isn't clear how "no longer hovered" should be defined. And even if there was a declarative trigger, what happens for tooltips that are programmatically triggered via tooltip.showPopup()? In order to answer questions about light dismiss for tooltips, I think we need to figure out how declarative invocation works.

Here's a quick strawman off-the-cuff idea:

<img src=questionmark.png hoverhint=foo>
<div popup=hint id=foo>Tooltip</div>
<style>
img {
  hint-trigger-delay=500ms;
}
[popup=hint] {
  hint-hide-delay=1000ms;
}
</style>

In other words, there is a new content attribute, hoverhint, which points to an element with popup=hint. When the <img> element (in this example, but could be any element type) is hovered, after a delay set by the hint-trigger-delay CSS property, the tooltip is shown. When that tooltip (or the triggering <img> element) has no longer been hovered for a time set by hint-hide-delay, it is hidden.

Again, this is a total strawman proposal. Suggestions appreciated.

[scottaohara]

i think i'd just expect a :hover and :focus for the selector to tie it to those actions. As otherwise i'd read that as expecting it to show by default after the 500ms delay.

e.g.,

*:hover,
*:focus {
  hint-trigger-delay=500ms;
}

What I don't readily have answer for is how non-interactive elements will allow users who aren't using a mouse to access their tooltips (e.g., your image example) or how these tooltips will be accessible on touch screens.

What might be useful is if caret navigation had it's own pseudo-class similar to :hover, or tapped into:hover, as that could be a means to trigger a hint on an otherwise non-focusable element.

I only have partial thoughts on what could be done for touch screen access.... I'll have to think more on that / we probably want to bring this up to a larger group to say "hey, we're talking about tooltips.... they've been horribly accessible on non-interactive elements for the last 24+ years... how we going to fix that?"

[mfreed7]

*:hover,
*:focus {
  hint-trigger-delay=500ms;
}

So I think that would be fine, since the hint-trigger-delay represents the time that the user needs to hover or focus the element before it triggers the tooltip. So it'll only matter if/when the element is hovered/focused. Having said that, it also shouldn't matter if it was selected like * {hint-trigger-delay=500ms} because it'll have no effect when the element isn't hovered/focused. Perhaps your point was just that we need to make sure to include focus, and I totally agree with that.

What I don't readily have answer for is how non-interactive elements will allow users who aren't using a mouse to access their tooltips (e.g., your image example) or how these tooltips will be accessible on touch screens.

Totally agree with this. Suggestions appreciated.

[css-meeting-bot]

The Open UI Community Group just discussed [popup] Triggering and light dismiss for popup=hint.

The full IRC log of that discussion

<gregwhitworth> Topic: [popup] Triggering and light dismiss for popup=hint
<gregwhitworth> github: https://github.com//issues/526
<hdv> masonf: this one is about triggering light dismiss for popup=hint (tooltips). This came up when I was working on the previous issue… it became clear that light dismiss is identical between popup and tooltip, for tooltips they also light dismiss when you stop hovering the tooltip… that makes sense but we don't have a way to trigger a tooltip with a hover
<hdv> masonf: should there be a way to declaratively say you want a tooltip to work on hover?
<hdv> q+
<hdv> masonf: and also how long should you wait when you stop hovering?
<JonathanNeal> q+
<hdv> masonf: the proposal I put was an attribute that you point to an ID, hopefully one that has popup=hint, and two CSS properties: one for the triggering element and one the tooltip itself
<hdv> the first 'hint trigger delay' property with a time, for the triggering element, and then one for the tooltip itself 'hint hide delay' that you can set on the tooltip
<Alexander_Futekov> q+
<flackr> q+
<gregwhitworth> hdv: I was going to ask if people do the hovering this with via keyboard?
<gregwhitworth> ack hdv
<scotto_> q+
<hdv> masonf: not sure what the correct way would be to do that
<gregwhitworth> ack JonathanNeal
<hdv> JonathanNeal: what would you think of it using an internal animation or transition with a delay that was like a UA transition or animation that could be overwritten?
<hdv> JonathanNeal: should this action wait for an animation to end if the user would want to make the popup 'pop' ?
<hdv> masonf: right now my thinking was that we would not… but would be fairly easy to do… animating the close is a bit more difficult
<hdv> [ +1 for UA default animation/transition! ]
<hdv> flackr: there is some precedent for this
<hdv> flackr: one way we could support leave animation is by waiting for the modification that actually hides the element
<gregwhitworth> ack Alexander_Futekov
<hdv> Alexander_Futekov: my comment would be almost the same as what JonathanNeal said… we already have element with UA styles and we have animation properties, why not use them?
<hdv> Alexander_Futekov: seems like something we can reuse without issues?
<hdv> masonf: do you mean existing CSS props could do the things I proposed those two properties for?
<hdv> Alexander_Futekov: we have transition delay and duration… I think they might work?
<bkardell_> q+
<hdv> flackr: if you do this naievely and there is both a opendelay and closedelay, then if you hover of the element than you will see it open and close at delay time… it could work for the hide direction but I'm not convinced it could work for the show direction
<hdv> Alexander_Futekov: in CSS we can already declare a different delay for mouseout and hover
<bkardell_> q-
<hdv> masonf: the difference is probably… you would want to cancel in some cass
<hdv> s/cass/cases
<gregwhitworth> ack flackr
<hdv> flackr: how does this tie into the ARIA properties? serves a similar purpose to things like title or alt textst… how do we see this work as content for screenreaders?
<hdv> masonf: there is an open issue where there are some comments on it, I don't have it handy but that exact thing is discussed there with some proposals
<gregwhitworth> q+
<gregwhitworth> ack scotto_
<hdv> scotto_: I can comment on hdv's comment and the last one too
<hdv> scotto_: tooltip hint would generally have an aria-describedby relation with the element that invokes it, that would be the relationship there
<masonf> Here's the issue, and specifically the comment Scott is currently describing: https://github.com//issues/329#issuecomment-1117304746
<hdv> scotto_: there is a role of tooltip that could be used for the resulting popup elements… that role is kind of useless right now, because all the magic happens with aria-describedby, but the role tooltip doesn't really do anything now… the contents of the hint are passed as a texts string to the screenreader, so focus never leaves the element that invokes the tooltip
<hdv> scotto_: per Hidde's question… it;'s been 24… 26 years since the title attribute been introduced… never been keyboard accessible except for some exceptions… I don't know… would be great if focus on focusable elements shows the hint popup
<hdv> scotto_: but how do we handle that for hover? I think that that's something that needs a discussion beyond this group. Could see it go in a bunch of different directions, wouldn't want to assume that everything that has a tooltip should become focusable, could get messy with many tooltips
<hdv> scotto_: there is also caret browsing… but doesn't solve for touch screens… maybe there is some platform setting, where you can indicate you don't have a mouse… if not figured out, we're just maintaining what the status quo is but we're letting people style the tooltip
<hdv> flackr: question about the first point… aria-describedby says the element is decribed by some element, could it have multiple, would that be reasonable?
<hdv> scotto_: I would assume that if an element was pointing to a tooltip, it was there for a reason… I would say it would describe all of them… arguably that could happen… at the same I would really want to see that UI
<hdv> flackr: it could be that you have multiple name fields, but it would point to the saem description
<hdv> scotto_: reminds me of another thing I can see hints being useed for… error messages
<bkardell_> I was thinkign about this too ^
<hdv> flackr: in some contexts the message in the tooltip might be changed dynamically but you would probably not be using the hint attribute
<hdv> scotto_: there could be a usecase for that… I know Chromium does that now, they listen to the description when it changes it would get announced, almost like a live region
<bkardell_> I removed myself but I was kind of in the queue for basically that
<hdv> scotto_: that would be great to have it fully work
<hdv> flackr: that would be an argument to set describedby when we show the tooltip… -
<hdv> scotto_: if someone uses JAWS or NVDA with virtual cursor,you'd still want that infomation associated, because user woouldn't trigger a focus or hover, they would still need that information available
<hdv> flackr: if the tooltip isn't visible would we have the content accessible in a11y tree?
<hdv> scotto_: yes
<hdv> flackr: even display none'ed content?
<gregwhitworth> q?
<hdv> scotto_: yes
<hdv> gregwhitworth: seems there needs to be an entire side discussion on this… do you want to spin up an issue for solving this, scotto_ ?
<hdv> scotto_: the general problem I was talking about… hints, how do we even hover?
<hdv> scotto_: sure can create issue
<hdv> gregwhitworth: masonf, you were referencing how you were going to make it very similar… is there reason to have duplicates?
<bkardell_> q+
<hdv> masonf: great point… I don't think there's any reason… the fact that the target popup is a hint should be enough for it to trigger hover behavior… sounds good actually
<gregwhitworth> ack gregwhitworth
<bkardell_> q-
<hdv> gregwhitworth: as a dev I would personally prefer to have just one
<flackr> +1
<hdv> masonf: I would assume that all three of them should keep working in the same way
<hdv> gregwhitworth: when we're talking about hint but name them other things to know what they are… that's probably a bad thing
<hdv> bkardell_: I also agree with Greg's point… I catch up to this 1-2 times a week and occassionally have to think about what the properties were
<masonf> q+
<hdv> bkardell_: can't remember if this is part of the goals or non goals
<hdv> bkardell_: one of the most common things I see people try to do with async… when you land on a form field and they give you a “hint”
<hdv> bkardell_: in that case, I have seen pages that land you on a form and set your focus on the first form field… I can see that naturally setting wanting to open that by default
<hdv> bkardell_: I feel like I'm lost in the terminology and where we stand on things to comment on whether it is right or wrong… but are we thinking those kinds of interactions would be helped by this?
<hdv> masonf: not sure if I understand the last part of your qeustion… 
<hdv> bkardell_: did I mindtrick myself that this would work for those kinds of cases?
<hdv> masonf: I get your disconnect… terminilogy is hard… we call them two things, popups and tooltips. Popup is popup=poup, tooltip is popup=hint. We have showpopup, hidepopup for things that look like a button, when you click them, a popup shows uo. What we talk about here is tooltips
<hdv> masonf: what we're talking here is hovering
<hdv> bkardell_: when you land on a form field and they give you contextual help… that seems like a hint, but it shows on focus… are we even talking about that?
<JonathanNeal> “Hmph. Don’t call things ‘toast’,” I spoke to myself. “... and don’t call things ‘click’, either.” I announced at a near hush to myself, with my arms folded, and shadows of rain from the window glass drifting down my face.
<hdv> masonf: that's kind of what I hope we'll get to in the issue scott will hopefully open
<bkardell_> popup="cookedbread"
<hdv> masonf: tooltip I can see using popup=tooltip… popup=toast is not what I wanted to get into
<gregwhitworth> q?
<gregwhitworth> ack masonf
<hdv> masonf: I'm happy ot open bikeshed issues
<hdv> s/ot/to
<hdv> gregwhitworth: was there anything else you wanted to get resolution on masonf ?
<hdv> masonf: hopefully folks will go back to the issues and comment
<hdv> masonf: hopefully the IDL attributes will tell you what the status of things is so that you can feature detect
<hdv> masonf: I'm thinking that maybe in the first version we'll ship this with popup=popup and not the others
<hdv> masonf: thanks I got all the feedback I wanted
<gregwhitworth> Zakim, end meeting
<Zakim> As of this point the attendees have been gregwhitworth, JonathanNeal, dandclark, flackr, scotto_, dbaron, hdv, masonf, bkardell_
<Zakim> RRSAgent, please draft minutes
<RRSAgent> I have made the request to generate https://www.w3.org/2022/05/12-openui-minutes.html Zakim
<Zakim> I am happy to have been of service, gregwhitworth; please remember to excuse RRSAgent. Goodbye
<gregwhitworth> RRSAgent, you may leave
<RRSAgent> I'm logging. I don't understand 'you may leave', gregwhitworth. Try /msg RRSAgent help
<gregwhitworth> RRSAgent, please leave
<RRSAgent> I see no action items

[mfreed7]

Great discussion yesterday, with several good comments. One important one, which we didn't resolve on, but sounded like it had general agreement was:

• Instead of a new attribute (hoverhint), let's just re-use togglepopup, showpopup, and hidepopup.

I like the idea of re-using the existing attributes. There are a few questions we'd have to answer:

• When applied to non-button-like elements, that should only work when the target popup is a popup=hint. What happens otherwise, nothing?
• What is the meaning of hidepopup=foo when foo is a popup=hint? Does it immediately hide the popup if it's showing, rather than waiting for the delay to expire? I'm not sure what the use case is.
• What exactly does togglepopup=foo mean also? Hover it once and the tooltip shows, hover it again and it goes away? Feels odd.
• Given the above two, maybe only showpopup makes sense?

---

There was also some discussion of a11y mappings for popup=hint. Let's discuss that on #329.

There was some discussion of keyboard support for triggering popup=hint, and @scottaohara nicely opened an issue to discuss that: #530.

Another point was made about naming: hint and async are confusing because they have to be mentally mapped to "tooltip" and "toast/notification/something". Perhaps we should pick better names. I've opened #532 to discuss that.

[aleventhal]

Is it settled that hint popups will be triggered on focus?

[css-meeting-bot]

The Open UI Community Group just discussed https://github.com/openui/open-ui/issues/546, and agreed to the following:

• RESOLVED: Rename the IDL attribute from 'popup' to 'popUp'. Also change documentation to use the phrase "pop-up" rather than "popup".

The full IRC log of that discussion

<dandclark> topic: https://github.com//issues/546
<dandclark> Github: https://github.com//issues/546
<rodydavis> q-
<dandclark> masonf: 546 is about popup. popup isn't web compatible. There is a content attr and an equivalent idl (js) attr.
<dandclark> masonf: there are sites that use myObject.popup. When we added the behavior that it only returns valid values, this breaks sites.
<dandclark> masonf: Domenic laid out several options. Do nothing, rename both content and idl attrs, and (the one masonf prefers) use different names.
<dandclark> masonf: Give the IDL attr a different name.
<JonathanNeal> q+
<dandclark> masonf: This may cause misunderstandings but can be done. There's also a hacky alternative [missed details]. Doesn't seem to be precedent.
<una> q+
<dandclark> masonf: Focus on options of either renaming both, or renaming IDL attr only.
<JonathanNeal> <div popgate>
<dandclark> masonf: Other idea is use capitalization. Change IDL attr to popUp. Keep contetn attr the same. Describe in docs as "pop up" feature.
<chrisdholt> q+
<dandclark> JonathanNeal: Did we discuss popup=popup?
<dandclark> masonf: We resolved to switch it to popup=auto.
<JonathanNeal> ack JonathanNeal
<dandclark> JonathanNeal: Was hoping that was resolved, so renaming the attr name wouldn't create an a=a problem. Auto would still work in this case.
<dandclark> masonf: If we decide to rename both, that's pretty clear
<masonf> darn web name-squatters...
<dandclark> una: I like the idea of popUp with capital U. If that resolves the issues it seems like the most seamless approach. I thought it was clever, +1'd in the thread
<JonathanNeal> Would `popUp` break tools like Preact?
<JonathanNeal> ack una
<JonathanNeal> ack chrisdholt
<JonathanNeal> q+
<dandclark> chrisdholt: I agree it's clever and it's good to keep popup. BUt capitalization could be unintuitive. Documentation could become hyper-important. That's the only concern I have with doign the capitaliation bit.
<dandclark> masonf: It can be confusing but there are precedents. Calling it "pop up" (2 words) makes this exactly the right thing to do.
<dandclark> masonf: [lists precedent examples]
<dbaron> masonf: ... maxLength ...
<dandclark> JonathanNeal: Is popup the property or attr that has the capital letter? And does this have impact on tools that assume no casing difference?
<dandclark> masonf: we're taking about JS prop, not content attr.
<JonathanNeal> ack JonathanNeal
<tantek> HTML attributes names are case-insensitive AFAIK, though lowercase usage by convention
<dandclark> masonf: 2nd q, generally there are concerns. Looked at react. They have extensive translation key. It's my opinion that this should be transparent. When prop is standardized they will add it. Should work the same in preact.
<JonathanNeal> q?
<masonf> Proposed resolution: Rename the IDL attribute from 'popup' to 'popUp'. Also change documentation to use the phrase "pop up" rather than "popup".
<JonathanNeal> +1
<chrisdholt> q-+1
<chrisdholt> +1
<dandclark> una: When you say change the docs to use pop up with a space, where would that change?
<dandclark> masonf: Everywhere.
<tantek> +1 this seems like a reasonably way forward (both aspects together)
<dandclark> masonf: Now we just have explainers. Look for everywhere it's used in a sentence.
<tantek> prose vs code
<dandclark> una: why not use dash?
<dandclark> masonf: I'm ok with that too.
<masonf> Proposed resolution: Rename the IDL attribute from 'popup' to 'popUp'. Also change documentation to use the phrase "pop-up" rather than "popup".
<tantek> +1 to dash per una suggestion
<chrisdholt> I prefer Una's as well, so +1
<dandclark> una: verbiage feels more like an action than a noun.
<JonathanNeal> q?
<dandclark> JonathanNeal: If this is for property, that would be less friendly to JS.
<dandclark> masonf: Just taking about docs regarding the dash.
<JonathanNeal> +1 to una’s suggestion
<dbaron> I agree with Una as well. (Not sure if I was audible.) There's definitely a clear distinction between the nouns and verbs for this type of thing.
<chrisdholt> Yes, so documentation would be, "The new pop-up attribute in html is popup and in JS is popUP"
<chrisdholt> lowercase p...
<dandclark> una: Does this add confusion to attribute?
<dandclark> masonf: Domenic also commented on this. On the spec, image sizes is a property. Used in text it's image-sizes.
<tantek> <prose>pop-up</prose>, <code>popup</code> HTML attribute, <code>popUp</code> property/IDL
<dandclark> masonf: If you try it in JS you'll get an exception immediately.
<JonathanNeal> q?
<dandclark> una: And you won't get the desired behavior.
<dandclark> una: Let's do it, +1
<dandclark> masonf: Regardless of if we'll resolve, I'll change it.
<masonf> RESOLVED: Rename the IDL attribute from 'popup' to 'popUp'. Also change documentation to use the phrase "pop-up" rather than "popup".
<dandclark> [agenda shuffling]
<dandclark> github: https://github.com//issues/526

[css-meeting-bot]

The Open UI Community Group just discussed https://github.com/openui/open-ui/issues/526, and agreed to the following:

• RESOLVED: use a new/different name for declarative hover-triggering of popups. Don't re-use togglepopup, showpopup, hidepopup.

The full IRC log of that discussion

<JonathanNeal> topic: https://github.com//issues/526
<JonathanNeal> github: https://github.com//issues/526
<JonathanNeal> +1 to tantek’s suggestion
<dandclark> masonf: We talked about this a few weeks ago. This is the question about declarative triggering for hint popups.
<dandclark> masonf: Idea is you can put hint on any element. When you hover it, should trigger a hint. Like tooltip. Hover and it will show you tooltip about that thing.
<dandclark> masonf: Initial proposal was to use differerent declarative name. Discussed maybe it would be better to reuse showpopup, togglepopup.
<dandclark> masonf: My concern is there are use cases where that wouldn't work. Have button, want it to trigger popup, but also want a tooltip on that same element.
<dandclark> masonf: Wouldn't be possible if you combine them.
<dandclark> masonf: Also, what does hidepopup mean? Similarly togglepopup. For hints, doesn't make sense to hover the element, tooltip shows up, hover again, and it goes away. Triggering only goes in 1 direction.
<una> q+
<scotto_> q+
<dandclark> masonf: So there's general confusion I have and I wonder if we should revisit the earlier decision.
<JonathanNeal> q?
<JonathanNeal> ack una
<dandclark> una: You said it doesn't make sense to have hover toggle the tooltip. But we do want an action to hide the tooltip. Otherwise we don't be able to do things like animate tooltip out.
<dandclark> una: it's tricky but with tooltip I want to make sure it's not just an open action, and we also have close event that gets triggered.
<dandclark> masonf: Hint popup is still popup, has other popup behaviors includign show/hide events. And animation behaviors. So can animate based on :top-layer.
<dandclark> masonf: There is proposed behavior for how it goes away, modeled on tooltips. After CSS configrable delay after user mouses out, can go away. Can animate that.
<dandclark> una: There is use case you can create with this change
<dandclark> masonf: If we do all the things in this proposal and add another attriubte, can do all the things asked for.
<JonathanNeal> q?
<dandclark> scotto_: Even in demos I was making for sub navigation popup, trying to have that show up on hover, I found I had to reach for JS events to show/hide. Seems that having additional attr to help with showing hints on hover and focus would be beneficial to people who want to have popup subnavigation
<dandclark> scotto_: Hover it with mouse but want behavior to happen only on keyboard events.
<dandclark> scotto_: Could do that with JS, but do we want to make it available to people without JS
<dandclark> masonf: Tricky to do in JS. Handling of open/closed state.
<dandclark> masonf: Suggestion is to make this behavior is to make this work for non hint popups too?
<dandclark> scotto_: yes. There is use case for popup navigation. I don't necessarily like this pattern but it exists. People should be able to do this easily rather than futz with it in JS.
<JonathanNeal> q?
<JonathanNeal> ack scotto_
<dandclark> masonf: In your demo, you hover over something, menu shows up. Goes away when de-hovered?
<dandclark> scotto_: yes
<dandclark> masonf: That's hint popup
<dandclark> scotto_: It's not hint, it's subtnavigation.
<JonathanNeal> q+
<dandclark> masonf: Light dismiss desc for hint is different. It goes away when defocused. Also says you can't nest, but you have in this example. Interesting use case.
<dandclark> JohnathanNeal: Would this work for other popups where that behavior would be appropriate? e.g. CSS property that specifies these things, would that solve this use case?
<dandclark> masonf: You'd use non hint popup (auto), so you can nest it. Apply CSS property, control the fact that when dehovered, dismisses with CSS only. Could work.
<dandclark> JonathanNeal: Similar to transition delays.
<dandclark> masonf: Kind of , in that if you add this property with value you get new behavior. I'll think about that.
<dandclark> scotto_: Demo is in popup chat.
<masonf> q?
<JonathanNeal> ack JonathanNeal
<JonathanNeal> Up Next: Jonathan suggests `popup` itself becomes a CSS property. :P
<JonathanNeal> Kidding... For now...
<dandclark> masonf: Sounds like it needs more brainstorming.
<JonathanNeal> my-button { pop-up: auto; }
<dandclark> masonf: Undoing the last resolution? We need to use a different triggering attribute. Can't reuse others for this behavior, it's confusing and can't use both on same element.
<dandclark> scotto_: I agree with that, particularly for my use case. want to auto show on focus but not hover.
<masonf> Proposed resolution: use a new/different name for declarative hover-triggering of popups. Don't re-use togglepopup, showpopup, hidepopup.
<dandclark> masonf: even for hints, example is that you get different poups for hover vs for click.
<dandclark> s/poups/popups
<scotto_> +1 to proposed resolution
<chrisdholt> +1 to proposed
<tantek> +1
<JonathanNeal> Generally +1, but I don’t understand it well enough to feel authentic about it.
<JonathanNeal> q?
<masonf> RESOLVED: use a new/different name for declarative hover-triggering of popups. Don't re-use togglepopup, showpopup, hidepopup.

[mfreed7]

Based on the resolution above (not the first one, which was inadvertently posted here), we've decided to go back to a unique name for the declarative triggering of hint popups.

I'd like to re-post the proposal from the OP:

<img src=questionmark.png hoverhint=foo>   <!-- hoverhint means foo gets shown when this img is hovered -->
<div popup=hint id=foo>Tooltip</div>      <!-- hint pop up, but maybe could also be auto or async pop up? -->
<style>
img {
  hint-trigger-delay=500ms;  /* Controls how long the img needs to be hovered before triggering the pop up */
}
[popup=hint] {
  hint-hide-delay=1000ms; /* After the pop up/img are no longer hovered for this long, hide the pop up */
}
</style>

The code snippet above has some comments, which also incorporate part of the discussion we had last week. In particular, these behaviors might "just work" for any kind of pop up, not only popup=hint (or whatever). I.e. hoverhint could point to any kind of pop up to trigger-on-hover. And if the CSS hint-hide-delay property was set on a popup element (any kind?), then de-hovering for that long triggers a hide.

Thoughts? Suggestions for improvement?

[VicGUTT]

In

img {
  hint-trigger-delay=500ms;
}
[popup=hint] {
  hint-hide-delay=1000ms;
}

I would suggest parity with the terms used for activation/deactivation of popup (aka: show/hide).
So: hint-show-delay and hint-hide-delay. Plus using the opposite of "hide" here creates an intuitive parallel between the two words I believe.

In particular, these behaviors might "just work" for any kind of pop up, not only popup=hint (or whatever). I.e. hoverhint could point to any kind of pop up to trigger-on-hover.

Well in that case all "hint" references should be replaced by "popup":

<img src=questionmark.png hoverpopup=foo>   <!-- hoverpopup means foo gets shown when this img is hovered -->
<div popup=async id=foo>Tooltip</div>      <!-- async pop up, but could also be auto or hint pop up -->
<style>
img {
  popup-show-delay: 500ms;  /* Controls how long the img needs to be hovered before triggering the pop up */
}
[popup=hint] {
  popup-hide-delay: 1000ms; /* After the pop up/img are no longer hovered for this long, hide the pop up */
}
</style>

---

My personal open question for the very specific CSS properties (popup-(show|hide)-delay):

Is it becoming common to have CSS properties pertain to specific HTML contexts/elements/attributes ?

Wouldn't the more CSS'y way to add a new pseudo-class ? Something like:

img:popup-show {
  transition-delay: 500ms;
}

I know I saw some early specs (for anchor positioning maybe ?) also having some CSS properties expecting a very specific HTML context. So I'm just wondering.

[mfreed7]

Alright, Popover v1 shipped. Let's start talking about the popover=hint related things again. I think this issue is a good starting point.

[brechtDR]

There are far greater A11Y experts here. But from what I understood was:

tab on focus tooltip containing element -> next tab should toggle the tooltip with a focus on the container of the tooltip itself (by setting tabindex to 0 in this case).

using shift+tab to return, it should not toggle the tooltip.

escape key should close the tooltip.

Interested to hear thoughts on this 🙂

Created this little codepen demo with key navigation idea

[css-meeting-bot]

The Open UI Community Group just discussed [popup] Hover-based triggering for pop-ups.

The full IRC log of that discussion

<gregwhitworth> Topic: [popup] Hover-based triggering for pop-ups
<hdv> s/button]/button
<gregwhitworth> github: https://github.com//issues/526
<hdv> masonf: given that we recently landed popover spec in HTML… we're now ready to look at the “v2“ stage
<hdv> masonf: I've picked one issue, don't expect a resolution today, but just to get us started talking about v2 popover
<hdv> masonf: the issue I picked is about the hint behaviour of popover
<hdv> masonf: which is a type of popover that envisioned to be able to show on hover
<hdv> masonf: there were some issues … it worked nicely if you were using a mouse, but it didn't work for other input methods
<hdv> masonf: another question was if the role of the popover'ed element should change when it was a hover-type popover
<hdv> masonf: and anohter issue is that many elements where popover=hint would be use are not interactive elements, eg a <span> that shows a definition on hover
<gregwhitworth> q+
<hdv> masonf: finally, should we even call it hover, if you can also do it other ways, like touch
<hdv> masonf: so, lots of different issues, my main point of adding this to the agenda was to get it in people's minds
<hdv> gregwhitworth: it makes sense to me to not call it hover if it isn't just hover but also other input methods. Maybe we rename the issue?
<hdv> gregwhitworth: hint wasn't great as people didn't really know what it meant, but I also don't really know a different name?
<hdv> s/name?/name
<hdv> gregwhitworth: I don't have a strong opinion on names
<hdv> masonf: clarifying your question… are you against a hover behavior or just the name?
<hdv> gregwhitworth: would look at Sarah or Scott for their views on this
<masonf> q?
<gregwhitworth> q?
<gregwhitworth> ack gregwhitworth
<lea> I think it's fine for this to be a sort of "higher-level hover" for this that works with other input methods as well. There is precedent for similar things in the web platform, e.g. the "click" event is also triggered through the keyboard. I cannot think of any use cases where you want this popover to appear on hover, but NOT on focus
<hdv> masonf: we did talk about some of these things in the early days, like that hover also works when using keyboard
<hdv> masonf: I'll tag some people on the issue
<hdv> masonf: this is something a lot of developers roll on their own and not great for a11y… if we collectively put our effort in we can make one good way to do this

[mfreed7]

Per my meeting action item: @scottaohara @aleventhal @smhigley call to action! Let's figure out the right way to do "interest-based triggering" of popovers. See this comment for a possibly-incomplete list of open issues.

[mfreed7]

So the TL;DR of the meeting just now was that while this might be a "cool" addition to the pop-up API, it still has many things that need to be resolved, including:

• What to do about the role for elements with popuphovertarget?
• How to handle non-mouse user interaction?
• Should we call this "hover"? Or maybe something else that better captures the keyboard/touch/other use cases?
• How to spec the implementation of the behavior: during hover chain update, during mouseover update, etc.? What happens if the CSS properties are inside :hover or :focus selectors - when are styles updated?

At this point, based on the discussion, I'm going to consider this a "V2" type feature, not to be included in the first version of the Pop-up API. In the meantime, we can use this issue to brainstorm the answers to the above questions plus any others I left out.

There's now an explainer for popover=hint and hover triggering. I believe it addresses many of the questions above. Since hover triggering is only supported on buttons, the "role" question goes away. The explainer addresses non-mouse user interactions via keyboard focus or long-press. Naming ("hover") is still an open question, as it always is, but there's #767 for that specifically. And exactly how to spec it - let's cross that bridge when we start to spec it.

Given the above, I'm going to close this issue. Feel free to open fresh issues to discuss problems related to the new explainer.