[popup] Hover-based triggering for pop-ups

[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/openui/open-ui/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/openui/open-ui/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 https://github.com/openui/open-ui/issues/329.

There was some discussion of keyboard support for triggering popup=hint, and @scottaohara nicely opened an issue to discuss that: https://github.com/openui/open-ui/issues/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 https://github.com/openui/open-ui/issues/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/openui/open-ui/issues/546
<dandclark> Github: https://github.com/openui/open-ui/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/openui/open-ui/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/openui/open-ui/issues/526
<JonathanNeal> github: https://github.com/openui/open-ui/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]

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.

Thanks - I think I agree with this point. It'd be nice to have these be more symmetrical.

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

100% agree with this one. In fact, as I've been prototyping this in Chromium, I used hoverpopup as the name, and made it work for all pop-up types. Taking this together with the above, and adding dashes for "pop-up", we're at:

• pop-up-show-delay - hover a triggering element for this long to show the pop-up
• pop-up-hide-delay - de-hover the pop-up or its triggers/anchors for this long to hide the pop-up.

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 ?

I agree that this does feel a bit weird: pop-up-show-delay only has an effect on elements that have the hoverpopup attribute. And pop-up-hide-delay only has an effect on elements that have the popup attribute. But I guess I don't see how that's terribly different from CSS properties that only have an effect when other CSS properties are also present, such as transition-delay. That only does anything when transition-duration != 0.

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

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

That's an interesting suggestion. The problem is that it's a bit muddled - what state/class does the :popup-show pseudo class match? And that would preclude using transition-delay on that element for actual transitions, right?

[VicGUTT]

Ah, sorry, only just now seeing your comment. I should look into configuring my Github notifications.

Yes, the "dashyfied" version of popup. So yep, all for pop-up-show-delay and pop-up-hide-delay.

I agree that this does feel a bit weird [...] But I guess I don't see how that's terribly different from CSS properties that only have an effect when other CSS properties are also present, such as transition-delay. That only does anything when transition-duration != 0.

I don't see it being "terribly different" either but "different" nonetheless.

• First, the dependency is in relation with another CSS property and stays within the CSS only context.
• In this particular example they share a relation as prefixed by the same transition keyword. Also, they can be condensed into shorthand versions transition: ...;
• Here we at least have precedence (CSS properties depending on each other).

I guess my question was more in the lines of "is there precedence" or "is this a agreed upon / reliable strategy moving forward, where CSS and HTML become so implicitly inter-dependent".

That's an interesting suggestion. The problem is that it's a bit muddled - what state/class does the :popup-show pseudo class match?

Yes, I agree. More thoughts would need to go into it. This conversation could probably be tied to the :top-layer/:modal discussions.

And that would preclude using transition-delay on that element for actual transitions, right?

Right, good catch. I'd say "possibly", but it'd definitely create some conflicts. I guess in that case maybe the pop-up-(show|hide)-delay properties could both be moved to the element with the popup="..." attribute.

Which begs the question: in it's inactive state, would the [popup=hint] element have a default display of none? If yes, the problem could be broaden and "generic'ifed" to include any display none'd element?

[css-meeting-bot]

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

The full IRC log of that discussion

<hdv> Topic: [popup] Triggering and light dismiss for popup=hint #526
<hdv> github: https://github.com/openui/open-ui/issues/526
<JonathanNeal> masonf: this one is more behavioral. I’m most of the way thru implementing this. This is about a declarative way so that when you hover over an element then a popup is triggered.
<JonathanNeal> masonf: there are some css properties to control how this would behave.
<hdv> q?
<JonathanNeal> masonf: there are some naming concerns for what we could name these properties, or the attribute itself that triggers this behavior. First, I want to talk about the behavior, itself.
<flackr> q+
<vicgutt> q+
<hdv> ack flackr
<JonathanNeal> flackr: some may ask; why not use `:hover` to handle this?
<vmpstr> can you do that with animation-delay
<JonathanNeal> masonf: it has to do with the delay/debounce. Not just hovering, but hovering and lingering for half a second, then trigger the popup. Managing that state can be tricky.
<bkardell_> q+
<JonathanNeal> flackr: Maybe there’s interest in some kind of generic show and hide delay. We have similar things for animations (animation timing) but perhaps there is a more generic concept that could apply here.
<JonathanNeal> masonf: one of the early comments on the proposal was “these properties are curious because they seem to really only apply to this one thing”.
<JonathanNeal> masonf: we would also be concerned with circularity issues
<hdv> ack vicgutt
<JonathanNeal> vicgutt: +1 what flackr said. I was also wondering if it could be made more generic, so that we could animate (other) things that are CSS display:none.
<JonathanNeal> q+
<hdv> ack JonathanNeal
<hdv> JonathanNeal: is a gist of what this behavior is similar to an animation-delay, but more like an event delay? In that it splits what would be a discreet event that is open/close into kind of before open, open, is that a way to think about this?
<JonathanNeal> masonf: it is more like an animation delay than an event delay.
<hdv> ack bkardell_
<JonathanNeal> bkardell_: is the explainer full up to date?
<JonathanNeal> masonf: yes, with everything that has been resolved.
<JonathanNeal> bkardell_: I need to go back and get my head around where we are right now. My question might already be answered the explainer.
<JonathanNeal> bkardell_: So if we had a form field and we had hints for what those form fields should be that trigger on focus (say on mobile), would those still popups? hints?
<JonathanNeal> masonf: We have a similar issue about “what does it mean to hover when we don’t have a mouse/cursor?”
<JonathanNeal> bkardell_: is it clear what we are calling “hovering” when it may not be triggered by what CSS defines as hover?
<JonathanNeal> masonf: it is currently geared toward pointers.
<JonathanNeal> bkardell_: so would there be any way to get that on a mobile device?
<JonathanNeal> masonf: there may be with a long touch, but I do not know if that is specced.
<JonathanNeal> flackr: you can get :hover to match, I believe.
<JonathanNeal> flackr: :hover and :active.
<JonathanNeal> flackr: People are going to continue to want to do this use case. We need to make it easy to make them accessible. It should be solved more fundamentally.
<hdv> q?
<JonathanNeal> vicgutt: or terminology around “pointer” to be more generic?
<JonathanNeal> flackr: are you specifically recommending “pointer”? An issue would be that “pointer” doesn’t refer to the state.
<JonathanNeal> bkardell_: “hover” is a specific kind of interaction.
<JonathanNeal> bkardell_: there are known issues with the current mobile versions of “hover”
<masonf> q+
<hdv> JonathanNeal: I have been looking at which inputs perform which actions… if we can solve this in a way that is more agnostic, that would be very helpful, also with the other issues
<flackr> q+
<JonathanNeal> JonathanNeal: thank you hdv for scribing when I chat.
<hdv> ack masonf
<bkardell_> like, if this was the 'info' state or 'hint' state which might or might not be the same as hover
<JonathanNeal> JonathanNeal: sorry masonf for jumping the queue. :(
<bkardell_> q+
<JonathanNeal> masonf: I would prefer we tie this to the well defined “hover”, and not solve all the world’s problems with the popup API.
<hdv> ack flackr
<JonathanNeal> flackr: I want to have a context menu trigger at some point. This doesn’t explicitly define what triggers it, either.
<JonathanNeal> flackr: Maybe that’s a good reason to use a term that describes the intent of the interaction versus how it happens.
<JonathanNeal> masonf: my only issue is that the term we have for that is “hover”.
<hdv> ack bkardell_
<JonathanNeal> bkardell_: there is a case sometimes where we must tie something to a specific interaction, but more often than not we want to describe things in ways that does not but lets us solve it.
<JonathanNeal> flackr: nobody would probably want to delay a context menu
<bkardell_> I like what flackr is throwing down +1
<masonf> q
<JonathanNeal> masonf: well “nobody” is strong.
<JonathanNeal> masonf: please put your comments into the GitHub issues.

[mfreed7]

The meeting above had some great discussion. Several folks had good suggestions for this part of the API - please post them here, and we'll discuss at a future meeting.

[mfreed7]

Any comments on this issue? I have the proposed behavior implemented in Chromium, with some renaming suggestions from the discussion above. As it stands, this is how it works:

<div popuphovertarget=foo>
<div popup id=foo>Pop-up content</div>

<style>
[popuphovertarget] { pop-up-show-delay=500ms; }
[popup] { pop-up-hide-delay=1s; }
</style>

New concepts:

• popuphovertarget=foo means that when the element with this attribute is hovered, the pop-up with id=foo should be shown. This attribute can be applied to any element type.
• The pop-up-show-delay CSS property controls how long you have to hover before the pop-up is shown. This property has no effect on elements that do not have a popuphovertarget attribute, because there is nothing to show in that case.
• The pop-up-hide-delay CSS property enables a feature that will hide a pop-up after it has not been hovered for a period of time (controlled by the value of this property). This is independent of the above two points, and can be used on any pop-up.

We've also discussed (in this meeting) that the spec/behavior likely needs to include some affordance for non-mouse users. For example, non-interactive controls that have the popuphovertarget attribute might need to be added to the keyboard tab navigation order (i.e. act like tabindex=0) so that keyboard users can access this content. That would also mean it needs to be triggered in that case by the element getting focus. Perhaps all of that only happens when using caret navigation? For touch users, it sounded like there was already a way (e.g. via long touch) to activate the :hover pseudo class, so that use case might be handled.

Generally, thoughts appreciated on the above. Having implemented the prototype, it does seem quite useful, as you can implement a fully animated tooltip that shows and hides after customizable delays, all with about 4 lines of HTML/CSS and no JS.

[css-meeting-bot]

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

The full IRC log of that discussion

<masonf> Topic: Hover-based triggering for pop-ups
<masonf> Github: https://github.com/openui/open-ui/issues/526
<bkardell_> masonf: this is about triggering the popup on hover/unhovered
<bkardell_> masonf: the proposal here is to add another attribute maybe that will be able to be put on the element to show/hide
<una> q+
<bkardell_> masonf: this one is slightly different in that you can have a css configurable delay - and there is a companion css property to delay a hide
<bkardell_> masonf: the obvious use case is a tooltip, but there are others
<scotto_> q+
<bkardell_> masonf: there is a syntax proposed for the css properties as well, but I'd love to discuss it a little... I have implemented the proposed behavior in chromium
<emilio> q+
<bkardell_> una: can definitely see this being very useful. The first thing I think about when I think about hover interactions is what about focus interactions - can you talk about how that would work
<bkardell_> masonf: there is no answer - I proposed that perhaps that could make it focusable too... bkardell_ showed me an example like this that makes it work like that (not with this proposal)
<bkardell_> una: also on mobile there is a click state - all of them are getting at this same 'showing something with delay' and it might be nice to have just one way and not require developers to learn/do N things here - is it possible to have a higher order thing here
<bkardell_> masonf: as it stands you can hover over things that aren't even interactable.
<bkardell_> masonf: my understanding is that with touch if you long press you can get the hover state to match. the only thing that is really missing is what if it is pure keyboard. I was trying to avoid requiring developers to say 20 different things and let the UA mitigate that
<bkardell_> una: ok I agree - it would be a better experience if the UA handled that. It might be good then to avoid the actual use of the term hover here - that's one way of interacting maybe, but this is kind of just generally a popup interaction target
<bkardell_> masonf: I don't disagree with you - my only counterpoint is that hover exists and people seem to understand it... the UA can mititgate based on that and the fact that we just called it hover a long time ago... it's just very familiar
<chrisdholt> Would we focus non-focusable elements magically because of the presence of this and what would the implications be for partial AT users for instance? Would that cause confusion?
<masonf> q?
<masonf> ack una
<bkardell_> una: as someone who writes a lot of css I think of hover and focus as distinct things that you have to deal with differently - if there is something that is about animating, for example, and it can do both that would be good
<bkardell_> scotto_: similar feelings. I generally agree on the naming thing too.. I would have expected needing then a popupfocustarget... we're asking them to write a lot of attributes. Better than asking them to add a lot of js but still- people will complain
<masonf> q?
<bkardell_> scotto_: it might just be a naming thing... but also to una's point there might be a use case where someone wants something to popup on focus vs hover, so the counterpoint is that it might be useful to be able to differentiate.
<masonf> ack scotto_
<bkardell_> scotto_: if it is specified about non-interactive elements getting focus... what role does it become?
<bkardell_> q+
<bkardell_> scotto_: I know that we're going to run into this
<masonf> ack emilio
<chrisdholt> +1 to the focus of generic elements concern - I don't know that we can reliably assume a role there and I can forsee it being common that this just gets slapped on divs.
<bkardell_> emilio: one of the issues of controlling the delay using css is that you need to specify very well. Looking at the chromium source, it is done from ...?... it doesn't take the hover pseudoclass into account - so you couldn't differentiate as scotto_ mentioned. It may be a bit tricky, you have to define a lot, how changes are handled. I feel like a lot of these things... maybe it should be done at the time when the mouseover event happens
<bkardell_> emilio: I guess my concern is getting this into a very well defined state
<bkardell_> masonf: good points
<bkardell_> masonf: this part of the feature - using it seems nice and easy but it is less well developed than the rest and might have to be moved to a version 2
<masonf> q?
<emilio> scribenick: emilio
<emilio> bkardell_: interested in scotto_'s point, I've thought about similar things
<emilio> ... an example with text is just text, and you want to provide a little hint / tooltip thing that gives you the definition if you focus on it
<emilio> ... not a link or anything, just text
<emilio> ... it's not an interactive element, but it kind of is because it's now a popup trigger
<emilio> ... I was also thinking about this today
<emilio> ... does this go from plain text to needing a role?
<emilio> ... because you can also style this and it still acts as a popup and then it doesn't need that role anymore
<masonf> q?
<masonf> ack bkardell
<emilio> ... I think there's like a core thing we need to figure out about these components, about how you make something pseudo-interactive from the UA standpoint and can communicate
<emilio> ... to the AT the right behavior
<scotto_> q+
<emilio> ... it's a little weird that things go from regular to needing a role
<emilio> q+
<emilio> bkardell_: you could potentially click back and forth between them
<emilio> ... I think that's a core thing we need to figure out
<emilio> masonf: how does that behave if we put tabindex=0?
<emilio> ack scotto_
<emilio> scotto_: masonf to your question, yeah, that's one of the pros / cons of global attributes, you can put tabindex on anything
<emilio> ... if you put tabindex on a span/div that'd indicate that this is more than a generic element
<emilio> ... in most cases that would just announce the contents of the generic element as the accessible name
<emilio> ... which can be benign or terrible, like if you have a whole article inside
<emilio> ... same with title=
<emilio> ... let's assume that if title showed on focus, which it doesn't, a generic element with a lot of text would give all the contents of the element before reading the title
<emilio> ... to stop that would require the screen reader to stop before you get to the description
<emilio> ... maybe this is a v2 feature, because there's a lot of things to work out there
<masonf> q?
<bkardell_> scribenick: bkardell_
<emilio> ... we don't want to do this if it's not an improvement over the title attribute
<bkardell_> emilio: I was going to ask about title, so I guess scott's question mainly covers it
<masonf> q?
<masonf> ack emilio
<emilio> ack emilio
<bkardell_> masonf: so - do people want to set this aside and comment on the issue? it does seem there are a lot of open questions
<chrisdholt> +1
<bkardell_> scotto_: more discussion yes
<emilio> +1
<chrisdholt> there is a lot to consider here
<bkardell_> una: I like the energy of it though
<bkardell_> scotto_: there's been a lot of work here - it will be good someday

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

[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/openui/open-ui/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 https://github.com/openui/open-ui/issues/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.