[popup] Bikeshed popover=hint

[mfreed7]

It has been mentioned often that popup=hint and popup=async aren't great at describing what they do. Perhaps we should pick better names?

For popup=hint, this is almost always referred to as a "tooltip". Should we use popup=tooltip? That does seem to "bake in" one particular use case, and there might be others. Then again, because of the strong prior knowledge about how a "tooltip" behaves, it also makes it easy to quickly understand the behavior. Is there another word that describes this behavior but is more generic?

For popup=async, this is variously used for things that are called "toasts", "notifications", "real-time notifications", "alerts", "snackbars", etc. The behavior is something that asynchronously (hence the name) shows up, does not change focus, does not close other elements or light dismiss, and sometimes times out and disappears. What name better explains this? Or maybe async does the job.

[mfreed7]

Note this comment by @domenic #495 (comment) which suggests popup=manual instead of async. Makes sense to me.

I also thought about popup=sticky since the behavior is "sticky" - it doesn't go away when other things open or when you click/move to other elements. Unfortunately, that's likely too close to position:sticky which is different. But maybe something similar?

[scottaohara]

i still favor popup=hint, as i'd submit 'hint' is the more generic term that things like 'tooltip' or browser validation error messages would fall under. but if those are the only use cases we see for this type of popup, then i guess it wouldn't be the worst thing to have this particular value be so very specific while the others are more generic names?

[mfreed7]

Let's use this issue to discuss specifically popup=hint. From this issue, here are a few suggestions:

• popup=hint
• popup=weak
• popup=light
• popup=transitory
• popup=transient
• popup=ancillary

Ideally, the name should convey the behavior, which is outlined in the explainer, here.

Other ideas?

[mfreed7]

Please either vote here using emoji (see below), or suggest something better. Thanks!

• popup=hint 👍
• popup=weak 😄
• popup=light 🎉
• popup=transitory ❤️
• popup=transient 🚀
• popup=ancillary 👀

[VicGUTT]

I'm on par with @scottaohara's comment above.

A quick Duckduckgo'ing of a definition for "tooltip" and a quick read of Wikipedia's Tooltip page yields words like: hint, info, description and help.

So depending on what we want the value to convey, here's a small list of alternatives I've put together:

Meaning

• hint
• tip
• title (akin to the existing "title" attribute)
• description
• help
• info

Behavior

• light
• temporary (instead of "transitory" as I think it's a more common and easily understandable word)

Action

• pointer (hovered, tapped, long touched, stylus'd)

No! God! No! God! Please! No! No! No! Nooooooooooooooooooo! 😅 (-> https://media.giphy.com/media/d10dMmzqCYqQ0/giphy-downsized-large.gif)

• transient
• ancillary

-> Explanation: I'd find it unfortunate if I'd have to open a dictionary every time I see those words (specially as a none native English speaker).

---

Based on the list above, my picks in order would be: hint/light, tip, title, then help/info/description

[VicGUTT]

Also thought of "delay" but, nah...

[hidde]

Like @VicGUTT , I find ‘temporary’ easier to understand than ‘transitory’ and would also need to look up and therefore be against ‘transient’ and ‘ancillary’ (all as non native speaker).

I voted for ‘hint’, because it personally gives me associations with the kind of thing popup=hint would do. I like ‘tooltip’ too, but can understand people would find it too specific.

[VicGUTT]

Same with regards to "tooltips". I think it's fine but worried it could get some backslashes similar to how the "masonry" keyword for grid did.

[css-meeting-bot]

The Open UI Community Group just discussed [popup] Bikeshed popup=hint #532, and agreed to the following:

• RESOLVED: we will choose one of these five names: hint, title, light, info, advisory.

The full IRC log of that discussion

<hdv> Topic: [popup] Bikeshed popup=hint #532
<hdv> github: https://github.com//issues/532
<JonathanNeal> masonf: There was some feedback to name this less around the use-case and more toward the behavior.
<vicgutt> q+
<JonathanNeal> masonf: there are various suggestions, and one has a handful of votes.
<hdv> ack vicgutt
<JonathanNeal> vicgutt: I voted for ‘hint’, and after some research, I feel this one most describes the behavior.
<JonathanNeal> vicgutt: ‘hint’ is generic enough. I am also fine with tooltip.
<hdv> q+
<JonathanNeal> hdv: are there other obvious behaviors we can think of for tooltip?
<hdv> ack me
<JonathanNeal> hdv: a use case for ‘hint’ is tooltip, but are there other use cases that ‘hint’ could be used for?
<JonathanNeal> masonf: ‘hint’ is more transient than a popup.
<JonathanNeal> flackr: I could see someone using it for a hover menu.
<JonathanNeal> masonf: I would encourage folks to use an auto popup for that.
<JonathanNeal> vicgutt: for people who remember the association, I could see ‘title’ being that term.
<JonathanNeal> masonf: maybe we can limit the possibilities down to just ‘hint’ and ‘title’?
<JonathanNeal> flackr: the spec says “title” is advisory information that would be suitable for a tooltip.
<hdv> JonathanNeal: one of those was 'light', was that as in lightbox or lightness or smaller?
<hdv> masonf: lightweight, I think…
<JonathanNeal> vicgutt: ‘light’ as in ‘not heavy’.
<JonathanNeal> JonathanNeal: bkardell_ , or it implies we have ‘heavy’. As in heavy duty popup.
<JonathanNeal> masonf: I do not want to revisit this issue again.
<masonf> Proposed resolution: we will choose one of these five names: hint, title, light, info, advisory.
<JonathanNeal> masonf: we can resolve to like “one of these 5” and that would be helpful.
<bkardell_> info is not bad imo
<JonathanNeal> JonathanNeal: I also like info.
<JonathanNeal> +1 to the proposed resolution
<masonf> RESOLVED: we will choose one of these five names: hint, title, light, info, advisory.

[bkardell]

Just setting up a polling mechanism since the options resolved don't match those of the original emoji poll

• hint 👍
• title 😄
• light 🎉
• info ❤️
• advisory 🚀

[mfreed7]

Thank you @bkardell for setting up the poll.

Folks, please vote! And encourage other people to vote. We need to resolve this issue soon and pick a name. I'd ideally like to resolve on a name at the August 4 meeting, if possible.

[Westbrook]

hint is great when open/close semantics ONLY are a managed.

If title was used, I’d expect there to be more accessible semantics exposed by default.

light implies dark which seems incorrect for “popups”.

info is close to hint and could be a close second.

advisory is just long enough to be wrong with no further explanation.

[domenic]

None of these seem to be about behavior (which, IIUC, is force-closing others of its type, and also responding to various dismissals). All of them seem to be about semantics. It feels like the feedback on why to rename wasn't really taken into account, and the group just came up with a bunch of new semantic-name synonyms?

[scottaohara]

what about "quick" or "eager" (to reuse a value from the loading attribute)?

something to indicate that the popup will display by a user focusing or hovering the associated element (auto is out because we're already using it - and it's also not really automatic because there is still something that must be done to make it show).

[WickyNilliams]

I personally think tooltip is best. I feel like there's a universal understanding of what this means, and what behaviour is associated with it. Nobody seems to have come up with other use cases for this behaviour, so why not the obvious choice?

[mfreed7]

None of these seem to be about behavior (which, IIUC, is force-closing others of its type, and also responding to various dismissals). All of them seem to be about semantics. It feels like the feedback on why to rename wasn't really taken into account, and the group just came up with a bunch of new semantic-name synonyms?

No, we did discuss this in the meeting for sure. The light suggestion was discussed at some length, with "light" as in "lightweight". The problem is that the behavior is more than can be described in a single word. The behavior, though, is well described by the canonical example of that behavior, the "tooltip". The word "hint" is close, and is less directly tied to a particular UI pattern, so maybe ok. Imagine if I asked you to pick a single word to describe the behavior of a computer. It can be done, but the most descriptive word is "computer", since that conveys what a computer does better than any single word or short phrase, even if it's only one example embodiment of that behavior.

I'm really not arguing against your point, I just think that no great alternatives have emerged. So far for behavioral words we have: light, temporary, transitory, transient, ancillary, quick, and eager.

The last two were recently added, and while I admit they're better, they also don't describe the one-at-a-time and light dismiss behaviors of this type of pop-up. The rest (which we discussed) were fairly universally hated. None of them really describes the behavior, and all (I can almost guarantee) will end up causing developer confusion. Whereas people know what a "tooltip" or maybe a "hint" is, and they have (correct) expectations about how it behaves.

More/better suggestions are appreciated! The resolution was attempting to force this discussion, and it seems to be working.

[mfreed7]

Let's resolve this at next week's OpenUI meeting, please.

If you haven't already, please vote on a name suggestion here.

[css-meeting-bot]

The Open UI Community Group just discussed [popup] Bikeshed popup=hint, and agreed to the following:

• RESOLVED: Do not rename popup=hint.

The full IRC log of that discussion

<gregwhitworth> Topic: [popup] Bikeshed popup=hint
<hdv> masonf: just wanted to say, as you said when summarising, gregwhitworth, this was a difficult vote as there isn't really one good answer to this
<gregwhitworth> github: https://github.com//issues/532
<hdv> gregwhitworth: yes thanks everyone for trying to get it right and being respectful
<hdv> masonf: ok, so 532 is about what should the attribute name for what we currently know as `popup=hint`
<gregwhitworth> q?
<hdv> masonf: currently in GitHub most votes are for `popup=hint`, i.e. keeping it like it is now and a lot fewer for the others
<hdv> bkardell_: will domenic object to it?
<hdv> masonf: this conversation was based on a point from domenic… his point was that it was that 'hint' not really a description of the behavior
<hdv> masonf: my sense is that he strongly wanted something that was more behavioral, but as it seems we didn't really have great ideas for words that meet that, I hope he would be ok with this
<masonf> Proposed resolution: Do not rename popup=hint.
<masonf> RESOLVED: Do not rename popup=hint.

[annevk]

What I miss here is consideration for ::tooltip: w3c/csswg-drafts#8930. I feel pretty strongly these features need to be named consistently. Perhaps the CSS WG needs to rename to ::hint. I'll leave that to you all to make the case to them, but we shouldn't end up with two separate names just because a different group of people worked on it.

[mfreed7]

What I miss here is consideration for ::tooltip: w3c/csswg-drafts#8930. I feel pretty strongly these features need to be named consistently. Perhaps the CSS WG needs to rename to ::hint. I'll leave that to you all to make the case to them, but we shouldn't end up with two separate names just because a different group of people worked on it.

I tend to agree with this viewpoint. As the person who wrote the popover=hint explainer, I really struggled to describe any use case besides a "tooltip". It actually made the explainer harder to write, because I had to say "here's the use case, tooltip, and from now on in the doc I'll call it a 'tooltip', but the feature is called 'hint'". @annevk's point is a good one that there's already a concept on the platform called explicitly ::tooltip. Feels like maybe we should rename to popover=tooltip. @domenic you had opinions last time we discussed this - WDYT?

[mfreed7]

@lukewarlow just made a comment to me about a potential future <tooltip> element, and asked if calling it popover=tooltip makes that more difficult/troublesome. I tend to think it would actually help, given that it would be yet another usage of the same term "tooltip" to mean the same thing.

[domenic]

@domenic you had opinions last time we discussed this - WDYT?

I think we're running into a conflict between two things:

1. Consistency between HTML and CSS
2. The fact that HTML is, in its platonic ideal, about behavior and semantics, whereas CSS, in its platonic ideal, is about styling.

So CSS folks wanting a name like "tooltip" makes a lot of sense: it's a UI pattern; you're styling the actual tooltips that show up and are definitely called tooltips by everyone.

Whereas, HTML works best when we try to keep things vague and general, so that the markup makes sense even when the page is being presented by a non-visual browser, or is reinterpreted for a new type of device (computer -> smartphone -> smartwatch), and so on. So a name like "hint" (or my old favorites according to the poll, "weak" and "transient") are aligned with HTML.

But in the end, I think I agree that (1) is more important than (2). If these things really behave the same, then probably they should get the same name. And probably "tooltip" is the better name. HTML has a long history of making compromises away from its pure platonic ideal, especially in naming. Examples include things like <small> and <hr>.

I do worry a bit that developers might be confused if a <div popover="tooltip"> cannot be styled by ::tooltip { ... }, and in fact is totally separate from it. But I trust you all to decide if that's realistic.

[keithamus]

I'm not sure how much weight my opinion carries but I am concerned we're conflating two quite separate things; ::tooltip is for styling of the thing that title= produces, and popover=hint is an interaction pattern for exclusivity and ephemerality of the popover.

I could make a popover=hint that behaves identically to ::tooltip, as a replacement for it, and I might even name it the same thing. But the hint-style popover behaviour applies to many other things:

• "rich tooltips" are usually given other names, such as popover, preview or hovercard. These are intentionally separated in design systems because they're more complex widgets and nest non-rich tooltips inside of them (but would not allow nesting of themselves).
• sub-menus would likely use popover=hint as it matches the interaction model, but they are definitely entirely separate from ::tooltip.
• error messages for things like form invalidation, often these might be called "flash" or "bubble". They are tooltip-like but, like hovercard they would probably nest ::tooltips and not nest themselves. Additionally they would be invoked from different interactions to tooltips even if they borrow the exclusivity&ephemerality of hint.
• toasts might also use the same pattern, and again might nest ::tooltip but would definitely not nest toasts.

TL;DR inconsistency between these terms is a feature not a bug.

[hidde]

+1 to Keith, it makes sense to me to say “hint” is a broader category than tooltip.

Tooltip, in Tantek's 2000 suggestion, Lea's 2009 proposal and the 2023 discussion, continues to mean the component that UAs display natively when title attribute is present, or components that look and behave pretty much like that.

Hint, to me too, includes such tooltips, but also the interactions @keithamus mentions. I'd also add the “link preview” Wikipedia displays when you hover/focus a link.

I also think it's ok to have that one word for that broader category of items, given the alternative: being too specific. The popover attribute's name also covers a broader range of things, and (fwiw) in my conversations with developers about popover in the past year, that seemed to resonate with folks.

[bkardell]

+1. I agree with all of the points that @keithamus and @hidde made. It's probably worth noting that the issue 8930 csswg issue specifically mentioned that popup is a separate thing and that all of these that require more than title really are a non-goal.

[annevk]

Given that the behavior is essentially a "tooltip" I still think that's the best name given the web platform is already using it (or will be using it). Having a lot of different names generally makes things harder to use. I don't think that the ability to use a tooltip for a variety of use cases detracts from that.

[keithamus]

I agree that lots of different names make things harder to use, especially where there is significant overlap. The opposite is also true though; naming incongruent behaviours the same makes things harder to use. In this case I believe the behaviour of popover=hint is incongruent; it overlaps but not entirely. The "tooltip" pattern is a superset of the behaviour prescribed by popover=hint.

I think naming this feature popover=tooltip will make it harder to use in cases where you don't want a tooltip (e.g. submenu), because semantics that popover=tooltip has will be assumed to be congruent with tooltips, but they aren't. Consequently if it were named popover=tooltip, I could foresee people asking questions like: "why does my popover=tooltip not open when I over over the <button popovertarget>" or "why does it not close when I mouseout of <button popovertarget>". These are expectations of ::tooltip and the tooltip pattern in general, but they are not prescribed to popover=hint.

Ultimately I want the feature, it's important to me and I believe it'll improve web accessibility long term. If it has to be called popover=tooltip to get shipped, I'll live with that, it's a small price to pay. But considering this is a bikeshed issue I will maintain that, IMO, it is wrong name for this.

Much love to everyone, I know we all care about doing the right thing.

[css-meeting-bot]

The Open UI Community Group just discussed [popup] Bikeshed `popover=hint` .

The full IRC log of that discussion

<Travis> masonf_: Has been discussed a few times...
<Travis> .. where are we now?
<Travis> .. openui has discussed the naming value for popover=hint
<Travis> .. now bringing this to WHATWG
<Travis> .. the WHATWG editors are pushing back on the name.
<Luke> q+
<Travis> .. primary use case is for tooltip. But there are other use cases.
<Travis> .. not sure if we need to discuss. (we've discussed before). I want to register the viewpoint of webdevs by putting a poll like we've done before.
<Travis> .. want to get the votes for folks that have a viewpoint.
<Travis> .. if that changes folks mind, then great, if not, we tried.
<Travis> .. my plan is to do that today barring objections?
<gregwhitworth> ack Luke
<Travis> Luke: I think that sounds like a good idea.
<Travis> .. to clarify, editors themselves may not be in agreement...
<Travis> .. I personally think 'hint' is better than 'tooltip'.
<Travis> .. will see what developers want.
<bkardell_> q+
<Travis> masonf_: I'll put a link and post to the WHATWG issue.
<gregwhitworth> ack bkardell_
<Travis> bkardell_: can you pre-share the poll before posting?
<Travis> .. I would like to offer feedback on how its worded.
<Travis> .. would be good to summarize in short words what the options are.
<Travis> masonf_: concerned about my own bias in what I might right. Happy to work with you.
<keithamus> q+
<Travis> .. want to make sure there's enough context in the issue.
<Travis> .. bkardell_ we're asking should it be tooltip or should it be hint?
<Travis> .. tooltip does have an existing meaning and that's the issue, right?
<Travis> .. It's a bit complicated to explain.
<gregwhitworth> ack keithamus
<Travis> bkardell_: If we share it widely might hear some feedback that isn't very helpful (without context)
<Travis> keithamus: what's the goal of the poll?
<Travis> .. 'hint' or not 'tooltip' is the right choice--that's what we all agree on right?
<bkardell_> fwiw I would like very much to discuss this in csswg wrt the pseudo issues
<Travis> .. is the goal of the poll to prove that 'tooltip' is the preferred name, and folks don't care about the nuance.
<Travis> .. but if they say they get the nuance, will that sway the editors?
<Travis> .. can the editors just disagree with the poll?
<Travis> masonf_: point in favor of tooltip is that it's less-confusing for web devs. (to avoid creating a new name that they get)
<gregwhitworth> q+
<Travis> .. my idea is that if the poll shows otherwise, then that should be convincing arguments.
<Luke> q+
<Travis> (existential discussion of what it takes to sway editors)
<Travis> gregwhitworth: I think there needs to be a whatwg triage meeting where we join and stop this pushback.
<Travis> .. because there was already a poll.
<Travis> .. can we open an issue so that we can join the triage? Seems like we shouldn't need to do the 2nd poll.
<Travis> .. I think it would help us all ground ourselves.
<Travis> .. I also think that's why select styling is going in circles.
<Travis> .. hopefully it would be fruitful.
<Travis> .. if we can have a meaningful discussion with them, we'll bring it back to this group. Don't want you to waste your time.
<bkardell_> https://www.irccloud.com/pastebin/EnVseNY8/
<keithamus> q+
<Travis> .. ex: maybe a result is that the poll must have a whatwg url to be valid?
<gregwhitworth> ack gregwhitworth
<gregwhitworth> ack Luke
<Travis> .. still thing it's worth having the discussion about popover-hint/tooltip.
<bkardell_> masonf_: are you going to add it on the agenda for that meeting?
<Travis> Luke: We might not have to prove our point to the HTML editors, might be more easily swayed as they don't agree with themselves.
<Travis> .. not an us vs them situation, just a disagree on naming.
<bkardell_> https://github.com/whatwg/html/issues/10128
<scotto_> q+
<gregwhitworth> ack keithamus
<Travis> masonf_: I hope to gain (from the poll) larger numbers of input from the community. It could even convince me.
<Travis> keithamus: about the whatwg convo, I think the good-faith interpretation is that we aren't correctly summarizing the nuance and providing it for their understanding.
<Travis> .. for the select case, I don't think they are related. Yes there is pushback, but not for the same reason.
<Travis> .. there is space for us to investigate that.
<Travis> .. in the hint case, we did a good job outlining, but haven't seen a clear result from the editors. Maybe they need more time to read/respond to what's been posted.
<Travis> masonf_: no response yet from an editor after all our comments?
<Travis> keithamus: yes, I think that's right. Mine was one of the last comments... only saw one or two comments from the editors.
<Travis> .. maybe we could triage+ it and schedule for discussion.
<Travis> masonf_: Yep, that's a good point.
<Travis> keithamus: maybe they've tried to look at it in a short period of time.
<masonf_> q?
<Travis> masonf_: well, I do see a comment from one editor expressing their opinion.
<gregwhitworth> ack scotto_
<Travis> scotto_: generally agree with keithamus. One worry about a poll: all designers/developers thing that anything that pops up is a tooltip. 😁
<Travis> .. in range discription, the number that shows up above the range slider is a tooltip!?
<keithamus> q+
<Travis> masonf_: Hmm. Most devs know the word tooltip, then maybe that's the word we should use?
<Travis> scotto_: yes, perhaps. Words have meaning, should be clear what they will get.
<una> q?
<una> q+
<Travis> masonf_: on the dev, I want this 'thing' need to go find it... what do I type..? I type 'tooltip' cause that's what I know.
<gregwhitworth> Zakim, close queue
<Zakim> ok, gregwhitworth, the speaker queue is closed
<Travis> .. so, maybe that's the right word. I could agree with that if it plays out that way.
<gregwhitworth> ack keithamus
<Travis> scotto_: like with title= that could be a tooltip but perhaps it's not in some cases (accessible name)
<Travis> keithamus: sub-menu case. It can be used for it. might want to frame it that way, and not call it a tooltip.
<Travis> masonf_: why not a popover=auto?
<Travis> keithamus: you only want one submenu open at a time?
<Travis> masonf_: you get that with nested popover=auto
<Travis> .. popover=hint takes prescedence over auto.
<Travis> .. you don't want the tooltip showing to close the other thing (a submen) that might have opened.
<Travis> .. nesting popover=auto is exclusive (unless nested) if one opens the others close.
<gregwhitworth> ack una
<Travis> una: regardless of use cases, etc., the way its defined is a behavior. Not an object. If we go with tooltip it's not .. mixed metaphore of an object or noun, vs a name meaning the behavior. When talk about the set of values, there needs to be consistency overall. Tooltip is used to describe semantics not behavior.
<Travis> gregwhitworth: there is a learning curve to understand the differentiation.
<Travis> . it helps developers to know what to go to.
<Travis> :)
<gregwhitworth> end topic
<gregwhitworth> Zakim, end meeting

[github-actions]

There hasn't been any discussion on this issue for a while, so we're marking it as stale. If you choose to kick off the discussion again, we'll remove the 'stale' label.

[mfreed7]

Since the hint naming is no longer the sticking point for popover=hint, I'm going to close this issue.