I am actually using sharon paines most recent version of this tooltip.

I have many tips on a page, and want to reduce page size.
Does anyone know if it is possible to put all the

onmouseover="doTooltip(event,t1)" onmouseout="hideTip()">

code in one place and reference each individual tip. It seems a lot of code to repeat everytime???
I have the tooltip .js file as an external file.
Any ideas would be greatly appreciated.
Thanks in advance
Richard

Twey

07-01-2006, 03:53 PM

You can, but you've got to have something that all those elements have in common. For example, a common class name, a common name, or if you want all of that type of tag to have the tooltip.

rich1234

07-01-2006, 06:18 PM

Dear Twey,
Thanks for the reply. The hrefs are not in common and the events are different, so I suppose its not possible. I was trying to reduce the amount of onmouseover and out. I was imagining you could have a single letter reference like in css to the mouse over and out to reduce the text memory size.

Then there would be a way to get everything set up onload with a single function.

Alternatively, you could just get rid of the onmouseout attribute by assigning it during the onmouseover event phase of the script.

Either of these approaches require the script to be modified. With the first method, you couldn't have any other links (not using tips) with an id that starts with 'tip', or it would make things too complicated.

Dear John, Thanks for the help. I think I will look into the assigning of onmouseout to save memory, prob easier.
Thanks very much
Richard

rich1234

07-02-2006, 11:53 AM

Dear John, Just recieved your demo. That is amazing I set it up staightaway and it works perfectly
http://www.richardrubbra.com/TESTING.htm
basically eliminating all those mouseovers.

I have however been using sharon paines latest version here

http://www.dyn-web.com/dhtml/tooltips/tip-txt-img.html
one with three external .js files.. event, tooltip and viewport.

Is it possible to do the same magic to this one. I would happily pay whatever you charge. To go to this effort for free seems a bit much.
Thanks very much for your time and energy.
Richard

jscheuer1

07-02-2006, 09:12 PM

I'm not sure if I want to get involved with this project at this time. I want to consider the ethical implications and technically difficulty of the project further. Also, I would like to know if you are using the 'linkware' version or have purchased a license, and if you have purchased, at what level.

rich1234

07-02-2006, 09:31 PM

Dear John, I do have a licence, I have the multi domain licence. I wrote to sharon asking if she knew how to do it but she said that although she thought it was theoretically possible she didnt have a way. I have been led to believe from her licencing prerequisites that one is allowed to alter the code to suit. I am sorry if I appeared to jump the gun. The changes you made to the original tooltip were great. I was just interested to know if it was possible- and you proved that it was - and also how much that might be to alter the later version. If after consideration you do feel that you can do it, I would be most grateful if you could give me a quote. Anyway I thank you again for the time you have spent.
Thanks
Richard

jscheuer1

07-02-2006, 10:35 PM

Turns out I already did most of the work on this one. At least for her free demo, this works:

/* This is where you can customize the appearance of the tooltip */
div#tipDiv {
position:absolute; visibility:hidden; left:0; top:0; z-index:10000;
background-color:#dee7f7; border:1px solid #336;
width:250px; padding:4px;
color:#000; font-size:11px; line-height:1.2;
}
/* These are optional. They demonstrate how you can individually format tooltip content */
div.tp1 { font-size:12px; color:#336; font-style:italic }
div.tp2 { font-weight:bolder; color:#337; padding-top:4px }
</style>
<script src="js/dw_event.js" type="text/javascript"></script>
<script src="js/dw_viewport.js" type="text/javascript"></script>
<script src="js/dw_tooltip.js" type="text/javascript"></script>
<script type="text/javascript">
/*************************************************************************
This code is from Dynamic Web Coding at dyn-web.com
Copyright 2003-5 by Sharon Paine
See Terms of Use at http://www.dyn-web.com/bus/terms.html
regarding conditions under which you may use this code.
This notice must be retained in the code as is!
*************************************************************************/

Very Important! all tip variables and id's used must begin with 'tip', as with my previous modification but, numbers are no longer required (see above example page's code for examples).

rich1234

07-03-2006, 11:43 AM

Dear John, wow, thanks very much for doing that, I intend to have a great number of links and this has halved the size of the page. It has really made my project more viable. About the onload attribute from the body tag, I am not sure of its function, so dont really know if its worth adding to the tooltip.js. Its working fine without it at the moment.
Anyway, thanks again for your great help
Richard

jscheuer1

07-03-2006, 03:05 PM

About the onload attribute from the body tag, I am not sure of its function, so dont really know if its worth adding to the tooltip.js. Its working fine without it at the moment.

I'm not sure exactly what you mean here or your level of javascript knowledge so let's be very basic about this. OK, this statement (attribute) in the body tag:

<body onload="Tooltip.init();">

Is virtually the same thing as having this inside a script on or linked to the page:

onoad=Tooltip.init;

or:

onload=function(){
Tooltip.init();
}

So, what I did was to put the body onload attribute in a function and add to it in order to initialize the links' mouse events onload as well. There can be only one onload event per page but, it can do many things, if desired. There are other ways to add to it but, this is about the simplest and clearest method.

That is part one of the explanation, part two is that you don't need to have any code on the page but, it would be nice to keep the tips there. You could have the head of the page look like so:

/* This is where you can customize the appearance of the tooltip */
div#tipDiv {
position:absolute; visibility:hidden; left:0; top:0; z-index:10000;
background-color:#dee7f7; border:1px solid #336;
width:250px; padding:4px;
color:#000; font-size:11px; line-height:1.2;
}
/* These are optional. They demonstrate how you can individually format tooltip content */
div.tp1 { font-size:12px; color:#336; font-style:italic }
div.tp2 { font-weight:bolder; color:#337; padding-top:4px }
</style>
<script src="js/dw_event.js" type="text/javascript"></script>
<script src="js/dw_viewport.js" type="text/javascript"></script>
<script src="js/dw_tooltip.js" type="text/javascript"></script>
<script type="text/javascript">
/*************************************************************************
This code is from Dynamic Web Coding at dyn-web.com
Copyright 2003-5 by Sharon Paine
See Terms of Use at http://www.dyn-web.com/bus/terms.html
regarding conditions under which you may use this code.
This notice must be retained in the code as is!
*************************************************************************/

This code is from Dynamic Web Coding at dyn-web.com
Copyright 2003-5 by Sharon Paine
See Terms of Use at www.dyn-web.com/bus/terms.html
regarding conditions under which you may use this code.
This notice must be retained in the code as is!
*************************************************************************/

The advantage in all of this is that if you use this script on several pages, the external files only need to be parsed/cached once, and it gets more stuff off of your individual pages so that they can be parsed/cached more quickly.

Similarly, you could make the style for the tool tips be an externally linked stylesheet or part of an existing externally linked stylesheet but, if you are not familiar with how that works, that's a separate lesson.

rich1234

07-03-2006, 08:43 PM

Dear John,
My javascript or indeed any programming knowledge is 0, but I am not to bad at moving things around. Thanks for clarifying things, although it seemed to work, I put the modified code you gave me together with the tips and this code

So I am thinking, surely if you can upload a second image, you must be able to upload a text file too. I tried putting a text file reference there but of course it didn't work, as how do you get the text file open! and I don’t know what format to save it in.

Do you think this is feasible at all? or am I dreaming!
Thanks
richard

jscheuer1

07-03-2006, 09:22 PM

I'm not sure that your use of the term upload is accurate. As a result, I am once more not certain what you are saying. Here are two items that may interest you:

1) You can put the tip variables in an external script as you have done. It makes no sense to do so unless they are shared by two or more pages, otherwise, for clarity's sake, it is best to keep the tips on the page that is using them.

2) You are already using an external text file, albeit a javascript text file, to add text to your tips. No real need to do anything more to achieve that. You could do something like so:

var tip='<iframe src="some.htm"></iframe>'

But, that would just load another page into the tip. This would take longer to load than just putting the contents of some.htm that you want displayed into the tip variable to begin with.

rich1234

07-03-2006, 11:48 PM

Dear John, Thanks. As all the text with the tooltips gets uploaded with the tooltip.js file and I am imagining having so much tooltip text that my tooltip.js file might be up to 1000kb, I was thinking, was there some way that individual tooltip text like the image could be uploaded only on mouseover and not alltogether thus reducing the tooltip.js file upload time. Thanks for the iframe idea which I tried, but the appearance of the tooltip does not fit with my general design.
Thanks
Richard

jscheuer1

07-04-2006, 05:11 AM

I think I am getting the idea about 'uploading'. Your real concern seems to be the amount of time and resources visitors to your site will spend (down)loading your tips.

If so, the iframe idea may be the way to go. If properly configured via style and attributes (both the iframe and the page(s) showing through them), an iframe and its content should be able to appear any way you choose. My example was just that of a most basic iframe. I'm still not sure what this will get you though as, the code for the iframe will then need to be set for each tip variable instead of its text value.

rich1234

07-04-2006, 04:59 PM

Dear John, Thats exactly the problem. I have revisited the iframe solution, I think it could work too, I tinkered with it and got it looking pretty ok, without borders and scrollers. I think it probably could be done in css too but cross browser quirks with iframe might make it a bit too tricky for me to control.

I thought of another solution and wonder if it could be done.

Having the tooltips divided into different .js files. I have tested this and found that it works. Of course all of them would have to be uploaded before the homepage functioned.

The question is, is there a way to stagger their upload, so that the one that relates to the tips at the top of the page uploades first and the others maybe staggered with a time delay or when a link, lower in the page is hovered over. Or maybe a call in the main tooltip.js, when it has completed upload to upload the others. And would that work anyway? Do page with .js code only work when all the .js files are uploaded?

Thanks again
Richard

rich1234

07-05-2006, 12:11 AM

Dear John,
Since my last post I have been looking around for ideas on the net, and found this link

http://www.c-point.com/javascript_tutorial/Editor/ajax_tutorial.htm

It seems to me the closest thing to what I was thinking if there was a way to incorperate it in the code. What do you think?
Richard

jscheuer1

07-08-2006, 07:18 AM

Yes, that should work out nicely. I've implemented it but, in order to avoid a 'warning' message in FF for folks who closely follow that sort of thing in their script debuggers, I changed the use of id for this to name (this should also allow more than one trigger with the same name/tip). I also created a variable (red in the code immediately below) that will be used to hold the event until the external script holding the tip can execute. The onload code has changed as well.

The nice thing about this implementation is that it is backward compatible, you can load some tips in the mouseover event, or using the ordinary method of 'variable storage' (with the events being either hard coded to the trigger or assigned onload due to its name attribute) or using the externally loaded script with the name attribute. Once a given tip is loaded from an external script, it will become like a 'variable storage' tip and follow that path toward execution on subsequent mouseover events.

I've only made one tip external in the following example but, it may be used as a template:

var tipRich = '<div class="tp1">This text is in a div with it\'s own class for different style specifications than the tooltip. </div>';
doTooltip(eventHolder, tipRich)

The red part will be the same for each external tip*.js file, the name of the file will be the name of the tip which will be the name of the trigger and be the two green variables referenced in the external file.

Added: The tipRich.js file goes in the same directory as the page but, can go anywhere as long as its path is properly referenced for or in loadScript().

rich1234

07-08-2006, 06:51 PM

Dear John, What can I say, thats brilliant. Not only did you halve the size of my home page by eliminating the need for the mouseovers and offs, but have now reduced the total memory completely by getting rid of the variables for tooltip content and associated text. Incredible!

I hope I have set it up correctly, as I seem to have a glitch and in Internet Explorer I get error on page when I mouseover a link for the first time and then after I mouseover the link for a second time it works, but still with error on page message. I have a test page here

http://www.wotartist.com/trial.htm

Do you think this is a delay due to the var eventHolder holding the event until it can execute it?

Regarding the onload assignment you mention above, Is it set up to onload only on mouseover at the moment, so I dont have to tinker with anything?
I dont need to preload anything, just let it function on mouseover.

Thanks very much
Richard

jscheuer1

07-08-2006, 09:48 PM

Looks like you have it right. I just tested locally before I posted my last reply in this thread. I just now tested live, and I am getting the same error. Apparently, in the time that it takes IE to load the live contents of the tip, it forgets what event is held in the variable 'eventHolder'. Locally there wasn't enough lag for this to be a problem. IE handles events differently than other browsers and I am not certain if there is a workaround but, will look for one.

jscheuer1

07-09-2006, 03:46 AM

Looks like I have it solved. The problem is that IE5 to IE6 cannot assign an event to a variable for later use. To get around this, I used those browser's ability to generate their own events without user action to create a new similar event at the appropriate time. As I said before, this part of the code is only needed the first time a tip is loaded from an external file, after that, the whole things works as our previous working version did, until the page is reloaded. There is a lag though, in any browser as we load the new .js file containing the tip and then call for the doTooltip() function to run. This will vary by browser, bandwidth, and size of the externally loaded tip variable. Unfortunately, with this fix for IE, we can no longer assign the same tip or name to more than one element.

OK, here is what you do - add this function just after the loadScript() function:

And now the external tip*.js (I'm using tipRich.js again as an example) will look like so:

var tipRich = '<div class="tp1">This text is in a div with it\'s own class for different style specifications than the tooltip. </div>';
goTip('tipRich')

and its filename is, of course, tipRich.js and its trigger's name will be like so (as before):

<a href="some.html" name="tipRich">rich html</a>

For other tips, just substitute their name in all the green spots, including the name of their .js file.

rich1234

07-09-2006, 12:23 PM

Dear John, That seems to have done the trick in Internet explorer, but as always the devil is in the detail, and in Netscape 8 it has developed a problem, on mouseover, without having to click the link, it takes you straight to the linked page, almost before the tip has time to display. Do you think there is a fix for that?
Richard

jscheuer1

07-09-2006, 02:24 PM

I can't duplicate the NS8 problem in NS8.1 or NS8.0.4. What version of NS8 are you using and what browser mode and security did you have it set to and do you need to do anything special to get it to misbehave? In NS's native browsing mode, it should follow the path to execution that FF uses successfully, in its IE mode, IE's path should work, this is what I am observing here.

I am seeing a slight problem in FF. When the page is completely uncached and loaded for the first time, the tips at first display at 0,0 instead of over the triggers but, if you move the mouse at all, they jump into place. I will look into that.

rich1234

07-09-2006, 04:31 PM

Dear John, I am using netscape 8.1. When I change the trust settings/rendering engine to firefox its fine but with internet explorer I still have that quirk. I dont do anything special for it to behave like that, just mouseover triggers the link. Before the last change in the code you made to fix the internet explorer bug, it didnt have this behaviour, so it might be something there. When I do a dom inspector, it seem to work fine in the test window, but I got the following error message in the javascript console

I noticed the quirk in ff too. In internet explorer and icab for mac, the tooltips dont work, but with IE for mac its probably the withdrawn support offered to it by microsoft.
Thanks
richard

jscheuer1

07-10-2006, 02:45 AM

Why do you have this:

<script language="JavaScript" src="ajax.js"></script>

on your test page? It is not required and could be causing the trouble. I set up a demo of my method and it doesn't have this problem or this link to that external script. To be clearer, I only needed the loadScript function, not all that other junk, so I put loadScript on the page. Having it on the page and in an external file could cause problems and having that extra (unused) code in the external file can't be good.

I have an idea for a workaround for the incorrect positioning bug but need to test it so, I will get back to you on that.

jscheuer1

07-10-2006, 04:22 AM

OK, I think I've got it all ironed out. See my previous message about getting rid of the extraneous external code. Here is my demo:

Dear John,
I am really sorry to bother you again after all this hard work, but after implementing the new changes, nothing seems to work. I have gone over it with a fine tooth comb, but cannot see any error. I have made three copies, one directly from your test page but none work.
http://www.wotartist.com/trial2.htm
http://www.wotartist.com/trial2.htm
http://www.wotartist.com/trial.htm

I am using identical external.js files as references for the tip as before when it worked with all the right references set up .....goTip('tipRich') .....and have downloaded the new tooltip .js file.
Maybe you can see where its going wrong.
Thanks again
Richard

jscheuer1

07-10-2006, 02:16 PM

Well, you only supplied two demos in your last post, not three. No matter, let's focus on one for the time being. I choose:

http://www.wotartist.com/trial2.htm

OK, there are two obvious problems but, I think after fixing those it still will not work. Let's try fixing those and, if I am right about there being another problem, I have a test in mind to help find it.

1 ) You've followed my code too closely, even where it diverges from conditions on your server, where you copied this function from my demo:

But the trigger's name is tiprich so, case matters, you are giving the wrong information to the rest of the code.

Fix those and if, as I suspect, it still doesn't work, revert to your original dw_tooltip.js file. I'm thinking that differences between it and the 'credit ware' version I was working from may be the problem. If that is the case, reverting will fix everything except the FF positioning bug. If not, then perhaps the real problem will become apparent.

rich1234

07-10-2006, 04:15 PM

Dear John, You are right, it still didnt work until I reverted to the licenced version of the tooltip.js I have. When I did, it worked but with the original problems in netscape 8.1 and ff. The ff problem, I could live with, but the netscape one, which you dont seem to get, is problamatic. It seems that fixing the bug in IE, creates one in netscape IE mode. I feel somewhat humbled by your generosity in helping me. If you feel enough interlectual curiosity to want to search for a solution to the problem, thats brilliant, but I would entirely understand if you dont. Thanks very much.
Richard

jscheuer1

07-10-2006, 05:19 PM

OK, that's what I thought. I will need to have your version of the dw_tooltip.js file. If you have the demo up and it is using that, I should be able to get it from your server.

About the NS8 bug, I did get it but thought it was due to the extraneous code from the ajax unit's external .js file. If you check my live demo again, in NS8, I think you will see that it doesn't have that problem.

rich1234

07-10-2006, 05:21 PM

Dear John, Just a note to show you two examples. trial5 is the version before the IE fix and works in Netscape without problem, but in ff, the tooltip stays at 00 and doesnt correct itself on a second mouseover.

Trial1, has the IE fix and the problem in N8, and the bug in FF.

http://www.wotartist.com/trial5.htm

http://www.wotartist.com/trial1.htm
Thanks
Richard

jscheuer1

07-10-2006, 05:53 PM

I am attaching a .zip file with an updated version of your copy of dw_tooltip.js and a demo .htm file that should run fine on your server as long as you haven't changed the tiprich.js or tiprich6.js files since I made the .htm demo. The demo tested fine here in NS8 IEmode.

418

jscheuer1

07-10-2006, 06:17 PM

I see now why there is a discrepancy in our findings. I used href="#" in my demo but, if I change it to something like:

href="http://www.google.com/"

even my demo has the NS8 problem. That's an easy fix though, use this goTip() function:

Dear John, Thats it, completely fixed, great. Just to say thanks for all this work, and making my project viable. I have certainly learnt quite a lot. My projects concept required right from the beginning that I be where I am now, with everything downloaded on tap. I will show you the site when its up and running, and will have a link to your site. Thanks once again.
Richard

jscheuer1

07-11-2006, 06:28 AM

That's great! NS8 is weird in IEmode though. I've noticed it before but can't remember exactly what it was, little things like that problem we were having. The link is not supposed to fire if the the onclick event returns false. IE itself follows this rule as do all other browsers including NS8 except when it is in IEmode. That's not the main reason I am posting this message though. I just wanted to remind you that all this added code, and the original doTootip and hideTip functions can be moved to the bottom of dw_tooltip.js. This is a very good move if you use tips on more than one page. The style can be moved to an external stylesheet, this is also good if more than one page uses the styles. By making these changes, these functions, code and styles will only need to be loaded once for each session visit to the site. If they are kept on separate pages, they need to be loaded for each page. If you need pointers on doing this, just ask.

rich1234

07-11-2006, 05:55 PM

Dear John, Thanks, I have done both things, the home page is extremely light now and works a treat. There was just one thing I was thinking. Although getting it to display in IE for MAC is not really of too much importance to me, I was wondering if there was any quick fix for that as the tips don't work. It worked in Sharon Paine's original version when I tested it.

I know they withdrew support for the browser some time ago. Looking around there is a lot of mention of bugs in IE for mac and javascript.
Anyway, thanks again.
Richard

jscheuer1

07-12-2006, 04:16 AM

Quick fix, no. The only sure fire approach (if, as you say, the original worked) would be to devise a path to execution for IE Mac that would force it to run the script in its original form. This would involve a browser/os test and creation of a master script of all the tip variables to be loaded and used by IE Mac alone, while others follow the new path we created for 'on the fly' loading. Not really as much work as it might sound but, certainly not a quick fix. An alternative would be to try to determine what IE Mac doesn't like about the new code. I have no Mac to test on so, error messages (if any) that it gives might be helpful in this. Also, I will write out a little test page for IE Mac to see if it likes either of the solutions we used for holding over the event for later use. If it can use one of those, then the fix might be something minor. If it cannot, another method will need to be found for it.

Load this up in IE Mac and then copy and paste the output to a post here:

Dear John,
I am only able to test remotely on 'browser pool' From what I deduce you are are testing to see if one condition doesn't work the other will.
I think I have done what you asked. I loaded up the test as it was and got no error messages.
I added links to the external js files and changed 'test' to 'tiprich' in both the code and link. I again got no messages, but it didnt work in both tests.

Well, I think I would need to see it on a Mac, or see what it actually did on an actual Mac. However, what is this browser pool? If it is a site I can go to that shows you how your page works in other browsers, I might be able to get it to yield some useful information. I've used services like that before but, all the ones I've seen so far just give a snapshot of how the layout would look, useless for real-time javascript debugging.

rich1234

07-12-2006, 05:02 PM

Dear John,
Its a pretty good service, with a free usage account available, its not just a snapshot but real-time and you can adjust the settings for javascript error reporting.

http://www.browserpool.com/kc/wob/portal.jsp

I think its ok for de-bugging as I have got script errors from it before, specifing the errors and lines on which they reside. At the bottom of the page there is a link to set up a free user account.
I hope it may be of use to you.
Thanks Richard

rich1234

07-12-2006, 07:16 PM

Dear John, I tried my test page again in browser pool. One has to reset javascript error reporting every time one views a page. This time I got the following error on load.
line 51
char 4
object doesn't support this property or method.

Hope that means something. As a footnote, I tested in Konquerer and it didnt seem to work either.
Thanks Richard

jscheuer1

07-12-2006, 08:13 PM

Well, I tested out a simple externally added javascript in browserpool and it didn't work. IE Mac will create and append elements, that much is needed for the original script to function but, it will fail when appending a script element. Either it doesn't recognise it as a valid element or it appends it but will not run its code. This pretty much takes us back to what I first mentioned, which would be to run the script in its original version for IE Mac. This will slow it down in that browser when loading all the tip variables but appears to be the only way. If you are interested, when I get the time I will set up a test/demo of how this would work. It will require all the tip variables be listed in a single separate .js file that we would only link to the page(s) if the browser were IE Mac. Something like this, in the head of the page:

The code additions we made for the 'on the fly' variables will need to be shielded from IE Mac as well. Also, we will need to see if IE Mac can handle the assignment of mouse events at the level we had before added the external 'on the fly' variables. If it cannot handle that much, I am afraid it might not be possible to work out at all.

rich1234

07-12-2006, 10:49 PM

Dear John, Thanks for trying, I think its not really worth the bother for a browser that's on its way out. I think I will keep it as it is, working fine for all the major browsers. Thanks once again for all the effort you have put in to my project.
All the best.
Richard

jscheuer1

07-13-2006, 03:36 AM

I was just thinking about it idly, and it occurred to me that the code is already shielded because our existing code doesn't even try to load 'on the fly' variables if they already are present. All we need to do is supply the tip variables for IE Mac. I did a test and it worked. So, if you are interested, here is what you do, put this on or linked to the page (I put mine in dw_tooltip.js):

Just make sure the highlighted path (if used) and filename point to the correct file relative to the page that uses it, or if using with several pages in different locations, use the absolute path. In this file you need to list all the tip variables, my macVars.js looked like so:

Dear John,
That worked perfectly for my test page in IE for mac. when I tested your demo page in conqueror and icab, the tips worked. When I tested my page in those browsers it didnt.
I was wondering why as they seem to be set up the same, althought I am not sure if you are using the freeware tooltip.js or like mine the licenced version?
My demo is at
http://www.wotartist.com/trial.htm

But you know as an experiment I replaced the tiprich variable code in my macVars.js file, for this one as follows

and incredibly it uploaded the tiprich file .js file too. As it seems to be able to preform this trick, I wonder if there is a work around that doesnt require the extra .js file with the tip variables?

Demo
http://www.wotartist.com/trial1.htm

To achieve the same for conqueror and icab, do you think its possible workaround to define the variables for them in the same way?

I suppose that's three question, on the way to perfection!
Thanks
Richard

rich1234

07-13-2006, 06:36 PM

Dear John, Just to say when I said uploaded the tiprich file, I meant the tooltip worked, using the .js files information I have on the server.
Thanks
Richard

jscheuer1

07-13-2006, 06:37 PM

I'm thinking that some of what you are observing could be accidental and/or could have undesirable consequences for the more mainstream browsers we already had this working for.

The way to get other niche browsers to follow the path to execution that we have laid out for IE Mac would be to include them in the conditional that tests for IE Mac. Unfortunately, most modern niche browsers have the ability, frequently activated by their users, to fake out a script and make it think that they are IE Windows. That is because some sites deny access to all but IE Windows. This is an abuse of browser testing (by both the niche browsers and the designers of the IE Windows only sites) in my opinion but, there is little we can do about it.

It still would be worth while perhaps to test for these niche browsers but, it won't always work. It will work more often than if we abandon them altogether. I'll look into the exact type of tests that might best be used.

As for what version of the tip script I am using, I am using the 'linkware' free version. However, since the modifications I am employing to get it to work on IE Mac do not rely on the alterations to either the free or licenced code that I made (which were identically altered BTW), this shouldn't make a difference.

rich1234

07-13-2006, 09:13 PM

Dear John, I have re-tested your demo in konqureror, and icab and IE for mac and it works in all three. My demo still doesnt. I have looked at the code and cannot see any differences. If I can get your solution to work, its really solved all the problems. The only thing I can think is that I may have incorrectly edited the src (see below) which might have some adverse effect on the other browsers.

Just make sure the red part points correctly to your file of alternative variables (as before). It excludes Opera because in Mac Opera can appear to be IE but isn't IE Mac and doesn't need this extra help. Konqueror and iCab are included as is IE Mac. If you see a little m before the tip text for rich text and for image, it means a browser is using the extra help.

rich1234

07-13-2006, 10:51 PM

Dear john, That's worked out very nicely. Great to have all those browsers covered. There's nothing like taking an idea as far as it can go! My website project is quite an ambitious one, but should be up and running soon. I am sure I may need to call on your expertise again, but for now just to say thanks for all the great work you have done.
All the best
Richard.

rich1234

07-22-2006, 12:49 PM

Dear John, I was wondering, with the script alterations that you made, if it were possible to extract the image reference, text and if possible the href="" from a database instead of individual files? As the .js files with the text and image ref have to be in the same folder as the homepage, I perhaps overlooked the time consuming nature of managing so many individual files in one place. If it is possible, do you know what type of database would be needed?
Thanks
Richard

jscheuer1

07-22-2006, 03:02 PM

Introducing a database to this arrangement would require that a server side language be available to you. Two of the most popular are PHP and asp. One drawback is that this would introduce additional lag time in the loading of a tip because the time that it takes the server to retrieve the information would be added to the mix. This may or may not be significant, it would depend upon how busy the server was at any given moment visa vis the server's overall processing capacity. This may or may not be much of an issue as the server is already retrieving the file but, at least then the file is cached on the user's end. With a database, the information may have to be retrieved by the server each time. Now, my knowledge of database techniques and server side languages is quite limited compared to my knowledge of javascript. I do know however that there are various ways a database can be set up and different ones that can be used, the same is true of the server side languages. You would want to go for the most efficient method possible. To do this would probably require some research on your part and/or the help of someone more knowledgeable on the specifics of these topics.

If it is simply a matter of wanting to have a separate directory for all the tip files, this could be done with appropriate coding. I think this is the most recent version of the loadScript() function that we were using:

You would replace this path with the actual one you decide to use. To make the files more manageable, a naming convention could be employed. Due to the way filenames will be presented in a directory listing (0 to Z) and the fact that each file must be named:

tipsomething.js

You could decide on the upper limit for the number of tips, say it was one thousand, then this naming convention could be used -

The first tip would be:

tip000tipname.js

This would allow you to go all the way up to and including:

tip999tipname.js

The numbers used would correspond to the position of the tip on the page and the tipname would be descriptive. Using this sort of scheme should help you to organize them just about as well as any database would.

rich1234

07-22-2006, 11:33 PM

Dear John, I set that up and its perfect. I am going to have 5 pages with 500 links and if all the .js files had to be in the same place you can imagine the chaos. I can now have them all neatly in folders.

There was one other point I wonder if you can help with. I know of course my links to external pages can still be stolen whatever one does, but is there a way to have all href link addresses externally located and referenced with a ref code on the actual page. Or maybe included in the individual tip.js files? I have looked around and cannot find much relevant material apart from, for example this page which scrambles the href address

http://smiledsoft.com/demos/hideemail/hideemail.php

Quite clever and it works, but adds too much code to the weight of the page.

Thanks again for your help
Richard

jscheuer1

07-23-2006, 04:18 AM

I'm not clear on what you want to hide or why. Generally, any hiding or encrypting will not protect your material. That is what copyright is for. What happens is that if someone wants to steal it, they will find a way. Encrypted material can easily be decrypted. Hidden files can be found and, if used by the browser, will be in the browser's cache. These sorts of 'protection' schemes generally only stop honest people and usually add overhead (lag time) to the code, or worse.

What exactly do you want to hide and why?

rich1234

07-23-2006, 10:10 AM

Dear John, It was a bit of a long shot. I realise that whatever you do put on a site can be accessed otherwise it couldn't be seen in the first place. I was sort of imagining, not so much in an attempt to hide the href address, as that's impossible but maybe in an attempt to reduce the weight of the page to incorporate the href address with the tip. As the tip downloads on mouseover, I was thinking if there was a way for the related href address to be embroiled somehow with that information and therefore doing away with the necessity for it to be on the page in the first place. Or a substitute href on the page that was a trigger for the real one. This is probably really in the realms of fantasy, but I thought I would run it past you anyway.
Thanks
Richard

rich1234

07-23-2006, 03:23 PM

Dear John, I think I have just figured out the idea, if its possible. One version of this tooltip has links, in the tooltip itself, and as the tooltip stays static long enough one can click on them. As I have it now, with the tip info is in its own.js file, is it feasable to put the href link in with the text? The only modifiction might then be, to stop the tooltip moving on mouseout.
What do you think?
Thanks
Richard

jscheuer1

07-23-2006, 03:44 PM

It is hard for me to imagine hrefs adding that much weight to a page. If you are writing them out in their absolute form:

href="http://www.somedomain.com/directory/pagename.htm"

It could get to be quite a bit. However, you can use the virtual form:

href="/directory/pagename.htm"

or relative (which can look like so but varies depending upon the location of the linked page relative to the location of the page with the link on it):

href="../directory/pagename.htm"

There is also the base href tag which can be paced in the head of a page. If most of the links on a page are in a certain directory, the base href can point to it. Then only links that deviate from this need to be written out in full.

You probably could load the href as a part of the tip's script or put it on the tip but, then your links would be inaccessible to non-javascript enabled browsers. Generally not a good idea.

rich1234

07-23-2006, 05:00 PM

Dear John, Yes I think you are right, about the non javascript users. All my links are external to other sites so I have to write out the full address and yes it does add up. Thanks again.
Richard

jscheuer1

07-24-2006, 04:47 AM

If the majority of the links on a page are to a single domain, that's where the base href can come in handy. It is an HTML tag so isn't dependant upon javascript. Once you set the base href for a page though, all links on that page that do not access that domain must be written out in absolute terms, as well as image src attributes, linked styles and external scripts. This includes any of these links and src attributes that appear in scripts that are used on or linked to the page as well, so it might not work out too well if all of your images are on your primary domain.

It's easy enough to do, say most of the links are on someother.com - you would then put this in the head of the page:

<base href="http://www.someother.com/">

You can even specify a directory on the other domain if you like. After that, all links on the page will act as though they have that as their preface, or base. Links can be written relative to it if possible or, in absolute terms if they are on another domain.

rich1234

07-25-2006, 08:47 AM

Dear John, Thanks for that, it will be quite handy as my site grows. Just to give you an update on my previous query. I did a test, I attached the modified code that allows for links within the tip, that sharon supplies, as an external .js file. I then wrapped the href around the image in the .js tooltip files and it worked, the tip doesn't move so you can click the image as a link. That does away with the href on the page. Like you though I agree its not a great idea, but might be handy when there is a need for secondary links.
Thanks again
Richard

rich1234

07-27-2006, 09:20 AM

Dear John, Just a thought - Is mod_rewrite a good way to reduce href weight?
I found this
http://www.websiteoptimization.com/speed/tweak/abbreviate/
My site is on a windows NT platform and I was thinking if this is a solution, to turn to Apache.
Thanks
Richard

jscheuer1

07-27-2006, 05:06 PM

Now you are moving outside of my area of expertise. However, I know enough about server side languages to know that this type of thing could be done in any of them and on any type server only, the specifics would be different. Also, enough to know that you would be adding to the server's load for each page that this was used on. This would most likely be unnoticeable except in cases where the server was at or near its limits in processing capacity and/or memory usage. In which cases, there would be additional lag time to the page load, sometimes quite significant.

Unfortunately, I cannot see how using this type of server side gimmick would help the end user. By the time the document is served to them, it would (if this was done correctly) contain the full paths. This information would pass over the internet in exactly the same way, at exactly the same speed as if it were hard coded into the page - except if the server was under heavy load, as I've already mentioned. It would make your actual pages shorter but, for editing and space saving purposes only. Plus, you would have to remember all your abbreviations.

rich1234

08-03-2006, 04:24 PM

Dear John, I have just found a small problem with firefox. Something we might not have noticed as I didn't have a mock up of my page to test. The original problem was the tip appearing at 00, if you remember. well if one scrolls down the page the problem re-surfaces, randomly sometimes at 00 and others just at the top of the screen and others in the correct position. Here is a dummy page.

http://www.wotartist.com/mm.htm
Do you have any ideas?
Thanks Richard

rich1234

08-03-2006, 08:51 PM

Dear John, I have just realised that with all the changes made that I might have actually been working on the tooltip version before you modified it. I have just looked again at the tooltip versions I have and cannot for the life of me get it working on any other than the one it is using at the moment although I fear it may not be the one you worked on.
Sorry for the inconvenience
Richard

jscheuer1

08-04-2006, 03:43 AM

Now I am really confused. I kicked this idea around a bit, went back over the code I had here, etc. I really couldn't find or think of a reason for this happening that wouldn't be fairly complicated (if possible at all) to resolve. I did not go over your source code for your example of the problem in depth though. If you are saying that this is no longer a problem, that would be a relief. If it resurfaces, I think I would want to go over all of the files involved to make sure you are still using the finalized version we arrived at. This definitely was a problem before we instituted the xHolder and yHolder variables for FF and similar browsers (those that test positive for the document.addEventListener object). Those variables, creation of, tests for and use of had been written into the dw_tooltip.js file as well as the goTip() function and declared for the page and initialized by the created mouseover event. If a version you are using does not incorporate all those features, it would be little wonder, your having the problem described.

rich1234

08-04-2006, 09:53 PM

Dear John, I have compared the original version and what I presumed was your altered version of the tooltip.js and found your modifications, so I am actually using your modified version. It is here that I found differences with the original version.

Funny that this problem should occur. It seems that it behaves as it did originally, first mouseover eratic positioning and second mouseover it corrects itself to the right position. If there is no quick fix, dont worry, I can prob live with the quirk.
Thanks again
Richard

jscheuer1

08-05-2006, 04:32 AM

Hmm, I've looked over your code a bit now and things seem fine, at least with the sorts of stuff I was talking about before. However, I notice that some of your tip#.js files are using invalid HTML and many have no images. This cannot be helping.

I also noticed that if I clear the cache, then load the page, and then only move the mouse over the tips with valid HTML and images that exist, I have a much harder time getting the problem to occur.

My theory is that the processing time that gets hung up looking for images that aren't there and trying to interpret HTML which isn't valid is what is throwing things off in FF. It isn't that simple though so I added a little code to goTip() that should help as well:

With the addition of the above code and the use of tips which contain only valid HTML and that only link to images that exist, things should go much more smoothly.

One other thought, since the links on your demo page do not appear to lay out in the order that they appear in the source code, I am assuming that you are floating them, this may or may not be making it harder for the browser to position the tips.

It has no opening <a> tag but, has a closing </a> tag. This can throw off the entire layout of the page once it is written to it.

rich1234

08-05-2006, 12:05 PM

Dear John, I think that has done the trick. Thanks again for the effort. Yes that atag was a left over I had missed. When you say the links do not appear to lay out in the same way as the source code. Are you referring to the tips folder? I will have to change the numbering system as they do not list exactly as they are on the homepage.
Thanks again for the help.
Richard

jscheuer1

08-05-2006, 08:38 PM

since the links on your demo page do not appear to lay out in the order that they appear in the source code, I am assuming that you are floating them

No, the numbering of the tips to reflect their position in the layout is a human convenience. The browser doesn't care how they are numbered or named, as long as the correct tip can be matched by the code to the correct trigger.

I was referring to the css style of the triggers. They appear to float. This may or may not be making it hard for the browser to determine the x and y coordinates of a trigger event. Probably not.

rich1234

08-05-2006, 09:30 PM

Dear John, Thanks, all seems to be working.
Richard

rich1234

08-06-2006, 03:48 PM

Dear John, My curiosity has got the better of me and as I am now aware of the possibilities with the get function I was wondering if I perhaps had thought of a more complicated system than was perhaps necessary. I am now thinking, although it works a treat as it is perhaps it would have been simpler to, if it were possible, to instead of referencing individual files from my site to have had the original .js file full of all the tip references not download with the home page, instead, each tip inside the file referenced with the get function. I am thinking that maybe then it would have avoided the extra download for the three browsers, icab, etc and perhaps be easier to handle as one could visually see all the content of the tips in one place. What do you think?
Thanks richard

jscheuer1

08-06-2006, 07:49 PM

I'm not sure if I follow you exactly but, something like what you are talking about is certainly possible. There are two main avenues I can see:

1 ) Have all the tips in a single external file start loading after the page has loaded and test for the existence of a tip before fetching it, timing out and retrying if unavailable.

2 ) Have all the tips in a single external file load with the page.

These would both be different than what we have already worked out and the inevitable lag time that occurs while loading a tip or all tips would be experienced differently by users who do not have the tips cached. It would still be there in one form or another.

With what we have now, the lag occurs in smaller increments each time a tip is loaded for the first time, which occurs onmouseover of each tip.

With method 1 above, the lag would occur after page load and might go unnoticed but also, in a case where a user goes straight to the very last tip, could be quite significant on a dial-up connection. With this method, a situation could arise where so many timeouts are firing at once that the browser or computer hangs. This is also a potential problem with the current method but, much less so.

With method 2, the entire page load would be delayed by whatever lag is involved in loading the tips. This has the advantage of no tip being missing when it is fetched. On slow connections, this could mean significantly longer load times for pages.

All in all, our current method seems like the best compromise. No matter what we do, it takes time to cache a large file of tips and it takes some time to load each small file. These two realities cannot be sidestepped, only managed as we choose.

With all three methods, once a given tip or all the tips is/are cached by the user, lag time would be so minuscule as to be unnoticeable to all.

rich1234

08-07-2006, 08:01 PM

Dear John, Just like the original code referenced individual tips, but the file containing them had to be downloaded with the homepage, I was imagining if that page could sit on the server instead and the individual tips referenced from there, sort of like a database. I was understanding that we were referencing the content of a individual tip .js file directly, but we are in reality downloading the whole file first and not simply extracting its content.
I think I understand more fully now how things are working and from what you say, I agree that the way we have it at the moment is the best solution. It works perfectly. When I get it finished I shall show you the result.
Thanks Richard

rich1234

08-20-2006, 07:54 PM

Dear John, Do you know the best meta tag or any other method to force refresh of a page together with its corresponding external javascripts if someone has 'empty cache' turned off in their browser?
Richard