[DHTML] Email Protector

1) CODE TITLE: Email Protector

2) AUTHOR NAME/NOTES: Scott Bruce, http://www.abacusit.ca/

3) DESCRIPTION: This is just a simple JavaScript to hide email addresses in HTML links, it doesn't involve scrambling or encoding simply breaking the key things that identify an email address - the @ symbol and the mailto: protocol. It separates the user from the domain and assembles it in the function call and redirects the window's location to the fully assembled email address preceded by "mailto:" - In theory this will trigger the browser's mailto behavior. I've only tried this on a couple major browsers (IE & FireFox) but so far so good.

I'm not sure if anyone else has published a script like this, I would imagine so considering it's simplicity - but it never hurts to throw it out there, in any case here's my version. Any feedback would be appreciated.

4) URL TO CODE: Code attached.

or, ATTACHED BELOW (see #3 in guidelines below):

What about users that have scripting disabled, those that use Web-based mail services, or even those that don't have their system configured to use the mailto scheme? All of these are to be found on the Web, and the second group is particularly prominent with many people opting to use Hotmail, Gmail, and the like, instead of a mail client and SMTP.

If an author wishes to be contacted directly, they should include their address in a link and use a spam filter to remove any junk. It's probably best not to use a personal address anyway (in case anyone wants to object on those grounds), but rather create a mailbox set up especially for receiving correspondence related to the site. One may also want to consider providing form mail in addition to an e-mail address. Ideally, that form would have to option to CC the mail to the sender so that they may retain a copy for their own records.

Trying to 'protect' mail addresses in this manner only makes it more difficult for people to contact authors, which is rather perverse, considering the aim of providing contact details in the first place.

Mike

Hmm...Good point - In my "quest" to save email addresses from spam harvesters I neglected to consider those who don't use mailto. I use GMail heavily myself but I just work around the mailto part, which is a bit much to expect from the average user - I've just been doing it so long now I don't even think about it.

As for those who choose to disable scripts, and this may be wrong but it's just how I feel on the issue, I don't feel terribly obliged to cater to them. They've limited the capabilities of their browser by choice; while it does afford a higher level of security it also limits functionality - that just goes with the territory.

Thanks for the reality check,
Scott

Quote:

---

Originally Posted by GrimmyTheGrimReaper

As for those who choose to disable scripts, and this may be wrong but it's just how I feel on the issue, I don't feel terribly obliged to cater to them. They've limited the capabilities of their browser by choice [...]

---

What about those to which your assumption doesn't apply? There are even modern browsers (so saying 'Upgrade!' is arrogantly futile) where an ECMAScript implementation isn't present, or where the DOM interface is less comprehensive than in other browsers. Even so, limiting the capabilities of the browser doesn't mean that a site should stop functioning properly.

When I disable images (rare, but I still do it occasionally), I shouldn't be unable to navigate through a site just because the author couldn't be bothered to include adequate alternative text. The same applies to scripting. Except in unusual circumstances, a site should be useable with only HTTP and (good) HTML. It might not be pretty, and it might not even be as convenient to use as it would be with scripting in use, but it should still work.

The majority of client-side code can be replicated server-side. Indeed, some code should be replaced with a server-side implementation. It is usually through laziness, ignorance, or incompetance that client-side code is written without due regard to a useable fallback, not because that fallback is not feasible. It is a testament to the bleak state of this aspect of Web development that the situation is so pervasive.

Mike

As I said Mike, that's just how I feel on the issue - ultimately my feelings on things grow and evolve over time - no doubt I'll get to a point where I'm just as fired up and frustrated over these things as you are. But, the reality of the situation is that I'm self-taught and still in the process of learning what it is to be a good web developer.

As best I can I try to incorporate best practices as I go, but there's a limit as to what I can reasonably put into practice at any one time. The approach I've chosen to take is to try and cater to the largest cross-section of users with the skills I have first, and worry about the rest later - that's cold and far from ideal but it's usually what's realistic given my time constraints and level of skill at any one time.

The bright side to this is that the scope that comprises the largest cross-section of users is consistently growing as my level of skill increases. Casualties, unfortunately, are unavoidable - I don't mean for this next part to sound saucy, but I'm not sure how else to put it - I can either get the job done and learn from the experience or I can entrench myself and strive for nothing less than the ideal design and get nowhere - the equivalent of trying to run before I can walk.

In any case, this has strayed far from the original point of this whole thread - I just thought it was a simple way to hide an email address from a spammer - and now we've spiraled off into the state of web design and my personal approach to it. Anyway, this has probably gone far enough, I'll leave it at that.

Take Care,
Scott