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)

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)