MediaWiki talk:Gadget-ReferenceTooltips.js

Latest comment: 5 months ago by Pppery in topic Update request 14 July 2024
Note: There is also discussion at User talk:Yair rand/ReferenceTooltips

Sync

edit

Could an admin please re-copy User:Yair rand/ReferenceTooltips.js to this page to add the recent bug fix? Thanks. --Yair rand (talk) 19:19, 4 April 2012 (UTC)Reply

Done.  Sandstein  17:27, 11 April 2012 (UTC)Reply

Could someone synchronize the pages again, please? --Yair rand (talk) 21:35, 19 April 2012 (UTC)Reply

  Done --Redrose64 (talk) 22:15, 19 April 2012 (UTC)Reply
Thank you. --Yair rand (talk) 22:25, 19 April 2012 (UTC)Reply
I've made some changes to User:Yair rand/ReferenceTooltips.js and User:Yair rand/ReferenceTooltips.css, to add a delay to the tooltip, functionality for touch screens, and a settings menu including options to change both and a disable button. Could someone please copy them over MediaWiki:Gadget-ReferenceTooltips.js and MediaWiki:Gadget-ReferenceTooltips.css, respectively? Thanks. --Yair rand (talk) 03:05, 11 June 2012 (UTC)Reply
  okay — Martin (MSGJ · talk) 17:19, 11 June 2012 (UTC)Reply

Hm

edit

Where is element #footer-places? Also, disabling of this gadget isn't work (Firefox 13). Saint Johann (ru) 15:48, 17 June 2012 (UTC)Reply

#footer-places is at the bottom of the page, holding the "Privacy policy", "About Wikipedia", and "Disclaimers" links, but only in Vector skin. I had forgotten to also include the equivalent elements for other skins. There was also another bug in working with other skins that I had missed. Now that both bugs, as well as the problem in Firefox, are fixed, could an admin please copy User:Yair rand/ReferenceTooltips.js and User:Yair rand/ReferenceTooltips.css over MediaWiki:Gadget-ReferenceTooltips.js and MediaWiki:Gadget-ReferenceTooltips.css again? (Sorry for having to ask so frequently.) --Yair rand (talk) 19:52, 17 June 2012 (UTC)Reply
  Done --Redrose64 (talk) 20:08, 17 June 2012 (UTC)Reply
Thanks. --Yair rand (talk) 20:13, 17 June 2012 (UTC)Reply
MediaWiki:Gadget-ReferenceTooltips.js and MediaWiki:Gadget-ReferenceTooltips.css need yet another sync, to fix this bug. Thanks. --Yair rand (talk) 21:06, 2 July 2012 (UTC)Reply
  Done --Redrose64 (talk) 22:33, 2 July 2012 (UTC)Reply
Sorry, I made a mistake in the edit to User:Yair rand/ReferenceTooltips.js. Could someone please re-sync the pages to fix this? Sorry about that. --Yair rand (talk) 00:03, 3 July 2012 (UTC)Reply
Done. Thank you. Rjd0060 (talk) 02:29, 3 July 2012 (UTC)Reply
There was a bug with the script working with iPads, hopefully the recent change to User:Yair rand/ReferenceTooltips.js fixes it. Could an admin sync the gadget page again, please? --Yair rand (talk) 04:56, 5 July 2012 (UTC)Reply
  Done --Redrose64 (talk) 10:26, 5 July 2012 (UTC)Reply
Could someone please sync this with User:Yair rand/ReferenceTooltips.js again? Thanks. --Yair rand (talk) 23:40, 21 August 2012 (UTC)Reply
  Done --Redrose64 (talk) 16:13, 22 August 2012 (UTC)Reply

Protected edit request on 11 July 2014

edit

Hello!

Could someone apply these changes to the script? Helder.wiki 21:22, 11 July 2014 (UTC)Reply

  Done Ruslik_Zero 19:43, 18 July 2014 (UTC)Reply

NotFoundError

edit

This gadget causes the error: NotFoundError: Node was not found. See phab:T109486. Helder 17:54, 18 August 2015 (UTC)Reply

@He7d3r: Checked Chrome/FF/IE on Window 7, could not reproduce. What browser were you using? --Yair rand (talk) 18:09, 18 August 2015 (UTC)Reply

I was using Iceweasel 38.2.0. On Google Chrome it is a little more verbose:

{
	"errorMessage": "Uncaught NotFoundError: Failed to execute 'removeChild' on 'Node': The node to be removed is not a child of this node.",
	"url": "https://en.wikipedia.org/wiki/(ε,_δ)-definition_of_limit",
	"lineNumber": 102,
	"columnNumber": 812,
	"errorObject": {
		"stack": "Error: Failed to execute 'removeChild' on 'Node': The node to be removed is not a child of this node.\n    at Error (native)\n    at HTMLUListElement.eval (eval at <anonymous> (https://en.wikipedia.org/w/load.php?debug=false&lang=en&modules=jquery,mediawiki&only=scripts&skin=vector&version=3hR/0Nym:4:681), <anonymous>:102:812)\n    at HTMLUListElement.opt.complete (https://en.wikipedia.org/w/load.php?debug=false&lang=en&modules=jquery,mediawiki&only=scripts&skin=vector&version=3hR/0Nym:110:60)\n    at fire (https://en.wikipedia.org/w/load.php?debug=false&lang=en&modules=jquery,mediawiki&only=scripts&skin=vector&version=3hR/0Nym:45:124)\n    at Object.self.fireWith [as resolveWith] (https://en.wikipedia.org/w/load.php?debug=false&lang=en&modules=jquery,mediawiki&only=scripts&skin=vector&version=3hR/0Nym:46:431)\n    at Animation.tick (https://en.wikipedia.org/w/load.php?debug=false&lang=en&modules=jquery,mediawiki&only=scripts&skin=vector&version=3hR/0Nym:107:719)\n    at jQuery.fx.tick (https://en.wikipedia.org/w/load.php?debug=false&lang=en&modules=jquery,mediawiki&only=scripts&skin=vector&version=3hR/0Nym:112:760)"
	}
}

Helder 18:55, 18 August 2015 (UTC)Reply

PS: it also happens when I'm not logged in. Helder 18:56, 18 August 2015 (UTC)Reply

Formatting by stylesheet

edit

To allow users to use custom styling of the highlighted reference, please replace:

  1. h.style.border = ""$( h ).removeClass("RTTarget")
  2. h.style.border = "#080086 2px solid"$( h ).addClass("RTTarget")

Note that this class is already defined in MediaWiki:Gadget-ReferenceTooltips.css. Petr Matas 14:44, 9 January 2016 (UTC)Reply

Hm, this was actually in the changes that I made to the version in my userspace, but I never ended up requesting a merge, and I can't remember why... Eh. --Yair rand (talk) 04:08, 11 January 2016 (UTC)Reply
  DoneMr. Stradivarius ♪ talk ♪ 07:25, 13 January 2016 (UTC)Reply

Tooltip is not shown if the reference is above the visible area

edit

Problem description: Open Quantum state#Ref-14. Reference 14 contains a link to reference 1. If you hover on the link to reference 1, no tooltip is shown, although reference 1 is off-screen (above the visible area). This is because the check for the reference being below the visible area is implemented, but above is not.

Fix: Please replace

if( !isTouchscreen && ( window.pageYOffset || document.documentElement.scrollTop || document.body.scrollTop || 0 )   $(window).height() > $( h ).offset().top   h.offsetHeight ) {

with

var windowTop = window.pageYOffset || document.documentElement.scrollTop || document.body.scrollTop || 0;
if( !isTouchscreen && windowTop < $( h ).offset().top && windowTop   $(window).height() > $( h ).offset().top   h.offsetHeight ) {

Petr Matas 13:20, 13 January 2016 (UTC)Reply

Probably easier if you dump the whole code in a sandbox next time, so I can just copy/paste. But   Done — Martin (MSGJ · talk) 09:25, 14 January 2016 (UTC)Reply
Ok, thanks :) Petr Matas 12:00, 14 January 2016 (UTC)Reply

Sync request

edit

Could an admin please merge these changes? Changes include:

  • Nested references can have tooltips.
  • Links inside reference tooltips are compatible with hovercards, for those who have the beta feature enabled.
  • Messages are grouped at the top and use mw.msg, for easier localization when imported to other language projects.
  • Reference Tooltips now runs in the Draft namespace.
  • Minor general cleanup.

--Yair rand (talk) 23:04, 14 January 2016 (UTC)Reply

  Done — Martin (MSGJ · talk) 09:24, 15 January 2016 (UTC)Reply

jQuery 3

edit

This script contains the lines

$(this)[ isTouchscreen ? 'click' : 'hover' ](function( e ){

and

isTouchscreen || $(tooltipNode).hover(show, hide);

which cause the following warning in the console:

JQMIGRATE: jQuery.fn.hover() is deprecated

Helder 22:54, 7 October 2017 (UTC)Reply

  Not done: it's not clear what changes you want to be made. Please mention the specific changes in a "change X to Y" format. — Martin (MSGJ · talk) 07:13, 27 October 2017 (UTC)Reply
This was resolved by KrinkleTheDJ (talkcontribs) 12:38, 1 November 2017 (UTC)Reply

Update suggestion

edit
 

Hello! I would like to suggest to update to the new version of this gadget I've presented at mw:Topic:Ueqlcc482l9yw8gv. There are numerous bugfixes and added features like Harvard-style citations support. Tooltip style & animations are also updated to be consistent with Page Previews' style & animations. It has been tested thoroughly and used in Russian Wikipedia for several months with no complaints.

Jack who built the house (talk) 11:18, 29 December 2018 (UTC)Reply

  DoneTheDJ (talkcontribs) 16:40, 2 February 2019 (UTC)Reply
P.S. you might want to get rid of the cookies in favor of LocalStorage. That helps reduce request size and we won't be bothering the WMF servers with that info any longer. —TheDJ (talkcontribs) 16:43, 2 February 2019 (UTC)Reply
Per phab:T179415 for logged in users it should really be replaced with toggling the gadget in preferences. Galobtter (pingó mió) 07:35, 8 February 2019 (UTC)Reply
@TheDJ: Thanks! I forgot: jquery.client and mediawiki.notify dependencies are needed too. Jack who built the house (talk) 19:52, 2 February 2019 (UTC)Reply
  • Hello Jack, nice to see you here. My two cents: since I'm sill using Opera 12.18, I was afraid that your new version would not work for me, as for some unknown reason on ruwiki it didn't, but oddly enough that's not the case now, it does work. (Except for the absence of icon in the upper right corner, but that's bearable.) So take my congrats on the success. — Mike Novikoff 02:33, 3 February 2019 (UTC)Reply

Mechanics

edit
@Jack who built the house: to be clear, is this ready to go and you would like us to replace:
? — xaosflux Talk 13:52, 9 January 2019 (UTC)Reply
Yes, that's correct. Right now I have both of these files in my common.js, and it's working properly. Jack who built the house (talk) 14:18, 9 January 2019 (UTC)Reply
@Xaosflux. Jack who built the house (talk) 14:20, 9 January 2019 (UTC)Reply
@Xaosflux: Hello! Any updates? Jack who built the house (talk) 14:58, 11 January 2019 (UTC)Reply
edit

As reported here, this gadget's feature to show tooltips seems to make links with tooltips unclickable on touchscreen devices:

This is particularly inconvenient on navboxes, which uses {{navbar|mini=y}} to show the links on top left. Can this be fixed with a change to this JS? Nardog (talk) 09:50, 4 April 2019 (UTC)Reply

We also have this problem in Ukrainian Wiki after we updated Gadget:Reference Tooltips to the last version. I think it would be the best solution if the words “view this template”, “discuss…” and “edit…” became pressable after you click on vte. If anyone can fix the bug in this way, please do this! --Gzhegozh (talk) 12:35, 5 April 2019 (UTC)Reply
@TheDJ: I am sorry to bother you, but maybe you can help fix the problem? --Gzhegozh (talk) 15:45, 7 April 2019 (UTC)Reply

I fixed the issue together with another one, reported at en:Template talk:Harvard citation#Cosmetic issue: nested quotes.

Please update the gadget by moving the code from en:User:Jack who built the house/Gadget-referenceTooltips.js to here.

@Gzhegozh: you can update in your wiki too. Jack who built the house (talk) 14:00, 10 May 2019 (UTC)Reply

@Jack who built the house: just want to make sure that this is the change you are asking for: DIFF. — xaosflux Talk 19:25, 10 May 2019 (UTC)Reply
Yes, I only forgot the comment on top: // Source https://en.wikipedia.org/wiki/MediaWiki:Gadget-ReferenceTooltips.js. Updated my code, now it's correct. Jack who built the house (talk) 19:32, 10 May 2019 (UTC)Reply
Xaosflux Jack who built the house (talk) 19:33, 10 May 2019 (UTC)Reply
  Done. ~Oshwah~(talk) (contribs) 10:21, 11 May 2019 (UTC)Reply

Add support for directionality of ref tags

edit

Since May 2018 we have the ability to use the dir attribute in the <ref> tags to specify the directionality of ref tags as right-to-left (RTL) or left-to-right (LTR). This is widely used in pages that cite both RTL and LTR sources, for example on Persian Wikipedia (fawiki, see example). Since the ReferenceTooltips code is used on many wikis, it is ideal to add support for directionality in its enwiki version so that all others who copy it would also benefit from it.

I have already implemented the solution into our copy on fawiki. Please incorporate it here too.

Happy to answer any questions (but please {{ping}} me). hujiTALK 14:47, 1 July 2019 (UTC)Reply

@Huji: (Presumably you did not mean to leave in the console.log there.) --Yair rand (talk) 16:40, 1 July 2019 (UTC)Reply
@Yair rand: correct; I updated the diff link above hujiTALK 16:46, 1 July 2019 (UTC)Reply
The structure of the surrounding code context appears to be substantially different in enwiki's version of this script; I'm not sure it would be a straightforward cut-and-paste. Writ Keeper  14:54, 2 July 2019 (UTC)Reply
  Not done this would need to be thoroughly tested here first, feel free to mock it up as a user script here on wiki and gain some testers. — xaosflux Talk 19:50, 15 July 2019 (UTC)Reply

Feature suggestion: support for book references

edit

The Cite extension has an experimental feature called book referencing. This feature allows editors to cite multiple parts of an already-cited source using the extends attribute. For instance, an editor could cite a book with the citation <ref name="Miller">E. Miller, ''The Sun'', (New York: Academic Press, 2005)</ref>, and then they could cite page 42 in that book with a second citation <ref extends="Miller">p. 42</ref>.

Continuing with the earlier example, currently when a user hovers over the "p. 42" sub-citation, the tooltip will just contain "p. 42" without the book name. That tooltip is not especially useful. It would be nice if this gadget could handle "book references" more naturally. That is, if a user hovers over a citation of the form <ref name="child" extends="parent">text</ref> attribute, it would be nice if the tooltip displayed the contents of both the parent and child citations. Note that book citations can only go one level deep (you cannot extend a citation that extends another citation), which should make the implementation more straightforward. Thank you for considering this suggestion! MtMNC (talk) 06:51, 2 November 2020 (UTC)Reply

The feature in Cite extension was experimental. The project was eventually abandoned unfortunately, see m:WMDE Technical Wishes/Book referencing. – SD0001 (talk) 07:23, 14 December 2021 (UTC)Reply

Change 2 strings

edit

As it turned out, it can be unclear to users what they are disabling/enabling. So please replace

	'rt-enable': 'Enable',
	'rt-disable': 'Disable',

with

	'rt-enable': 'Enable Reference Tooltips',
	'rt-disable': 'Disable Reference Tooltips',

Jack who built the house (talk) 20:43, 4 February 2024 (UTC)Reply

  Done * Pppery * it has begun... 21:34, 4 February 2024 (UTC)Reply

Update request 9 July 2024

edit

Please update the JS and CSS parts of the gadget:

Changes:

  • Respect the text size the user has in the "Appearance" section (Preferences → Beta features →   Accessibility for Reading (Vector 2022)) by using the --font-size-medium CSS variable and making the font size and several related properties relative (in em) instead of absolute (in px).
  • Encode several constants to calculate distances based on them instead of relying on magic numbers.
  • Use <a> element for the settings link instead of <div> as more semantically appropriate.
  • Use Codex design tokens in several places (box-shadow, icon size).
  • Fix the appearance of the tooltip tail (anchor) in Blink browsers in Windows on bigger system font sizes.

Ping me if there are any problems. Jack who built the house (talk) 08:40, 9 July 2024 (UTC)Reply

  Done * Pppery * it has begun... 16:15, 9 July 2024 (UTC)Reply
This change breaks font size on Vector 2010. Now my reference tooltip font is larger than the article size. Traumnovelle (talk) 04:41, 10 July 2024 (UTC)Reply
cc JWBTHNovem Linguae (talk) 04:47, 10 July 2024 (UTC)Reply
Thanks for the report. I guess we'll have to hardcode the font size for Vector 2010 and Monobook as well. Jack who built the house (talk) 05:53, 10 July 2024 (UTC)Reply
This is extremely broken for me (using Monobook). Font size is now significantly larger than body copy. (I think it was previously smaller? Or at least the same size.) Footnote boxes are the same width as before but now much less text fits on each line, so the footnote ends up taking 1.5x or more vertical space, which both makes it less legible per se and also covers an excessive amount of the page below. Long footnotes are much less likely to fit on screen. Some footnotes with wider content get cut off horizontally. –jacobolus (t) 06:50, 10 July 2024 (UTC)Reply
I think it was previously smaller?
It was 13px – a bit bigger than the font size in Monobook.
Some footnotes with wider content get cut off horizontally.
Can you give an example? Jack who built the house (talk) 06:54, 10 July 2024 (UTC)Reply
Here's an example, Lemniscate elliptic functions#cite note-73. Arguably this is an absurdly big formula to have in a footnote (without any breakpoints), and it's possible it spilled out of the width of a popup box even before. But there are at least some number of similar examples in other pages across the wiki. –jacobolus (t) 14:10, 10 July 2024 (UTC)Reply
That's very helpful, thanks. I'll make the tooltip scroll horizontally instead of having the formula spill out. Jack who built the house (talk) 14:31, 10 July 2024 (UTC)Reply
The width of footnote boxes should also probably be specified relative to the font size, to some consistent number of ems (25 or so? not sure). Then there can be somewhat consistent expectation for authors that readers' view of a popup note will be relatively close to an author's own view. –jacobolus (t) 15:01, 10 July 2024 (UTC)Reply
That too, yeah. Jack who built the house (talk) 15:02, 10 July 2024 (UTC)Reply
Like this:
 
Jack who built the house (talk) 11:27, 12 July 2024 (UTC)Reply
I assume this is to be fixed by appending the WindowManager to OO.ui.getTeleportTarget() instead of <body>? (See phab:T348286.) Nardog (talk) 06:55, 10 July 2024 (UTC)Reply
Oh right, using #mw-teleport-target could actually be a better idea than hardcoding anything (note that reference tooltips are not OOUI-based).
Let's see. Before the change the tooltip was 13px across all skins against 14px body size. We want to make it bigger where the body font size is bigger. #mw-teleport-target is:
  • strictly the body size (14px, 16px, or 20px) in Vector, Vector 2022, and Minerva
  • 14.44px against 15.2px body size in Timeless
  • 12.8px against 12.7px body size in Monobook
Here, I'm only afraid that making the tooltip smaller than the body text in Monobook wouldn't be a good idea as this would be hard to read. So, we may still hardcode the size for Monobook as a special case. An alternative would be to have the tooltip font size just equal to the body font size, like in Page Previews and Reference Previews:
 
Jack who built the house (talk) 07:25, 10 July 2024 (UTC)Reply
Couldn't you just wrap it in <ol class="references">? Nardog (talk) 07:33, 10 July 2024 (UTC)Reply
It would just give font-size: 90%; to the root font size and bring side effects with it. Jack who built the house (talk) 07:40, 10 July 2024 (UTC)Reply
What side effects? Aren't we trying to restore the previous font size (except relative) here? Nardog (talk) 08:13, 10 July 2024 (UTC)Reply
Side effects of the <ol> element as well as any styles applied to ol.references. By "root font size" I mean 1rem, so it's not relative to the body font size. Jack who built the house (talk) 08:20, 10 July 2024 (UTC)Reply
How about applying font-size: 90%; (or calc(... * 0.9) or whatever) then? Nardog (talk) 08:26, 10 July 2024 (UTC)Reply
There is no problem with that (currently the coefficient is 13/14 to match the usual font size in Vector, 13px); the question is, relative to what. Jack who built the house (talk) 08:33, 10 July 2024 (UTC)Reply
The teleport target. Nardog (talk) 17:21, 10 July 2024 (UTC)Reply
Hm. There is a problem with #mw-teleport-target, and I can't yet figure out how to solve it. #mw-teleport-target is located at the end of the DOM and only has
	position: absolute;
	z-index: 450;
as styles. Which means its descendants will be positioned relative to the bottom of the screen, even if they have position: absolute. If I use position: fixed for a descendant, then its descendants will have fixed positioning relative to the page (which we don't need), even if they have position: absolute.
If #mw-teleport-target had
	top: 0;
	width: 100%;
that would probably work, but it doesn't. #mw-teleport-target seems to be intended for fixed-positioned elements like dialogs only. Jack who built the house (talk) 12:51, 11 July 2024 (UTC)Reply
@Matma Rex: Do you have a recommendation on where a script can insert tooltips so the font size etc. are the same as in the content body? Nardog (talk) 15:46, 11 July 2024 (UTC)Reply
I believe that #mw-teleport-target was intended exactly for this use case. (As noted below, access it using require( 'mediawiki.page.ready' ).teleportTarget.) It's used by both Codex and OOUI and is meant to be usable by anything else.
I haven't looked at how it's used in Codex, but at least OOUI manages to use it to position not just dialogs, but also e.g. dropdown menus (like those on Special:Log).
You're right though that the position has to be calculated relative to the bottom of the screen… (I see things like top: -2447.62px on those OOUI dropdowns, which is a bit silly). I would guess nobody noticed because those libraries have generic methods to position anything relative to anything else, and they coped with the weirdness automatically. You might want to file a Phab task (and CC people who worked on the feature: https://gerrit.wikimedia.org/r/c/mediawiki/core/ /945825), or you'll have to make your code cope with it too. Matma Rex talk 16:57, 11 July 2024 (UTC)Reply
Thanks for explaining. Apart from requiring negative offsets, it also has zero width which makes descendants shrink if they don't have explicitly set width, e.g. try
const topOffset = -$('#mw-teleport-target').offset().top   $(window).scrollTop();
$('#mw-teleport-target').append(`<div style="position: absolute; top: ${topOffset}px; background-color:yellow;">test test test</div>`);
So I'm afraid, unless you set width: max-content (which is a bit newer than Grade C browsers) together with max-width, you can't have descendants with variable width also. Jack who built the house (talk) 17:49, 11 July 2024 (UTC)Reply
You might want to file a Phab task (and CC people who worked on the feature: https://gerrit.wikimedia.org/r/c/mediawiki/core/ /945825)
https://phabricator.wikimedia.org/T369880 Jack who built the house (talk) 00:56, 12 July 2024 (UTC)Reply
#mw-teleport-target isn't served by HTML, so I assume you can't just expect it to be there but have to await something. Nardog (talk) 07:36, 10 July 2024 (UTC)Reply
https://phabricator.wikimedia.org/source/mediawiki/browse/master/resources/src/mediawiki.page.ready/ready.js
mw.loader.using('mediawiki.page.ready').then(function (require) {
	console.log(require('mediawiki.page.ready').teleportTarget);
});
works. Jack who built the house (talk) 07:44, 10 July 2024 (UTC)Reply
Also, two questions to @Jon (WMF): Is there a chance that CSS variables like --font-size-medium will land in skins other than Vector 2022 and Minerva? Is #mw-teleport-target reliable to be used by gadgets like this one (that seek the font size more or less equal to the body font size)? Jack who built the house (talk) 08:56, 10 July 2024 (UTC)Reply
https://doc.wikimedia.org/mediawiki-core/master/js/module-mediawiki.page.ready.html#.teleportTarget is in the documentation so is therefore stable.
The font size variables are not stable as they are not part of https://doc.wikimedia.org/codex/latest/design-tokens/overview.html yet. (FWIW officially CSS variables are currently not covered under the stable policy but that conversation is underway). Jon (WMF) (talk) 23:04, 10 July 2024 (UTC)Reply
Got it.
The font size variables are not stable as they are not part of https://doc.wikimedia.org/codex/latest/design-tokens/overview.html yet
Well, they are on https://doc.wikimedia.org/codex/latest/design-tokens/font.html#font-size. Jack who built the house (talk) 04:10, 11 July 2024 (UTC)Reply
Yes you are correct. They are part of Codex now. My bad! Thanks for correcting me. Jon (WMF) (talk) 16:03, 11 July 2024 (UTC)Reply
I think it would be fine to have the reference preview font size match the body font size if it's less work to compute. SWinxy (talk) 22:38, 10 July 2024 (UTC)Reply
I agree. Having footnote popups match body copy size would be totally fine. (With the proviso that the popup box width should be set using relative units so the width is about the same number of characters, as discussed a bit above.) –jacobolus (t) 00:01, 11 July 2024 (UTC)Reply
I think it would look awkward. At least harder to tell apart from body text. Why should it be made bigger? We who stayed on Vector didn't complain. 78.3.197.2 (talk) 19:40, 12 July 2024 (UTC)Reply
(Plus I don't want to sound like an old person but footnotes are smaller in physical books. 78.3.197.2 (talk) 19:45, 12 July 2024 (UTC))Reply
Disagree per what IP wrote. The old style was fine and I would like it restored. Traumnovelle (talk) 09:25, 13 July 2024 (UTC)Reply
Several thoughts:
  • Work to compute is secondary here, but there should be a rationale for smaller font from a design perspective.
  • Technically we don't have the current font size of Reference Tooltips in design tokens that we are recommended to use. Page Previews also use the default font size, 14px.
  • "I think it would look awkward. At least harder to tell apart from body text" – in theory, yes, but in practice, I think, the tooltip content is already well-isolated by border paddings shadow. My hypothesis is that you'll quickly get used to the body font size once you enable it. To test this hypothesis, you can add this
    .rt-overlay.rt-overlay {
    	font-size: var(--font-size-medium, 14px);
    }
    
    to your common.css and, after some time, say how it goes. I added it to mine.
  • "footnotes are smaller in physical books" – obviously WP:NOTPAPER, but if the argument goes "Footnotes are smaller in the reference section itself", the counterargument is "The reference in a tooltip is isolated and doesn't compete for space or attention with anything, so there is no reason to downsize it".
Jack who built the house (talk) 09:52, 14 July 2024 (UTC)Reply
in theory, yes, but in practice, I think, the tooltip content is already well-isolated by border paddings shadow
If the tooltip content is not enough isolated, we might add a bit more side padding to that end:
Increased font size increased padding Current look
 
 
More examples with the default text size set to "Small" in the "Appearance" section: current look, increased font size, increased font size increased padding. Jack who built the house (talk) 12:07, 14 July 2024 (UTC)Reply
The main reason to make the text in the popup slightly smaller would be to better fit in a narrow text column, since the popup box is narrower than typical skins have for paragraphs of body copy. If the popup used the same font size as the article body that would also be fine though, in my opinion. It shouldn't be larger though. –jacobolus (t) 14:33, 14 July 2024 (UTC)Reply
As I promised, the popup width in my updated version is relative to the font size anyway. Jack who built the house (talk) 14:45, 14 July 2024 (UTC)Reply
Footnote boxes are the same width as before but now much less text fits on each line
This actually made me think that probably we should also made the tooltip wider when the user opted for the large font size in Vector. Jack who built the house (talk) 06:57, 10 July 2024 (UTC)Reply
Do your updates fix the gadget on Vector 2010? Traumnovelle (talk) 09:26, 14 July 2024 (UTC)Reply
Yes, see #Update request 14 July 2024. Jack who built the house (talk) 09:34, 14 July 2024 (UTC)Reply

Update request 14 July 2024

edit

This update addresses user complaints voiced in MediaWiki talk:Gadget-ReferenceTooltips.js#Update request 9 July 2024 and includes other changes.

Please update the JS and CSS parts of the gadget:

Changes:

  • Make the font size in Vector 2010 and MonoBook the same as before the changes. (In the future, Vector 2010 font size should be fixed by placing the overlay inside #mw-teleport-target; see phab:T369880.)
  • Make the tooltip width relative to the font size.
  • Increase the height of the tooltip tail (anchor) by 1px (it's hard to resize it proportionately as with other values).
  • Make a horizontal scrollbar appear when the contents of the tooltip exceed the maximum width and can't be wrapped to the next line (example).
  • Make the script reusable by other wikis (and synchronizable across wikis). They can now load it from enwiki while setting their own settings and messages.
  • Rework the settings dialog: turn the enable/disable radio input into a checkbox, turn the "Cancel" button into a close button, reword the labels.
  • Replace a 404 image illustrating the footer link from an extension with a Commons file. It appears when the gadget is disabled from its settings.
  • Fix the page footer when the gadget is disabled from its settings. A new footer link to reenable the gadget was added each time wikipage.content hook fired on a page.
  • Remove old IE fix (IE is no longer supported by MediaWiki).
  • Do minor chores and code style fixes.

Jack who built the house (talk) 09:33, 14 July 2024 (UTC)Reply

  Done * Pppery * it has begun... 23:22, 15 July 2024 (UTC)Reply