MultiPopup, a customization for Tooltips for Opera

MultiPopup, a customization for Tooltips for Opera

Hi, I want to move the thread in wish list named 'nice titles' to here with a proper name, as Multipopup was constantly mistaken for nice titles, and this place is better suited to it.

Multipopup is a User Javascript which waits until the page is loaded, and displays a stylish animated tooltip which can be fully customized (Animation speed, animation turn on / off, graphic styles can be edited).

You can download it and find more info on it on:
Multipopup UserJS version

Here you'll always find the latest version of the script.

Great work, as always.
Just a minor specification to my request with the javascript links: is it somehow possible (and not too laborious) to make javascript inks appear no matter if they have a 'alt' title or not, and then with a different delay? What I'm thinking about, is that this popup appears always and instantaious when I hover over a js link.
If this isn't too much work (or would make the config file too complex), maybe give it a thought

8.02 significantly faster with populated websites

I'd like to inform you that Opera 8.02 does a better job at populated sites on positioning absolute divs. This is of course good news

Thomas, it is not hard to implement it, the infrastructure enables such modifications. Tho such a behaviour wouldn't be default. I'll see what I can do, check this space in a few hours.

I'm loving this script, a couple of suggestions though, would it be possible to have a section on your site which would allow you to customize the script before downloading it? You could have menus and checkboxes and a test area to see if it works like you want.

Thanks alex for your kind words. Thats a really cool idea but it may take as much time as making the script as I haven't done forms for a loooong time and need to re-asses my prior knowledge with javascript and all

The current preferences file is very self- explanatory I hope but what you say is sth to keep in mind, most definitely, and it is a nice challenge for me.

Not quite ontopic but it's very weird thing. I've added this line to user css:
#someElement a:visited::before {content: "(x) " !important;}

and performance of multipopup greatly decreased. On every site, even when there is no someElement at all on such page. Anyone knows why?

Really weird.

But I guess this is just that Opera has a bug with position absolute elements that have elements afterwards. Normally I put our div at the very end but those generated content may be invisibly sitting after our div.

Here is the test page:
http://www.hesido.com/test/webdesign/pagerenderingstresstest.htm
(test with all including IE, Opera has this weird performance drop.)

I had earlier reported this and I'm told that they will be inquiring this. Let's keep our fingers crossed!

The solution to my test page problem will probably solve that problem too.

Anyway, still, that's one weird bug, now that I tested it It seems to be very different from the one I mention. (and, the fact that no such element is needed to make a slow down is baffling.
edit: more baffles--

'a::before {content: "(x) " !important;}':
creates no problem.. it changes all the links..

'a:hover::before {content: "(x) " !important;}':
creates no problem, dynamic content on hover for all a's.

'#anelementnotevenonpage a:visited::before {content: "(x) " !important;}'
causes problems!

DIZ, this is a really weird bug. I'll set up a test page and you can report it using that page.

Ok, thanks for your effort. Looking forward to your test page.

Hi DIZ, I am setting up a test page but I realized it is not just any absolute positioned box but especially multipopup box that slows down. The test 'hover me for two seconds' box does strangely fine, but not my popup. So I am investigating a little more to understand why, and then maybe fix the problem with my script(?) (If I could ever find the reason is my script, I'll be damned, this is weird).

It might be positioning divs with divs inside or maybe spans, it might be when the object is created using dom. I'd give it little chance it is a problem with my script, as on firefox as right now I am testing, there is no such slow down. Still, I am working on this with different combinations. I am more confused then I was at the beginning.

I was doing a dedicated page but with the problem being not single handedly related with the CSS itself, I decided to copy the demo page and add in some CSS switching for testing for now.

http://www.hesido.com/test/webdesign/multipopupperftestpage.htm

DIZ, you could report the bug on this address, while I do a better investigation..

Update on the subject:

It seems, it is not the complexity of the div that is moved around but the function that is moving it.

When I move the div with a simple function, there is no noticable slowdown. When I move the div with the more complex function(s) that is found in multipopup that does point collision detect, window edge compensation etc etc, the problem is evident. I will do step by step simplification of the functions in multipopup *to find the level of complexity to visualise the problem* and report it. But I am not going to change the functions because of this bug as those functions perform very quite well without this :visited CSS and on firefox even with this piece of CSS, so this is most definitely an issue with Opera. And god knows to what extent other javascripts are effected in general because of this. It was clearly visible on my script as it is a very visual based script. And maybe the visual part also plays an indirect role that would be quite hard to link.

More on inquiry, almost there

More on my findings:

Summary:
There is slowdown in updates of some particular functions when a a:visited::before is styled with, whether this setting is applied to any anchor on the page is irrelevant.

• There has to be at least one visited link on the page for this slowdown to appear.
• The slowdown appears even when there is no such element for the style to be applied.
• The slowdown only appears when offsetHeight and offsetWidth is being used, other functions do not create a slow down.
• The amount of slowdown is DIRECTLY related to the number of offsetHeight and widths in the function.

I have narrowed it down to offsetHeight and offsetWidth being used, this is an important finding. While this is clearly a bug that may be affecting elsewhere, I will try to rearrange the functions to remedy this, this was not possible with 1.6 or earlier but now that the div height is stable unless there is warping, so I could use offsetHeight only once. I will also check for the getComputedStyle option, which is absolutely useless on Opera because it is not standards compliant.

edit: getComputedStyle is also slowed down, but the number of getComputedStyles affects the slowdown less. (Still, it is a useless function as it gives the same result as offsetHeight/Width while other browsers (even including IE with its own different implementation for reading computed styles) does it right for once, and give the content area size with getComputedStyle.


A really precise test page is coming soon.

The ultimate bug display page.

The definitive bug pin-point page is ready:
http://www.hesido.com/test/webdesign/avisitedstylingperf.htm

1.9 beta 6

A slight modification to increase performance is now online. But this help JUST a little. Please report this bug on the report page, I am *totally fed up* with this. I won't report it myself.

I am halting all development until this bug is fixed by Opera, the script is good as it is, and hopefully sites do not use a:visited::before much, this time I should thank IE for not supporting ::before

There was only one feature request left is from Thomas, and until I put that optional feature in , Thomas, you could hover over links with alt pressed for instant popups and move href's to primary.

Great job on narrowing it down.
I feel that now you know the problem much better than me so maybe you should file the report? Of course I can do it too, based on your information, if you want. What do you say?

edit: ok, I will do it

Thanks D.I.Z. You're the man

You're the man too ;P
bug-176089 <-- look at this Opera Software

Hey DIZ, an a:visited is enough for slowdown! (tho it doesn't affect is as much as ::before..) I've updated the page, please check it out.

So this becomes an even more important problem to solve for Opera, as a:visited is used, ahem, very often. I hope they care about this, because this seems so irrelevant that it might be dragging Opera down elsewhere.

If they fix this problem, multipopup will be lightning fast on ALL sites, regardless the population or CSS being used. I am cross checking each site with firefox, and a no-offsetheight version of multipopup on Opera (but of course it is not usable, as popup goes out of screen an all.)

I also noticed that performance is only affected if styles are changing page layout (when elements move). For example these styles affects performance:
a:visited {padding: 2px;}
a:visited {content: "x";}
a:visited {font-family: Courier;}

while these does not:
a:visited {text-decoration: none;}
a:visited {color: red;}
a:visited {background-color: red;}

Very good find...
You could use my test page to add those buttons that make those css changes to also see the slowdown better as it provides iterations.

Now here are new findings: The more elements styled, the worse is the slow-down! If the styles style many different elements, (they don't have to be present on page, as you know.

a:link creates the same problem too.

Now even a stranger finding:
search and replace a:visited's with b:visited, and the slow down is worse!

p.s. I have this feeling this wouldn't be that hard to solve for Opera..

What I'm guessing is that they some sort of thread constantly on the run looking for visited links, which, for some reason, interfere with style reading. (other kinds of style reading is probably affected too.) The more elements with the a:link and a:visited style, the more threads?

I have sent additional info to the bug report mail (copy/paste) and provided an url to this thread.

Returning more to the topic at hand. It occurred to me, that if you can split the preferences off into a different file, why not the skin too? It makes a hell of a lot more sense than playing around with extra CSS files.
So, as an experiment I set about converting the "toggleStyleCSS()" sample function on the MultiPopup page to a userJS script.

After much fiddling, I arrived at the attached, which, as far as I can see, should be working fine. Testing with bookmarklets reveals that the updated CSS has been successfully appended after the default entries, the specs demand that the later styles take precedence, but unfortunately, the updated data: URLs just aren't being used by Opera.

Perhaps you could take a look, or implement a better skinning system based upon the idea.

multipopup_skin.js.txt

Thanks DIZ. It is also interesting to see the thread about this on is being ignored in web-design section. I'd think of this as an important bug(!) I am sure not many people are interested in animation but from my tests, it creates a lag even for using them once in a function.

BtEO, thanks for your efforts! Why not use the user.css instead? One can turn off internal styling (mPUserJS.useDefStyle = false) and have the user.css style his popup, which can be shared.

We also have to keep in mind that if the extra style has different paddings and margins, the addpopupdiv() function needs to be run once more to do necessary pre-processing.

If they are appended, I wouldn't know why they are not put in effect tho. If you can persuade me why a javascript solution is better than a user.css solution for skinning, I can come up with a javascript solution where the id names are appended a certain prefix so we make sure the popup uses that style. For that, I'd need to add a prefix passing variable to addPopupDiv. Shouldn't be too much of a problem but can't be sure without checking.

DIZ, I've updated the page with actual benchmarks, and there are more findings!


Let's discuss the bug over here
http://my.opera.com/forums/showthread.php?postid=1002624#post1002624

and leave this thread for Multipopup only.

Originally posted by hesido
BtEO, thanks for your efforts! Why not use the user.css instead?

It just seems to me that a .js file would be much easier to share. No need to change further settings to make it work (just drop it into an already configured userJS folder,) nor toggle between author/user mode, and replacing browser.css is only any good if the user doesn't have a preexisting file.
Plus, you wouldn't need to restart Opera with a .js file.

Excellent script, hesido. Great job! Thanks for making Opera (even) better.

@BtEO, those are valid points. I will look into it later. I am a bit let down by Opera's a:link a:visited:bug right now.

@J0sefK, thanks, I'm glad my script is being used and useful..

I hope Opera does a quick fix to that awful bug. It made me lose interest in doing anything further to Multipopup, but I may have to get used to it. (I am promoting Opera everywhere including my site, I just hope they act quick this time, other new bugs I've found aren't fixed yet but this one's a big let down. In addition, it makes me look like a worse programmer then I actually am!)

1.9 beta 8, Two new features for popup happiness

I decided to add in those last two feature requests before I gave myself a break, they are BtEO's and Thomas82d's: external skin file support and instant alert when given pattern is matched.

Script is at the usual URI:
http://www.hesido.com/test/webdesign/multipopupdemopage.htm

However, the instant popup feature is disabled by default as many wouldn't prefer that. If you need the feature such as Thomas, please set in the prefs->

mPUserJS.alertToPri = true;
//if there is a pattern match for alerting, copy it to primary view even if it is configured for secondary.

mPUserJS.alertInstant = true;
//if there is a pattern match, display the primary view immediately. Only works if alertToPri is true.

edit: fixed the settings, both should be true to turn on instant alert popups.


To all those whom I included their feature requests, they should send me a postcard by snail mail. Ok this wasn't in licence agreement before, but Multipopup is now Postcardware-if-your-feature-request-is-included.

You can /whois check hesido.com to get my postal address which I had so stupidly declared to the whole world. Please, no horse-heads on my pillow, tho.

edit: kidding. (But wouldn't say no to a few postcards )

From lack of response, I should assume everything is fine?!

Seems fine here.
Which cards do you prefer?

An iconic figure / place of your country should do fine ;=) (Anyway, if it is going to be any hassle, no problem eheh, even that you ask is enough)

No problems here either. Now we'll just have to see if I can get around to making a skin....

Excellent again, hesido. Works like a charm. Thanks and keep it up!

It's kind of like a dream come true.
I was planning to write a wish of something like this. I turned of the tooltips in Opera a long time a go. There is nothing more irritating than having a long URL pop-up in your face when you're reading something in a page.

This is all you need, and it works great. Many good features, and great potential.

Good job!

Agree.
It just a shame that Opera does not allow turning off tooltips just for web pages. Tooltips in Opera interface are sometimes usefull (latest example - bittorent downloads)

I don't like having the tooltips popup all the time but sometimes it's handy to have them on, is it possible to modify the behaviour of this so that the tooltips only show up when I hold down a key?

It would work so that during normal browsing no tooltips would show then if I wanted to see a tooltip for something I would just hold down a key and the tooltip would show.

alex_p, You can make the hide delay sth like 10000 ms or even more, ( which then the popup would only occur after 10 seconds steady on an element.) You can then use alt(primary instant) or ctrl (secondary instant) for instant popups.

The beauty of multipopup comes from the fact that you decide precisely how long it should take to make a popup.

If you don't like popups but still want to see without having to do a keypress, I'd suggest making the delay 2000ms, which is 2 seconds. 2 seconds on an particular element is a good time

BTW, thanks guys for the nice comments. They make my day.

^^^ I never thought of doing it that way that will work just fine.

Hi.

I only get the secondary instant to display (ctrl). Nothing happens when i hit the Alt key.

D.I.Z. is it possible to make the old fashion yellow pop-up to be less transparent?

Thanks.

Thukai, can you check that on the multipopup page? If the element doesn't have title, there'd be nothing to display with the alt key.

If the document has lost focus, you need to reclick the document, otherwise keypresses may not work.

Originally posted by hesido
Thukai, can you check that on the multipopup page?

Just did. I get nothing with ALT pressed.
With CTRL pressed I get; ATL, ADDRESS, SOURCE.

Here is the preference file if you want to check if its something wrong with it.

multipopup_preferences.txt

Can you make

mPUserJS.attDPri = [true,true,true,true];

just to make sure there is something to be put in the popup?

Alt key should be providing instant popups for primary view..

Originally posted by hesido
Can you make

mPUserJS.attDPri = [true,true,true,true];/B]

When I did that I get tooltips on everything regardless. I cannot try the ALT button because i always displays tooltips.

http://home.broadpark.no/~kmthuen/opera/tooltip.bmp

The primary is defaulted to display titles only, if there is no title, there'd be nothing to popup. If the nested colored boxes has something to popup, the alt key is working. If not, there could be a second instance of multipopup working that removes the titles, but I don't think that's the case. Please check if title is shown in nested boxes. If a title is shown, everything is working properly, and, you can go back to the normal.
mPUserJS.attDPri = [true,false,false,false]

If something is still wrong, this means I can't understand you correctly!

Originally posted by hesido
The primary is defaulted to display titles only, if there is no title, there'd be nothing to popup.

If something is still wrong, this means I can't understand you correctly!

Well, maybe it's me that can't understand. I believed the ALT key do do something different. But what it really does is to display the title pop-up instantly if you have, lets say 3 seconds of delay on your pop-ups. Is that correct?
If it is, than it works as i should

Thanks anyway.

Yes that is what exactly alt key does

I've downloaded MultiPopup V1.8 revision 5 and I see it wreaks the page:
http://www.htmldog.com/

Dantesoft, thanks for the bug report. I'll look into it!

Bad dog, Bad dog!

Here is the offending script.

/* Script allowing MS IE to see the 'abbr' tag  by Marek Prokop */
/* [url]http://www.sovavsiti.cz/css/abbr.html[/url] */

function styleAbbr() {
	var oldBodyText, newBodyText, reg
	if (isIE) {
		oldBodyText = document.body.innerHTML;
		reg = /<ABBR([^>]*)>([^<]*)<\/ABBR>/g;
		newBodyText = oldBodyText.replace(reg, '<ABBR $1><SPAN class=\"abbr\" $1>$2</SPAN></ABBR>');
		document.body.innerHTML = newBodyText;
	}
}

window.onload = function(){
	styleAbbr()
};

isIE = (document.all) ? true:false;

It rewrites the ENTIRE body, based on a really awful browser detection, document.all = ie, LOL. Does not use DOM methods. This is a bad habit

Now what should we do? Shall I make a simple stop multipopup from running key combo, so we could keep like 'shift + alt' pressed and it doesn't run? Or should we maintain a 'no run' list? Or both?

I do believe we must tell them HTMLDogs to use IE conditional comments instead of a really awkward browser detection.