Archive for June, 2008
Impressive Links of the Week (Firefox Week)
Saturday, June 28th, 2008Power User’s Guide to Firefox 3
Mozilla logs 8 million-plus Firefox 3 downloads in a day
Must-use Methods to Spam-Proof Your Email Address
Wednesday, June 25th, 2008Working for a busy web development & hosting company exposes me to the sad fact that well over 90% of website owners today do virtually nothing to protect themselves from email spam. Spam filters are good, and they’ve come a long way, but they are not the perfect solution — far from it. Even with a close to perfect spam filtering system in place (which never happens), users will still be inclined to waste time sifting through junk mail just to ensure that nothing was incorrectly filtered.
In this post, I’ll describe a few solid methods to ensure that your email address will not be harvested by “bots” or other automated programs that harvest emails from naive website owners.
The best junk mail folder is no junk mail folder
Okay, that sub-heading is a little misleading, since I don’t honestly believe it’s possible to eliminate the junk mail folder — even if the methods outlined below are used. But with good solid spam-proofing methods carefully followed, I believe that the junk mail folder can be empty 99% of the time, if not more.
1. Don’t use predictable user names for your email addresses
This is one of the methods that I haven’t really seen promoted much, and I’m listing it first because it really gets to the root of the issue. When I registered a domain name last year, I started out using a very typical email address: info@mydomain.com. Guess what? Within days, even though that email address was not listed on my site, I started getting spam in my inbox and junk mail folder regularly. Spammers know that as soon as a domain is registered, and a site goes up on the web, the “info”, “admin” and “sales” email accounts are likely used first. But don’t fall for this all too common mistake.
It is absolutely not true that potential customers are going to “guess” your email address using one of the “common” email prefixes (info, admin, support, etc). That is quite ridiculous. People don’t guess phone numbers, or bricks and mortar addresses; they look them up. The same applies to email. If they want to know your email address, they’ll look it up on your contact page, or else they’ll ask you directly, if that is an option.
So, choose an email address that is unique and cannot be “guessed”, but is still memorable and is associated with your product or service and the related company department. For example, instead of sales@yourdomain.com, use sales-dept@yourdomain.com. Or instead of support@yourdomain.com, use techsupport@yourdomain.com.
2. Do not display your email address on your web site
This is a tougher one, but it can be done, while still allowing users to send you email. There are tons of Javascript methods available online to “cloak” your email address, and many of them are easy to implement. If you are a novice web developer and aren’t familiar with any of these methods, then take the time to become familiar with them. One good one will do, and it will pay off in the end for your own sites, and for any client sites you work on.
There are also similar, simpler methods that involve replacing characters in the email string with HTML character codes. For example, this code & #64; (without the space after the ampersand) is equivalent to the @ symbol. You can also replace the entire email address, or parts of the email address with this kind of code, and so it is less likely that an email harvesting program or spider-like bot will find your address. I personally like to mix up regular letters with HTML character codes to keep it inconsistent, just in case the bot is programmed to sniff out the character codes and interpret them. But the JavaScript methods are much more secure, from my experience.
Also, be sure that the clickable link that appears for the user to see on the page does not contain your actual email address. Instead use a “call to action” phrase inside the anchor tag. For example:
This ensures that the bots will not be able to find your email address in the code or in the web page’s text. Definitely a safer way to go.
3. Use a contact form instead of an email address
This is a simple one, and is probably the only guaranteed method. The fact is, although the methods above work quite well, a human can still find your email address – it just takes more effort. So, if you want to completely avoid all spam, then I would suggest using a simple contact form. Don’t forget to validate the fields using JavaScript and a server side language, to ensure the fields are filled out correctly, thus reducing form submission spam.
4. Use a separate email address for subscriptions, forums, etc.
I have a hotmail address that I’ve been using for about 7 years, and I have never received a single spam message in it. I have never given out that address to anyone except close friends. But for newsletters, subscriptions, forum registrations, online purchases, etc., I have a completely separate email account. I expect junk in that one, so it’s no big deal. So take the time to register a separate “subscription only” email address that you don’t mind being public. That way, the email you use for business communications will not be made public – except where it appears on your website in the protected manner I’ve listed above.
What about using an image, or spaces, or the word “AT”?
I personally don’t like methods like making your email address an image, or putting spaces in between the characters in your email address, or using the word “AT” in place of the @ symbol. I think those are amateurish solutions, and don’t belong on professionally developed websites.
What does this have to do with front end web development?
Although much of the information I’ve presented here is fairly well known to experienced web developers, I feel it hasn’t been taken seriously as “best practices” in web development. I don’t think web developers should wait for the client to suggest methods to secure their public email addresses. They probably will never suggest such a thing; they probably don’t even know it’s possible.
It’s the webdeveloper’s job to offer the client the best possible web site solution, and this includes taking measures to ensure the client’s email addresses are protected from, or at the very least, minimally affected by, unsolicited email.
Impressive Links of the Week (June 16/08)
Monday, June 16th, 2008Alertbox: Writing Style for Print vs. Web
How to Recover Deleted Files with Free Software
AP Goes After Bloggers Under DMCA
IE6 Ghost Text Bug (with multiple solutions)
Monday, June 16th, 2008It is a sad fact that, according to W3Schools browser statistics, Internet Explorer version 6 is still holding one of the highest percentages of use for one browser version (28.9% — although I personally think that number is somewhat inflated for reasons that I’ll save for another blog post). Unless the site you are working on has specific stats that show a much lower number for IE6 users, then it is still necessary to ensure that IE6 is displaying your markup reasonably well.
What is the IE6 Ghost Text Bug?
Due to a bizarre rendering error in IE6, a well-organized, W3C-compliant web page that contains clean, semantic markup, and that looks perfectly fine in all other browsers (IE7, Firefox, Opera, Safari, etc.), will sometimes display duplicate text in a DIV that is floated and is followed by an HTML comment. The consensus is that the bug occurs when multiple comments are placed between a series of floated DIV tags, with the actual bug taking place inside the final floated DIV.
Multiple proposed solutions
In the case of this bug, we know exactly why it occurs — because of the HTML comment that appears after the final floated DIV. So the easiest solution is to just delete that final problematic comment. But if you’re like me, and you organize your markup by commenting your divs, then that may not be a satisfying solution. So in this post I’ll provide a number of proposed solutions to this common IE6 bug.
SOLUTION: Debug the page from bottom to top
Unfortunately, sometimes even removing the final comment that appears after the affected DIV will not solve the issue –hence proper debugging techniques need to be used. In some cases, I’ve had dozens of HTML comments appearing in a page, and removing the last one did not fix the duplicate text. So I simply went through the markup in reverse, starting from the problematic DIV and working my way up. I proceeded to remove HTML comments one at a time, until I found the one triggering the bug.
SOLUTION: Place the comment inside the closing DIV tag
Since I don’t want to eliminate the comment, the method I usually use to fix the issue is to put the comment inside the closing DIV tag, so it would look something like this:
<p>Some content would go here</p>
<!– my_div_name ends –>
</div>
SOLUTION: Adjust the margin to a negative value
I have never personally had to use this solution, as I normally use the above, but some sources say that putting a negative left margin on the affected DIV will fix the problem (note: on a right floated div, you would apparently have to use a negative right margin). Of course, you would have to use an IE6 only hack to ensure this margin change doesn’t affect your layout in other browsers, but I don’t see the reason to resort to this, as it seems it would harm your layout in IE6 anyhow — so you would have to adjust something else on the page to compensate. But this is a proposed fix nonetheless, so you may want to be aware of it.
SOLUTION: Use “display: inline”
Some have said that they’ve had success using this fix to elimate this duplicate text problem. Again, you would use an IE6-only hack and apply “display: inline” to the affected DIV in your CSS. Similar to the previous solution, I can only foresee other issues arising if this is implemented. Also, I personally have tried this and have yet to see it work. Obviously this ghost text bug occurs under a number of different circumstances, and thus some solutions don’t work in certain situations.
SOLUTION: Conditional comments
I have used this method, and seems to work perfectly. It also has a few extra benefits for developers that don’t like to re-organize their code (like me!). So I used this one recently and I think I’ll be using it exclusively in the future, should I run into this bug again. To implement this, just replace your existing comment with an IE conditional, like this:
The benefits of this fix far outweigh the one drawback. Firstly, the only drawback is that it looks ugly and out of place inside your perfectly organized markup. But the first benefit is that it keeps the comment exactly where you want it. And the second is that, similar to IE6 CSS hacks, when IE6 finally falls out of general use, all you have to do is remove this conditional and replace it with a normal HTML comment (assuming that you’ll need to go back into the markup at some later date).
I have no HTML comments and I still get the bug
I have never seen this bug occur on any of my sites without the use of HTML comments, but I have read blog posts where people have solved the issue and made no mention of HTML comments, so it’s possible that there were no comments used and it still occurred. If this is the case, then the solution seems to be to either use one of the alternative methods mentioned above, or else eliminate white space in your HTML. One blog post online seems to indicate that white space caused the ghost text to appear. So, you could systematically go through your markup using the dubugging method mentioned above and narrow down which particular chunk of white space is causing the problem.
SOLUTION: Use non-breaking spaces (not recommened)
This is a very poor way to fix the bug, but technically it does produce the desired result, is quite easy, and is pretty much guaranteed to work every time on non-linked text. Since the bug causes the last few characters (usually just two or three letters) to appear duplicated a line or two below, then you can just add a few non-breaking spaces (using ) to the end of the affected paragraph of text, and thus the duplication will occur only on the non-breaking spaces, so it will give the illusion that the bug is not occurring, even thought it still is. Of course, this is not a recommended solution as it gives your markup and “old-school HTML” feel, and will only work if the duplicated text is not hyperlinked.
IE6 Ghost Text conclusion
Ultimately you will have to use whatever method works best for your style of coding. I’ve tried to exhaust all the possible solutions above, so if I’ve missed anything, please let me know, and I’ll add some footnotes or supplementary info in the future.
Impressive Links of the Week (June 10/08)
Tuesday, June 10th, 2008Giant Nintendo Controller Coffee table
Should a web developer be concerned with SEO for client sites?
Friday, June 6th, 2008Every developer knows that SEO is a huge part of online marketing. Freelance designers and programmers spend countless hours optimizing their sites, link building, and validating their pages in order to get noticed, or to get to the “top of the heap”, as they say.
Pitfalls of a big development firm
But I find that in a high-volume, fast-paced development environment in which SEO has not been included in the budget, good solid — and sometimes very basic — SEO practices are often overlooked during development. Add to this the fact that many developers may end up working on the same website, and so, good SEO practices are even less likely to end up in the final markup.
Enter the “HTML guy”
But as a front-end developer, I feel it is my obligation to give the client as much basic site optimization as possible. In recent projects, I’ve been making a habit of incorporating many of the SEO practices that I’ve been learning about and researching.
Of course, when final page copy and site structure have already been decided upon before a single HTML tag is ever typed, there is only so much a developer can do. But even those few things that can be done will help the website make the leap from virtually no search engine findability to average or better, and potentially very strong findability.
I’ll give a couple of examples of some basic things that I’ve been doing to ensure that, at the very least, the site is SEO ready, even if it is not strongly optimized.
Some basic SEO optimization is not difficult
For one, I ensure that every page has a unique title tag. Although the client has the option of putting SEO friendly copy into each title, I find they almost never do. But a respectable web developer will put in the tags and fill in the basic page name.
Also, since I am responsible for actually slicing up the Photoshop file that contains the finalized design, I try to use as few images as possible. At my current job, we have a fantastic graphic designer who makes many image-heavy websites, but often it isn’t difficult to ensure that basic page copy is rendered as normal text. Our designer is familiar with basic web typography and this helps a lot, so he doesn’t use any non-standard fonts for titles and content. Of course, I could be lazy and include all headings as images, but I feel, as is the point of this article, that it’s my obligation to make the site as SEO-friendly as possible. Even if that just means making it ready for future page optimization.
Another good practice that I’ve developed is trying to ensure that each page has only one <h1> tag. Rumor has it (and we can never really confirm this), that Google will penalize a page that has more than one <h1> tag. Since this tag essentially represents the “heading” for the page, Google will give it more value than other text.
The benefits of basic SEO habits
There is a lot a web developer can do to help SEO on a site — and I’ve provided a few examples above. SEO should never be viewed as a separate entity altogether. It is a very integral part of web development, and should be viewed as such by all front-end coders who want to adhere to standards and best practices. And let’s not forget the extra-benefit of having developed sites that receive large amounts of traffic and increase profits for the client. I think that alone is reason enough to embrace basic SEO practices in all front-end development assignments.
Impressive Links of the Week (June 2/08)
Monday, June 2nd, 2008Here is the first installment of my Impressive Webs “Impressive Links of the Week” posting: