The SitePoint Forums have moved.

You can now find them here.
This forum is now closed to new posts, but you can browse existing content.
You can find out more information about the move and how to open a new account (if necessary) here.
If you get stuck you can get support by emailing forums@sitepoint.com

If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

I'm not a programmer, and have only begun to scratch the surface of Javascript programming so I cannot tell whether anything is wrong or not. The script performs flawlessly in IE, FF, Opera and Safari for Windows.

The look-up table consists of 6 columns, as described in the annotation above. The reasoning for the first column is that if scripting is disabled, then so too should the visible prompt. Nothing looks dumber than E-mail: with nothing following (imho).

The tooltip text is optional, but one reasons that most users will appreciate seeing where a link is taking them, or at least some description of the link.

Columns 3 and 4 (2 & 3 , actually) are crucial, as they contain the values that will accompany mailto: in the hook reference. Columns 5 and 6 (4 & 5) are the visible portion of the link on the screen. If column 5 contains a value, it will be concatenated with @ and the contents of column 6. If c.5 is left empty, then only the regular text expression in column 6 is published. HTML tags are allowed in these two columns.

To temporarily disable a link, set the argument value [doMailto(arg)] to NULL, ZERO, or empty quotes.

Furthermore, structural markup may be included inside the script tags, wrapping the doMailto(); function call. The script output is inline, so may even be inserted in the middle of a sentence. Noscript tags are optional, but implementation of the tags inline can be a problem, since it's not valid. For this, I use p tags styled inline to bookend the script, giving the output the appearance of being inline. Then my noscript can contain alternate text inside p tags (again styled inline) and replace the link text (with a phone number or a link to the contact page) like nothing is missing.

I would greatly appreciate any comments or corrections to the above. Thanks!

I think what is most wrong with this script is that it's unnecessary. This sort of thing should be done on the server side, then all the other wrong things would be avoided. The biggest wrong thing is the use of inline scripting in the body (document.write). It's horribly messy and a pain to maintain. This could be done more easily and more cleanly with a more unobtrusive method. The use of eval() is also not good and likely avoidable. The "inValid" function also seems to be unnecessary.

What do you use the argument for doMailTo() ? A sample would be useful.

This one look-up table contains all e-mail link information for the entire site. On some pages, such as the contact page, there are multiple calls to the doMailto() function.

As it stands, there are no unique or special identifiers for these links, just the script tags, the numeric argument and the occasional noscript. The script does not require any class or id in the HTML, and no structural markup beyond its parent element (likely a p) and the contained optional span.

The anchor tag is in the script, so where do I put the id for getElementById?

I'm not sure how one would implement window.onload for this function under these conditions. Would I need a more complex script to sniff out all the function calls in a given page, and deal with them in place?

The way I did it, I've catered for the possibility of javascript being unavailable, thus meaning noscript tags are unnecessary. As it is, the anchor is already there with a "default" email address (the admin one) and so if javascript is available, it changes it to the more specific address.

If you're going to do this several times, then change the script to this:

So in the doMailto you now need to specify the ID of the anchor that you want to affect. If you look at the HTML code I posted above, the anchor has the id "contactus", so the only change in the HTML you really need to do is add a "default" anchor and give each one you want doMailto to change an ID.

Thanks, Raffles. Your example is really a thing of beauty. Is it feasible to place the init function in the head section of a given page, to maintain customization, etcetera? I especially like the fact that script tags are removed from the document markup.

I ought to have been more explicit about the real purpose of this script--to obfuscate e-mail addresses and keep them out of the hands of spam bots. I used to use a much more primitive method using unique functions and gobs of document.writes. Either way, the method has kept the inboxes of all my sites free of spam for years. So I have a wee problem with the mailto attribute being coded into the page--it defeats the purpose of the script.

However, just as my noscript usually provides a ink to the contact page, I could just code it that way, with unique ids, as you suggest. On the contact page itself, links could just point to the section with telephone and mailing address.

My recent goal was to create a better script, which I had (or at first thought). Thank heaven I stuck my neck out enough to learn the better way. It really was worth the effort.

Now I understand what this is all about. So obviously you need some other placeholder instead of a default email address. That's up to you of course, but you really should provide a method for people to actually be able to email you. Perhaps by linking to a contact form or by using an image. 99&#37; (or thereabouts) of people have javascript enabled, so showing an image to the other 1% is not too bad.

And yes, you can put the init function directly in the head to customise it as you go along. The rest can go in an external javascript file. You might have to put the script tags for the init function before those for the external file, though I don't think this should be necessary.

Okay, now I have another problem to deal with: conflict with Kravitz's Universal Bookmark Script dss_addevent. Is there some way to register these two onload events, but in the head section, to support page customization? The main scripts are all external.

As it was before, doMailto() had no associated onload events, so this was not a problem.

With my level of troubleshooting skills, DOM methods are obviously going to take a while for this old brain to wrap around. Up to now, and with what time I've had , it's been whatever gives the appearance of working, which one must almost be certain broke every rule in the book. From this level, it's almost enough to be able to go to sleep knowing that everything works as best as we can make it.

One grows awfully humble strolling along the halls of SitePoint, especially when one walks these halls unaccompanied, as most of us must have done at one time or another. It's easy to be distracted by all the portraits along the corridors. But more to the point, I should hate to squander all that's laid out before me. SP is by all accounts a community of experts that seem to agree on the things that matter most. I only hope it's not all lost on my poor old noggin.

It's not working because sendTo (11 in this case) is bigger than addr.length (which I believe was 10). The second line in doMailto() means that the function exits when y > addr.length.

If this is still the case when sendTo is less than addr.length, try and debug this by throwing a few alert()s in there at certain steps of the way. For instance, put one inside init(). Then if you get the alert when you load the page, you know window.onload = init is working. Then put one at key positions in doMailto until the alert box doesn't pop up - then you know the error is somewhere just before wherever you put the alert().

You don't need to specify the radix (second argument) in parseInt. And what do you mean by "listed in the DOM"? The addr array is simply a Javascript array, it has nothing to do with the DOM. The same with doMailto - it's just a JS function.

For dumping variables, with Firefox you can use dump(), which dumps them to the javascript console (have a look on developer.mozilla.org for documentation on it). I don't think it'll just do something like dump all variables though, you have to explicitly say which ones.

Is this live in one of those links you PMed me? Then I could have a better feel for what the problem is.

Man-oh-man-oh-man

Well, I'm back. This brings be right back to the original script inline approach I originally contrived, save now I can id them and grind out the rendering via the DOM. This will take some study. See ya next week!

The link class adds underlining to the link since it appears inline, in the context of the paragraph.

The output is the default if the script fails or is disabled plus a noscript message when scripts are disabled; and "Please drop us a line." for this instance when all goes as planned. The link href is the contact page by default, and the mailto: referred to in the addr array on successful completion.

The next trick will be to be able to cycle through an array of all element IDs that apply on the given page and apply appropriate content across the entire array. My attempts thus far have not worked... any takers?