Extension talk:Tooltip/Archive

Example Sites?
Any sites using this that we can have a look at? Thanks --Dr DBW 05:28, 10 September 2007 (UTC)
 * Our company internal wiki is using it. However, the site is behind a wirewall. I am not aware of any other sites using the extension. --Gri6507 13:02, 10 September 2007 (UTC)

Could this be somehow combined with glossary extension?
Idea: Tooltip combined with Glossary -extension Contents of glossary extensions tooltips are displayed in same way like tooltip extension. This way you don't have to place tooltip tags and text to every term because glossary extension could take care of that. ie. Glossary extensions searches for words which contains explanations in glossary page and contents of glossary page is shown in tooltip. ie. tag that glossary extension creates is replaced with tooltip tag.

--JuhaV 12:00, 14 November 2007 (UTC)


 * I'm not sure at which point the Glossary extension came around. However, that's not really important. What is important is that the Glossary extension seems to have a superset of the functionality of this extension, including the tag, albeit the implementation of the tooltip is different.
 * So, let me see if I understand your question. Are you trying to make this extension coexist with the Extension:Glossary? --Gri6507 12:44, 14 November 2007 (UTC)


 * What I really want to do is make glossary words searched in a same way that in glossary extension and tooltip open in a same kind of window like in tooltip extension . --JuhaV 06:31, 15 November 2007 (UTC)


 * I know most of these discussions are a bit old by now, but I too would very much like to see a wiki extensions combining the features of these two. As said above, the main advantage of the Glossary one would be automatizing the process so one wouldn't need to include the tooltip tags manually each time, while one obvious advantage of the Tooltip extension (specifically, the one I'm interested in) is its ability to allow HTML/wiki markup in the tooltip text. I'm hoping this would not be too hard to make, because I'm sure I wouldn't be able to do it. - 222.13.238.163 17:35, 18 July 2008 (UTC)

A few remarks
Nice extension, but I have a few remarks:
 * 1) It seems that the x-offset cannot be negative (the y-offset has no problem with that). I don't know why, looked into the code, but could not find a bug. Still, if I define a negative offset, it doesn't seem to work (increasing the subtracted value on line 76 of the extension code does work, however... beatsme!)
 * 2) I found that the tooltip will go nicely over the toolbox (in a standard mediawiki installation), but dive under the navigation pane! I fiddled with the z-index on line 52 of the extension code, but to no avail.
 * 3) Not all browsers support alpha transparency. IE6 for example, will show a solid blue background if you use the image that is suggested. This is of course not the fault of the extension, but maybe it should be mentioned anyway.

Regards, Lexw 09:48, 21 November 2007 (UTC)


 * I found the problem with the negative offset. It's in lines 107 and 108, where the x position is "corrected". I commented them out, and the probleme is gone. A typical example of a program that thinks that it knows better what I want than I do myself (hey, this is a joke, not an insult to the author!).
 * Instead of these two lines, I added two lines after the retrieval of the x and y coordinates of the tooltip. My code now reads (including line numbers, remove them if you want to use this):

106 //$output .= '           // if tooltip is too wide, shift left to be within parent'; 107 //$output .= '           if (posX + it.offsetWidth > img.offsetWidth) posX = img.offsetWidth - it.offsetWidth;'; 108 //$output .= '           if (posX < 0 ) posX = 0;'; 109 $output .= '            x = xstooltip_findPosX(img) + posX;'; 110 $output .= '            y = xstooltip_findPosY(img) + posY;'; 111 $output .= '            if (x < 0 ) x = 0;'; 112 $output .= '            if (x + it.offsetWidth > img.offsetParent.offsetWidth ) x = img.offsetParent.offsetWidth - it.offsetWidth - 1;'; 113 $output .= '            it.style.top = y + '. "'px'" .';'; 114 $output .= '            it.style.left = x + '. "'px'" .';';


 * As you can see, lines 107 and 108 are commented out. Lines 111 and 112 is what I have added. These two lines ensure that the tooltip is always entirely inside the article (not the window !). This also guarantees that there is no more diving below the navigation pane, since the navigation pane is not part of the article. So now, within the limits of the article, the tooltip can be as far away from the base tekst as the author wants!


 * Cheers, Lexw 12:49, 21 November 2007 (UTC)
 * Many thanks for your help! I have incorporated your changes and released v0.3.1 of the extension (now in SVN) --Gri6507 13:31, 21 November 2007 (UTC)


 * Paul, one more remark w.r.t. version 0.3.1 as you have coded it now. You have now placed the creation of the javascript and CSS in one long line in the php file. If the code would have been like this at the time I installed the extension, I would not have been able to debug and modify it. For humans it is now practically uncomprehensible, unless one disassembles the code to contain 1 statement per line again. For understandability, this is really not an improvement. Just my 2 cents. Regards, Lexw 14:21, 21 November 2007 (UTC)
 * P.S. Since you are now streaming to $output anyway, why not retain the layout (that is: use multiple lines)? What is the use of streaming if you only stream one (very long) line?
 * Thanks again for your feedback. I understand what you are getting at. Here is why I did this. A while ago, I was contacted by one of the admins of MediaWiki about the possibility of having SVN access. They were very willing to do so under one (somewhat humorous) condition - I would have to change the way I concatenated strings to make legible JavaScript code. That's why I am using the streaming approach. The reason I went to a single line approach is because for some reason, when I had newlines in the stream, the Wiki Parser would translate the first and last one into a  which of course screwed up JavaScript. If you know of a better way of doing this, please let me know --Gri6507 21:36, 21 November 2007 (UTC)
 * If the wiki parser contains a bug with newlines in a stream I have no clue how to get around it. But why the heck wouldn't you be allowed to concatenate strings the way you originally did? It is valid php code! This is really a very strange story... Lexw 22:29, 21 November 2007 (UTC)
 * As I understand it, it's not that this coding style is not allowed, it is just frowned upon. The reason I got is that it's very wasteful having to recreate the string in pieces every time the page is loaded. I wouldn't think this is an issue, but someone else did. --Gri6507 02:37, 26 November 2007 (UTC)
 * Hmmm, I agree with that someone else that it's wasteful (to some extend), but I agree with you that it shouldn't be a real issue. And I would certainly think that if they prefer streaming, the wiki parser should be bugfree, instead of ruining the stream... But okay, the reasoning behind your current syntax is clear to me now, let's close this issue. Regards, Lexw 08:26, 26 November 2007 (UTC)

A Small Bug
Hi, I think I've discovered a minor bug in the latest 0.4 release. If I use the new parser function syntax I get an unwanted paragraph break inserted before the body text. It works fine with the tag-style syntax.

I'm using Firefox 2.0.0.8 and MediaWiki 1.11.0 in case this makes a difference.

Eclecticdave 01:15, 27 November 2007 (UTC)


 * This is reproducible behaviour, the browser makes no difference, the wiki version might be a difference. I have 1.11.0 too, and I see the same thing. The reason why I say that the wiki version might make a difference, is that if I look at the resulting HTML code I see a paragraph closing tag being placed right in front of the tooltip. As far as I understand the extension (which is not to the full 100%, I admit) this is coming out of the wiki parser, not out of the extension itself. No idea whether this can be suppressed, and if so, how.
 * Lexw 08:48, 27 November 2007 (UTC)
 * I think this is another case of the wiki parser trying to be a bit too ambitious. I have released v0.4.1 to address this issue. Please make sure to read the Usage Instructions before testing this because they have changed. --Gri6507 13:55, 27 November 2007 (UTC)
 * Yup, seems to work now: either tag syntax, parser syntax or template syntax: the page looks correct. Well done, thanks! Lexw 15:17, 27 November 2007 (UTC)
 * Sorry, still doesn't work for me: When I try parser syntax or template syntax on this version, I get Javascript errors. On investigation it looks like the Javascript in the output is being re-parsed and the empty strings are being replaced with  and  ! :-)
 * Eclecticdave 01:05, 28 November 2007 (UTC)
 * The parser syntax on its own will not work. You have to use the template (which in turn uses a combination of the tag and the parser) to get the correct output. What is the contents of your template? How are you you calling the template? Is that call the only use of the extension on the entire page? --Gri6507 03:02, 28 November 2007 (UTC)
 * As far as I can tell the template definition is exactly as in the Usage instructions. I've put together a test page and in doing so I think I've found a clue!  The page as it stands fails to work, but take off the    from the last sentence and both tooltips work!  (login as guest/hello if you want to try this for yourself)
 * Also note the need for the middle sentence - if it's removed (leaving a blank line) I don't get a paragraph break between the other two sentences.
 * Thanks - Eclecticdave 12:06, 28 November 2007 (UTC)
 * Strange enough, Dave, if I go to the page that you link to, neither one of the tooltips seem to work... On the other hand, for me they seemed to work where they didn't for you. So what's going on? Lexw 13:25, 28 November 2007 (UTC)


 * Gri6507, what do you mean with "The parser syntax on its own will not work. You have to use the template (which in turn uses a combination of the tag and the parser) to get the correct output"? I thought this combination in the template was a mistake, removed the part, so that only the pure parser syntax remains, and all works well. Also if I entirely skip the template syntax and use the parser syntax directly on my pages. Note that I also "corrected" this on the extension page: here, maybe this has to be reverted? But then: why does it work for me? Lexw 13:32, 28 November 2007 (UTC)
 * That did it! - I put the back into the template and it makes it work for me - plus I no longer need the middle sentence to 'fix' the paragraph break :-)
 * I've updated my test page - Lexw, what do you see now?
 * Eclecticdave 16:14, 28 November 2007 (UTC)
 * I see the first sentence (template style) work, but the second (tag style) not. I see the plain text: " This is the tooltip! ", as if no parsing of the tags is done at all. Lexw 19:35, 28 November 2007 (UTC)
 * That's OK, that's what you should be seeing - there's a   around the second one!
 * Sorry, I think I've confused you (I have a knack of doing that to people ;-) - When you first visited the page you should indeed have found it broken - this was deliberate. The idea was that removing the    tags from the tag-style tooltip made both work.  That's now unnecessary since I've modified the template.
 * I think I now understand how/why this works - if there are only parser-style tooltips on the page it breaks, because the Javascript gets inserted along with first one, but it gets parsed as wikitext and mangled. However include at least one tag-style tooltip on the page and the Javascript gets included with this one and doesn't get mangled.  Which is the point of putting an empty tag-style tooltip in the template.
 * Is there any chance this explains the results you're getting?
 * Eclecticdave 22:58, 28 November 2007 (UTC)
 * I have been thinking into the same direction, but it doesn't make sense with the results as I get them. I can simply leave the tags out of the template, and the whole thing still works. I can also directly put the parser-style tooltip on a page, and it works. That's also the reason why I "corrected" the template example on the extension page (which I will revert, by the way, and add a note to it). Maybe that Paul, the author, can explain why you and I get different results. Lexw 08:19, 29 November 2007 (UTC)


 * Ok, I went away and did a bit of research, trying to figure out how these extension things work. I think I've come up with a better solution, which hopefully should work more reliably ;-)
 * The root of the problem is that the CSS and Javascript is included in the body text where it is subject to being mangled (sometimes at least). IMHO the proper place for this code is in .  The way to put it there is to pass the code to $wgOut->addScript.
 * So here's a patch to do this ... once applied the template can be dispensed with - the parser-style syntax can be inserted directly into the page (well, it works for me anyway ...)
 * Eclecticdave 00:27, 30 November 2007 (UTC)

Index: Tooltip.php

=
====================================================== --- Tooltip.php	(revision 27956) +++ Tooltip.php	(working copy) @@ -10,9 +10,16 @@ ); function wfToolTipExtension { -   global $wgParser; -    $wgParser->setHook( "tooltip", "renderToolTip" ); -    $wgParser->setFunctionHook( 'tooltip', 'wfTooltipParserFunction_Render' ); +  global $wgParser; +	global $wgOut; + +	$output .= <<< END +.xstooltip{visibility: hidden;position: absolute;top: 0;left: 0;z-index: 2;font: normal 8pt sans-serif;padding: 3px;border: solid 1px;background-repeat: repeat;background-image: url($wgScriptPath/images/ttbg.png);} function xstooltip_findPosX(obj){var curleft = 0;if (obj.offsetParent){while (obj.offsetParent){curleft += obj.offsetLeft;obj = obj.offsetParent;}}else if (obj.x)curleft += obj.x;return curleft - 200;}function xstooltip_findPosY(obj){var curtop = 0;if (obj.offsetParent){while (obj.offsetParent){curtop += obj.offsetTop;obj = obj.offsetParent;}}else if (obj.y)curtop+= obj.y;return curtop - 25}function xstooltip_show(tooltipId, parentId, posX, posY){it = document.getElementById(tooltipId);if (it.style.top ==  || it.style.top == 0){if (it.style.left ==  || it.style.left == 0){it.style.width = it.offsetWidth + 'px';it.style.height = it.offsetHeight + 'px';img = document.getElementById(parentId);x = xstooltip_findPosX(img) + posX;y = xstooltip_findPosY(img) + posY;if (x < 0 ) x = 0;if (x + it.offsetWidth > img.offsetParent.offsetWidth ) x = img.offsetParent.offsetWidth - it.offsetWidth - 1;it.style.top = y + 'px';it.style.left = x + 'px';}}it.style.visibility = 'visible';}function xstooltip_hide(id){it = document.getElementById(id);it.style.visibility = 'hidden';} +END; +	$wgOut->addScript($output); + + $wgParser->setHook( "tooltip", "renderToolTip" ); + $wgParser->setFunctionHook( 'tooltip', 'wfTooltipParserFunction_Render' ); } function wfTooltipParserFunction_Magic( &$magicWords, $langCode ) { @@ -52,23 +59,14 @@        }     } -    $output = ' '; +		$output = ""; -   if ($wgToolTip != 1) { -       // This code was borrowed from http://www.texsoft.it/index.php?%20m=sw.js.htmltooltip&c=software&l=it -       $output .= <<< END -.xstooltip{visibility: hidden;position: absolute;top: 0;left: 0;z-index: 2;font: normal 8pt sans-serif;padding: 3px;border: solid 1px;background-repeat: repeat;background-image: url($wgScriptPath/images/ttbg.png);} function xstooltip_findPosX(obj){var curleft = 0;if (obj.offsetParent){while (obj.offsetParent){curleft += obj.offsetLeft;obj = obj.offsetParent;}}else if (obj.x)curleft += obj.x;return curleft - 200;}function xstooltip_findPosY(obj){var curtop = 0;if (obj.offsetParent){while (obj.offsetParent){curtop += obj.offsetTop;obj = obj.offsetParent;}}else if (obj.y)curtop+= obj.y;return curtop - 25}function xstooltip_show(tooltipId, parentId, posX, posY){it = document.getElementById(tooltipId);if (it.style.top ==  || it.style.top == 0){if (it.style.left ==  || it.style.left == 0){it.style.width = it.offsetWidth + 'px';it.style.height = it.offsetHeight + 'px';img = document.getElementById(parentId);x = xstooltip_findPosX(img) + posX;y = xstooltip_findPosY(img) + posY;if (x < 0 ) x = 0;if (x + it.offsetWidth > img.offsetParent.offsetWidth ) x = img.offsetParent.offsetWidth - it.offsetWidth - 1;it.style.top = y + 'px';it.style.left = x + 'px';}}it.style.visibility = 'visible';}function xstooltip_hide(id){it = document.getElementById(id);it.style.visibility = 'hidden';} -END; -       $wgToolTip = 1; -   } -     if ($input != '') { $tooltipid = uniqid('tooltipid'); $parentid = uniqid('parentid'); -       $output .= " ". $parser->unstrip($parser->recursiveTagParse($input),$parser->mStripState). " "; +       $output = " ". $parser->unstrip($parser->recursiveTagParse($input),$parser->mStripState). " ";        $output .= "". $parser->unstrip($parser->recursiveTagParse($text),$parser->mStripState). " ";    } -    $output .= " "; return $output; }


 * Thanks for looking into it. I knew there had to be a better way to output javascript! I'll try this out on my setup tomorrow and if it works, which I'm sure it does, I'll upload it to SVN. Thanks again! --Gri6507 03:12, 30 November 2007 (UTC)
 * Hi Dave, I agree with you that javascripts should be in the section. I had already seen this, but unlike you, I did not come to the idea to investigate whether it is possible to put it there. I just assumed that it was inevitable that an extension puts it in the body. Furthermore, I also noticed, just like you, that there was a  too much at the end of the script (although it didn't seem to harm, unless you use a tooltip inside another span of course).
 * I implemented the changes that you proposed, but I don't see a difference in behaviour before or after the change (might be not too strange as I didn;t have problems before).
 * I do want to make some additions to your modification however. In order to have the alpha transparency work, the image must be found. And after your change, it wasn't anymore! In order to have that work again, I had to add a line "global $wgScriptPath;" inside the function wfToolTipExtension (right after "global $wgOut;").
 * Another point for improvement, addressed to Paul. The background of the tooltip and the font family are nicely defined in the style of the xstooltip class. The font color however, is defined in a font tag (old-fashioned HTML style!) outside the xstooltip class. This is not very consistent. Furhtermore, using font tags is deprecated layout practice, and should therefore be avoided. So let's define the font color in the style of the xstooltip class, right after the font family.
 * Another thing is, that the tooltip is imlemented as a , which causes (at least for me), strange linebreak behaviour: a tooltip seems to "eat" linebreaks. It does not if it is a span. With the div implementation, if I place two adjacent paragraphs (that is: two lines with a blank line between them) which each hold a tooltip, the result is that the two lines are placed right after eachother, as if they were not two separate paragraphs; the linebreak seems to be "eaten". If I change the tooltip implementation into a span however, this behaviour is gone, two lines with a blank line between them appear as two paragraphs. I figured that this is caused by the fact that if the wiki parser sees a blank line after a div, it does not place a new paragraph tag (it probably thinks that it's not necessary, which is in this particular case wrong, because the div that it saw is from the tooltip text, not the base text), whereas when it sees a blank line after a span, it does put a paragraph tag!
 * Taking these two points together I think that the correct implementation of the tooltip should be:

$output = "". $parser->unstrip($parser->recursiveTagParse($input),$parser->mStripState). " "; $output .= "". $parser->unstrip($parser->recursiveTagParse($text),$parser->mStripState). " ";
 * As you can see I replaced the tooltip div with a span and left out the font color definition (which is now inside the xstooltip class).
 * The remark about font tags also holds for the font color of the base tekst: the font color is defined in the style of the span, not with font tags.
 * Cheers,
 * Lexw 09:08, 30 November 2007 (UTC)
 * Thanks - I'd missed the $wgScriptPath declaration - it works for me without it, but then I've got MW installed into the site root so the images directory is actually at /images ;-)
 * I agree with you wrt the font tags, and I can reproduce the linebreaks issue (that's a strange one, I could understand it if the div was the last thing on the line, but it still does it even when it isn't and, for me at least, only when two adjacent paragraphs both have tooltip's).
 * I can't test your changes at the mo (I'm writing this at work), I'll have a go tonight.
 * Cheers, Eclecticdave 12:57, 30 November 2007 (UTC)
 * Yep, checks out OK for me. Eclecticdave 01:40, 1 December 2007 (UTC)


 * Many thanks for looking into this! I did not know about the addScript method. As an added bonus, using this function now allows for formatting the JavaScript in a human legible way :-). Anyways, all suggestions made in this thread have now been incorporated into v0.5 (in SVN now). Please check it out if you have a chance. Thanks again. --Gri6507 13:37, 3 December 2007 (UTC)
 * Yep, looks good - except for PHP warning reported below, I concur with Lexw that this fix somehow got missed.
 * Thanks, Eclecticdave 15:31, 4 December 2007 (UTC)

PHP warning
If you set error logging on, you'll see the next PHP warning: Warning: Call-time pass-by-reference has been deprecated - argument passed by value; If you would like to pass it by reference, modify the declaration of [runtime function name]. If you would like to enable call-time pass-by-reference, you can set allow_call_time_pass_reference to true in your INI file. However, future versions may not support this any longer. in /srv/www/htdocs/wiki/extensions/Tooltip/Tooltip.php on line 28 Since this is a warning, not an error, it is in the current version not serious, but as it suggests its may cause problems in future versions. Also, because this warning is generated every time that a page is loaded, it is flooding the logfiles, which is very annoying. I think the call should be changed. Lexw 13:40, 28 November 2007 (UTC)
 * It looks like all that's needed here is to search for the call to renderToolTip in wfTooltipParserFunction_Render and remove the ampersand from the last parameter ($parser).
 * Eclecticdave 01:02, 2 December 2007 (UTC)
 * Fixed in version 0.5 (now in SVN) --Gri6507 13:37, 3 December 2007 (UTC)
 * Hate to say it, but it isn't. Lexw 08:37, 4 December 2007 (UTC)
 * I concur, FWIW the line that needs to be fixed is line 99 in this version. Eclecticdave 15:46, 4 December 2007 (UTC)
 * My bad. How about now (v0.5.1)? --Gri6507 18:38, 5 December 2007 (UTC)
 * Yep, better now. Lexw 21:35, 5 December 2007 (UTC)

Some more nitpicking
Version 0.5.1 seems to work fine, afaiac it might almost be the final version, but I have a few minor remarks. These really fall into the category "nitpicking", but I still want to share them with you. So far for the nitpicking. All in all it's a very nice extension. Well done, Paul! Lexw 08:26, 7 December 2007 (UTC)
 * 1) Line 57 is lacking a semicolon at the end. This has no real functional impact as javascript is tolerant with that (as long as you have only one statement per line, but still... I'm a bit of a language purist).
 * 2) I changed the returnvalue on the same line from 'curtop - 25' to 'curtop - 19' which results imho in a somewhat nicer vertical placement (just one line below the basetext), but this is of course pure personal taste, and also dependent on the default font that is used (which in turn can be dependent on the user's personal settings).
 * 3) On line 28, the tooltip border is defined as 'border: solid 1px', but the color seems to be white by default (same as the text?), which is almost invisible on a white background. Again: this might be dependent on the default style or the user's personal settings. So I changed that one to 'border: solid 1px black'.
 * 4) On line 27, the tooltip padding is defined as 'padding: 3px', but I think the text is not centered nicely inside the tooltip box. There seems to be almost no padding to the left side and also vertically it's a bit asymmetrical. After a bit of trial-and-error I found that 'padding: 3px 0px 0px 8px;' gives a result which is almost symmetrical. (The strange thing is that according to all documentation that I read the padding is defined in the order top-right-bottom-left, but if I set e.g. the top padding to 30, it is still divided almost evenly over the top and bottom padding. But I don't see that the text is defined to be vertically centered, so it's totally unclear to me where this behaviour comes from. But then, I'm no CSS expert.)


 * Well, as long as we're nitpicking :-) ... I added a 'max-width:400px' to the CSS - which IMHO makes tooltips with more than a few words look better.
 * Eclecticdave 10:41, 7 December 2007 (UTC)
 * Well, you could leave that to the user (creator) of the tooltip: simply adding HTML tags like  causes the tooltip to break into more than one line. And by doing it that way you don't limit the user to a max width beforehand. Just my 2 cents. Lexw 16:14, 7 December 2007 (UTC)

php warning
Great extension. Seems to be working fine, but at the top of each page containing tooltips I get "Notice: Undefined variable: output in c:\www\webapps\mediawiki\extensions\Tooltip.php at line 83 I'm running   * MediaWiki: 1.11.0    * PHP: 5.2.5 (apache2handler)    * MySQL: 5.0.45-community-nt-log    * Tooltip 0.5.1 and using Firefox 2.0.0.11. Any ideas? Thanks!


 * Thanks. This has been fixed in v 0.5.2. --Gri6507 12:58, 14 January 2008 (UTC)

Great- thanks!

Seems to clash with the Glossary extension
I have both the tooltip and the glossary extensions loaded. I've created the tooltip template as shown in the tooltip documentation. Now I get the following when a page contains an entry in my glossary: Proposed see tooltip are evaluated by the see tooltip monthly It should read: Proposed EC's are evaluated by the ECB monthly. EC's and ECB are entries in my glossary as used by the glossary extension. There appears to be some clash between the two extensions. Glossary version is 1.0 and tooltip is version 0.5.2. Other versions as above.


 * Good find! Apparently, the glossary extension also uses the tag for its syntax. This is what is causing the problem. Unfortunately, these types of clashes in extendible tags are very difficult to avoid from a developer point of view because there is no easy way to know which other extensions register which tags. From my point of view, since the glossary extension is called as such, it should have registered a tag. However, since it does not, one of the extensions has to change. Since I know there are a number of users who already enjoy the Tooltip extension, I would not want to permanently change anything in the extension. This means that you have to change it locally on your installation. Luckily, this is easy to do. In the example of the Glossary extension, you could simply change the following in Glossary.php


 * for


 * Of course, something similar could be done for the Tooltip extension as well, but, it's a bit more complicated since the Toolip extension supports both the tag and the parser syntax. --Gri6507 14:43, 25 January 2008 (UTC)

Thanks very much for the info. Sorted my problem! --Mitchelln 11:43, 26 January 2008 (UTC)

Empty paragraph still shows up
I'm still having problems with empty paragraph showing up at the end of the tooltip (after xstooltip_body span). The example can be seen here. I've already checked other templates in use and they do not have effect on the abscence/presence of empty paragraph. 01:42, 17 March 2008 (UTC)

Parser in Parser
Why this code doesnt works?

its return:

 "Imagem" is the localization to portuguese of "Image" --201.10.171.4 05:31, 28 March 2008 (UTC)

Stopped working with mediawiki 1.12.0?
I upgraded from 11.1 to 12.0 and my tooltips have stopped working. The text is highlighted in green, but when you hover over it the tooltip does not show. Anyone else seeing this? I've got tooltip 0.5.2.

Thanks! Mitchelln 10:40, 02 April 2008 (UTC)
 * Any update on this? It is definitely broken with mediawiki 1.12.0. Mitchelln 15:46, 01 May 2008 (UTC)


 * Thanks for the feedback. I have not tried the extension in 1.12 yet. Hopefully I'll get a chance to do so in the near future. In the mean time, if you or anyone else wants to give this a crack, please be my guest! --Gri6507 12:10, 2 May 2008 (UTC)
 * Thanks for the response. Any tips on where I should look in the code? Mitchelln 13:44, 02 May 2008 (UTC)


 * FWIW, I had a quick look at this last night ... it works if you use the tag style, but if you use the parser function method, the extension returns the same HTML (at least I can't see how it wouldn't), but the onmouseover and onmouseout parameters seem to go missing before it reaches the webpage.
 * Eclecticdave 13:14, 2 May 2008 (UTC)


 * I have checked the source of the page, and here is a typical output from the preprocessor, right after the non-working tooltip :


 * So apparently the template is not expanding correctly, but I haven't found out why yet. Possibly some recursion issue ?
 * Mr_Smoke 14:38, 16 May 2008 (UTC)

Tables
The tooltip tag and #tooltip parser function break when used inside tables. The resulting tooltip is skewed significantly off to the left and expands left to fit longer content, rather than expanding right. I think the issue is in the Javascript used to find the X position (below), though I don't know enough JS to figure out what... Any suggestions or ideas as to why this might occur?


 * MediaWiki: 1.11.1
 * PHP: 5.2.4 (apache2handler)
 * MySQL: 5.0.45-community-nt