Here are a few examples of where they've been used:
Here are a few examples of where they've been used:
|Open||None||T69500 jquery.tipsy (tracking)|
|Open||None||T117720 Remove use of jquery.tipsy from Wikimedia-maintained code|
|Resolved||matmarex||T115637 Replace usage of jquery.tipsy with OOUI PopupWidgets|
|Resolved||matmarex||T118906 Migrate deed chooser forms to OOjs UI|
|Resolved||MarkTraceur||T113371 Migrate text fields in UploadWizard deed step to OO.ui.TextInputWidget|
|Resolved||matmarex||T117119 Change popups informing about user choosing non-existent categories to use the warning system|
|Resolved||matmarex||T119385 Change tutorial checkbox tipsy to use OOUI PopupWidget|
|Open||None||T77402 Remove use of jquery.tipsy in MediaViewer|
|Open||None||T118124 Stop using jquery.tipsy for HTMLCheckMatrix labels (seen on Special:Preferences with Echo)|
|Resolved||• Jdlrobson||T119417 Remove use of jquery.tipsy in UniversalLanguageSelector|
|Resolved||WMDE-leszek||T141983 Use OOjs UI PopupWidgets instead of tipsy tips|
|Resolved||Jdforrester-WMF||T143027 Remove use of jquery.tipsy in BetaFeatures|
|Open||None||T143028 Remove use of jquery.tipsy in CodeReview|
|Resolved||Tpt||T143029 Remove use of jquery.tipsy in ProofreadPage|
|Resolved||santhosh||T143030 Remove use of jquery.tipsy in ContentTranslation|
|Duplicate||None||T143031 Remove use of jquery.tipsy in Wikidata|
|Open||None||T161403 Help indicator should show popup on hover not click|
|Open||None||T88630 Implement a way to display tooltips (using PopupWidget) on hover/focus rather than on click|
I'm removing F37375 from the description because it is a tipsy.
Tipsy-ies are non-interactive. You cannot move your cursor into the tipsy. It moves where your cursor points. They're used as supporting description / info to an element.
PopupButtonWidget in comparison is interactive. It may contain links that user can interact with.
Another aspect to take into account is we support hover to show/hide those is to be careful not to accidentally hide them while the user is moving the cursor to interact with them. That is, make sure to provide a safe channel (active area, delay in time, etc.) between the trigger an the popup that makes sure it does not close when the user moves from one to the other.
@violetto it was a generic concern, similar to the one in the "hover tunnels" section about this article on hover menus.
For example, with Hovercards, if you move your cursor too slow through the red area I added in the mockup below, the card will close before you are able to reach it.
This is not a big concern for hovercards since (a) you don't need to click the card (you can just click the link your cursor was over), and (b) the timer for closing the hover card leaves enough time for you to reach the card (you need to move the cursor really slow).
However, for other uses we may want to consider additional mechanisms such as making the red area I illustrated to be an invisible part of the card so that moving in that area counts as hovering the card and does not hide it.
To add to what @Pginer-WMF said — even when Hovercards did not have any actions on the Popup itself, people wanted to be able to tweak the delay times. There are two delay times—
Deciding these values for everyone is a pain. We tweaked it a couple of times for Hovercards and then ended up letting editors change it themselves from their common.js.
I personally prefer click actions for opening UI elements that I'll need to interact with, like — menus, drop-downs etc; and a hover action for tooltip type things. So, I'd prefer to see a PopupButtonWidget only when I click.
I'm on the fence about this whether this should be hover or on-click. I see this having two options: Either have a slight delay on hover to reveal the popup, or make it so it's on click.
If we make it on hover with a reasonable amount of delay, I'd prefer we use it sparingly, which I don't think has been an issue. I looked around Wikipedia for examples but it was quite hard to find some, with exception of hover cards. For me, the advantages is that this is a small target for a potentially important information.
Just like tooltips, triggered by mouse hover, they carry supporting info that are potentially important. Granted, tooltips' use case is different and so is hovercards. Users get hovercards from in-line links that are littered everywhere within an article. I can understand if it gets frustrating especially when your mouse is wandering across the page.
Here's an example at the top of my head why clicking on each icon is more work for something so small that carry helpful info for users:
Here's a proposal, do you have time to make a prototype? Perhaps with the same execution within Special:Preferences. If you can make me a prototype, I can find the users to try this out. I hear your point, and will be happy to follow what our users think feels best.
I share the same concerns about the small hover tunnels. We can give the illusion of a larger surface area with a bigger tapping space like indicated in yellow in the photo below. Moving the tipsy closer to the text/icon/target wouldn't be a bad idea.
I'm on the fence about this whether this should be hover or on-click.
For now, I am working on making it a config option, so that we can use the same widget for both use cases.
Here's a proposal, do you have time to make a prototype?
I am not sure if the patch will get merged, but testing this with different settings shouldn't be to much of a problem.
I think having both is going to be more confusing than picking one as we will end up with inconsistent behaviour between interfaces. I think we should stick with avoiding hover functionality.
As @matmarex points out in T117720: Remove use of jquery.tipsy from Wikimedia-maintained code, and @Perhelion in T147243: mw tooltip gadget/widget/plugin is needed, we really do need some way to do this in OOUI. Do you think it'd be better off as a separate widget then?