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/%28%CE%B5,_%CE%B4%29-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%2Cmediawiki&only=scripts&skin=vector&version=3hR%2F0Nym:4:681), <anonymous>:102:812)\n at HTMLUListElement.opt.complete (https://en.wikipedia.org/w/load.php?debug=false&lang=en&modules=jquery%2Cmediawiki&only=scripts&skin=vector&version=3hR%2F0Nym:110:60)\n at fire (https://en.wikipedia.org/w/load.php?debug=false&lang=en&modules=jquery%2Cmediawiki&only=scripts&skin=vector&version=3hR%2F0Nym:45:124)\n at Object.self.fireWith [as resolveWith] (https://en.wikipedia.org/w/load.php?debug=false&lang=en&modules=jquery%2Cmediawiki&only=scripts&skin=vector&version=3hR%2F0Nym:46:431)\n at Animation.tick (https://en.wikipedia.org/w/load.php?debug=false&lang=en&modules=jquery%2Cmediawiki&only=scripts&skin=vector&version=3hR%2F0Nym:107:719)\n at jQuery.fx.tick (https://en.wikipedia.org/w/load.php?debug=false&lang=en&modules=jquery%2Cmediawiki&only=scripts&skin=vector&version=3hR%2F0Nym:112:760)"}}
This edit request has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.
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.
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 edit request has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.
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.
These are significantly more changes than I had anticipated when looking at this again today.. This is gonna take me more than 15 minutes to review, so please be patient as I try to take another look later this week. —TheDJ (talk • contribs) 16:12, 29 January 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 (talk • contribs) 16:43, 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 Novikoff02:33, 3 February 2019 (UTC)[reply]
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]
This edit request has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.
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.
This diff shows how the JS code on this page should be changed.
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. — xaosfluxTalk19:50, 15 July 2019 (UTC)[reply]
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]
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.
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]
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]
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:
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
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 Rextalk16: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
consttopOffset=-$('#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>`);
#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]
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]
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]
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
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".
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:
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]
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]
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.
Done --Redrose64 (talk) 22:15, 19 April 2012 (UTC)
okay — Martin (MSGJ · talk) 17:19, 11 June 2012 (UTC)
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)
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)
Accessibility for Reading (Vector 2022)) by using the 
