Is this still an ongoing issue? I wasn't able to find screenshots associated with this task. Any updates?

Frankly, I have no idea. @Pginer-WMF do you remember which design this task refers to?

Old tipsy tooltips were white with a light blue border. At that time, there were designs for tooltips to make them more aligned with the design guidelines (with a solid bevel at the bottom) and I saw them supported in places like Flow. After OOUI transition, I'm not sure those are still available.

In conclusion, if tipsy tooltips look like the ones below, this task can be definitely closed:

I also recall some discussions about the effect of tooltips and performance during the Media Viewer project. So it is possible that no tipsy at all was finally used (using default browser tooltips), making the styling of tipsy no longer relevant for the project. If that is true, we can also close the task.

MediaViewer uses the default tipsy style. Most, but not all, tooltips were eventually removed.

Thanks @Tgr. I added the screenshot in the ticket description so that the ticket can be better understood at a glance.

Gotcha. We'll keep this open if you don't mind. cc @Volker_E

There's an approach currently used in Blueprint skin, on a skin level:

"ResourceModuleSkinStyles": {
	"blueprint": {
		"jquery.tipsy": [
			"skinStyles/tipsy.original.less",
			"skinStyles/tipsy.override.less"
		]
	}
}

I'm not very happy with the code of jquery.tipsy, it's pretty outdated, but seems to work for all different browsers and has been evaluated before. Alternative would be qTip2.

Just for my better understanding: On which level do we want customization be available?

Do we need customization?

There is T69500 if you want an overview of problems with tipsy. For MultimediaViewer the main headache was that tooltips defined to show on hover get stuck if the hover target area gets hidden while they are visible (very annoying when you have a tooltip on your close button). Also positioning near screen edges is not very intelligent, and worse in RTL languages (that might be some kind of conflict between tipsy and cssjanus; it was easier to work around than to track down.)

@violetto As far as I've understood that task, there are two problems addressed (please correct me):

1. Tooltips are currently not following Pau's design
2. Tooltip design should be more easily customizable

Because with werdna/prtxsna's approach from Blueprint we can at least assure on a skin level CSS customization of the tooltips

Trying to understand the reasons why we need tooltips to be more easily customizable

@violetto @MingleTerminator Well, we're leaving most of the interface somehow customizable, right? Therefore my question on which (technical) level possible customization should be able to take place.

I'm not sure what the context is (are you working on UI standardization?) but adding styles to tipsy might not be worth the effort. For MediaViewer this is a fairly minor problem, and in general reviewing the OOUI tooltip widget, improving it if neededand providing a migration guide might be a better use of time. Frontend is supposed to use OOUI these days; tipsy is not terribly well written and problematic for all but the simplest use cases and we have a limited ability to change it (since we don't want to fork it); OOUI looks reasonably similar to the mockups and seems good at handling edge cases (e.g. making its contents scrollable when there is not enough place) and is well-supported and actively developed so it makes sense to standardize on that, IMO.

Mass-removing the Multimedia tag from MediaViewer tasks, as this is now being worked on by the Reading department, not Editing's Multimedia team.

Change 516534 had a related patch set uploaded (by Simon04; owner: Simon04):
[mediawiki/extensions/MultimediaViewer@master] Remove most uses of jquery.tipsy in MediaViewer

https://gerrit.wikimedia.org/r/516534

The above patch switches to browser rendering

e.g.

Given the direction in T312899: Implement accessible tooltips in Vector 2022 it seems like a good change to make on the long term for the greater good of our ecosystem.
I'd also like to remove jquery.tipsy and Wikibase and MMV are the only blockers: https://codesearch.wmcloud.org/deployed/?q=jquery.tipsy

Is there any important reason to retain the existing functionality in MultimediaViewer? If not I'll look to merge this by Thursday.

Change 516534 merged by jenkins-bot:

[mediawiki/extensions/MultimediaViewer@master] Remove most uses of jquery.tipsy in MediaViewer

https://gerrit.wikimedia.org/r/516534

There is one more use remaining, in the "TipsyDialog" component shown on a file page on the next visit after the user has disabled Media Viewer:

Change 915851 had a related patch set uploaded (by Jdlrobson; author: Jdlrobson):

[mediawiki/extensions/MultimediaViewer@master] Remove jquery.tipsy and use OO.ui instead

https://gerrit.wikimedia.org/r/915851

Looks like an improvement but I'm having some issues with the placement. @matmarex, any ideas what I'm doing wrong with OO.ui.PopupWidget on https://gerrit.wikimedia.org/r/c/mediawiki/extensions/MultimediaViewer/+/915851 ? :)

Change 915851 merged by jenkins-bot:

[mediawiki/extensions/MultimediaViewer@master] Remove jquery.tipsy and use OO.ui instead

https://gerrit.wikimedia.org/r/915851

After the changes (with fixes to the PopupWidget placement):