A few months ago I began receiving spam from the form over at my XHTML slicing site at http://designerschopshop.com . The form itself is actually a slightly modified version of Dustin Diaz’s AJAX contact form, but for this tip you can use any form at your disposal. Lately though, I’ve been receiving 6-8 spam messages per diem. That’s just unacceptable. Wait, I take that back, ALL spam is unacceptable. Especially that super annoying kind that seems to be along the lines of:

Oedipus conflagration is among pacifists with trepidation annihilating mesomorphs http://cheappillsforyourdick.ru/pills/cialis “Hear ye!” behooves cornerstones of Tbilisi yearning for exhilaration http://hotbabes.anddickpills.com/buy/12387/pills dignified constitution

Ugh. Those emails make me want to have a sex-change operation so I can hit on a raging homophobic bodybuilder that’ll beat my ass after I tell him my truthful gender, just so the pain will be great enough to hopefully make me forget about the bastards that send that type of spam. It’s that intense.

Anyway, back to the topic at hand.

I didn’t want to go the Captcha route and wanted to keep it simple. What I did is create two input boxes for email. I gave one the id and name attribute of “email”, and the other “emailFalse”. I placed “emailFalse” before email, but I did this:

<label style="display: none;" for="emailFalse">E-mail address: (required)</label>
<input id="emailFalse" class="text" style="display: none;" name="emailFalse" size="25" type="text" />

<label for="email">E-mail address: (required)</label>
<input id="email" class="text" name="email" size="25" type="text" />

Then, in my validation Javascript (and in the PHP, just in case), I added something along the lines of this:

...
else if ( emailFalse.value != "" ) {
		alert("Not gonna work this time, bud.");
	}
...

In other words, you create an extra text box with an id/name attribute that contains “email” (I’m under the assumption that spammers in this case use a regular expression to know which field is which), hide it from normal users via a quick “display: none;”, and add a validation check that looks to see whether or not that field has been filled out. If the field isn’t left blank, it’s spam, so don’t send it. I’ve gone from 6-8 spam emails every single day to 0 in the last 4 days. Obviously, the only thing that keeps this solution working is spammers not knowing about it (yet) and coding around it (so far.) Even so, right now it’s working brilliantly, and that makes me happy.

Neat, eh?

One highly used method, which I’ll cover another time, allows you to place browser-rendered text in that menu. That’s useful for many reasons, but sometimes you don’t WANT browser-rendered text because you’d like to use a non-web standard font but wish to maintain the text in place for screen readers and SEO. In this case we want to create a menu using the “Cooper Std” font. So let’s get started.

First, the markup:

<ul id="menu">
	<li class="home"><a href="#">Home</a></li>
	<li class="locations"><a href="#">Locations</a></li>
	<li class="about"><a href="#">About Us</a></li>
	<li class="contact"><a href="#">Contact Us</a></li>
</ul>

That’s all. It’s very short and semantically relevant.

For this sort of method it’s best to create your images as sprites (or one big sprite, up to you.) What I mean by that is to take the image for the normal state and the image for the hover state and place them on one image, like so:

Then rather than calling a different image for the hover action, you just call the same image with an altered background position. You’ll see what I mean in the code. This helps stop the flicker you would get when the browser tries loading the new image when hovering, and it also lowers the amount of requests made to the web server. It would be even better to place all of the images into one big sprite map, but for the sake of this tutorial we’ll just create one sprite per menu item.

This, without styling, will produce the following results, so anyone in a text browser will still be able to see your links. So let’s start adding some styles.

body {
	margin: 0;
	padding: 10px;
	font-family: Arial;
	background-color: #303136;
	font-size: .75em;
	color: #333;
}
ul#menu {
	list-style: none;
	margin: 0;
	padding: 0;
	height: 25px;
	width: 520px;
}
ul#menu li {
	float: left;
	display: inline;
	height: 25px;
	margin: 0 10px;
}

This will give your menu a bit more structure. What you’re doing here is creating the menu as an unordered list with static height/width dimensions. With text-based menus you generally want to stay away from hard-coded height properties to account for users who wish to increase or decrease their font sizes and not allow that to break your design, but in this case that’s not necessary since these are images.

We’re floating the list items to the left to create a “seemingly inline” list out of what are block elements. The “display: inline” property is there as a fix for IE6 adding a random margin.

Next thing we want to do is add the images to each class along with their corresponding width properties:

ul#menu li.home a {
	background: url(images/menu_home.png) 0 0 no-repeat;
	width: 67px;
}
ul#menu li.locations a {
	background: url(images/menu_locations.png) 0 0 no-repeat;
	width: 119px;
}
ul#menu li.about a {
	background: url(images/menu_about.png) 0 0 no-repeat;
	width: 115px;
}
ul#menu li.contact a {
	background: url(images/menu_contact.png) 0 0 no-repeat;
	width: 136px;
}

Note the background position, “0 0″, which is the same as “left top.” This will show the image in its normal state. However, we’ve got a little problem here. The browser-rendered text is showing up, and the menu image only spans as high and wide as the text itself. We can fix that pretty easily with the following snippet:

ul#menu li a {
	display: block;
	height: 25px;
	text-indent: -999em;
}

Setting the inline anchor element to a block element allows us to specify its height and width explicitly. The text-indent will move the text completely out of view. Google frowns upon using “black hat” tactics such as hidden text for SEO purposes, but when you’re doing this to a few words in a menu in which the images you’re replacing the words with say the same thing, I’ve never heard of them having a problem with that. It’s when you start hiding paragraphs of key words out of view that Google decides you’re no good.

The only thing left to do is the hover state. This will do the trick:

ul#menu li.home a:hover, ul#menu li.locations a:hover,
ul#menu li.about a:hover, ul#menu li.contact a:hover {
	background-position: bottom left;
}

See that? All you’re doing is moving the background’s position to the bottom left rather than the top left. It’s the same image, but it gives the illusion of loading a new one. No flicker.

View the menu

Final touches

If you’re using Firefox, when clicking a menu item you’ll see an ugly dotted line border around the element going all the way to the left edge of the screen. This is something the browser adds itself. There’s a way to get rid of it though, just add a hidden overflow property:

ul#menu li {
	float: left;
	display: inline;
	height: 25px;
	margin: 0 10px;
	overflow: hidden;
}

Also, if you want to specify a selected state for a menu item, just add an ID attribute called “selected” and add this CSS:

ul#menu li#selected a {background-position: bottom left;}

View the final menu with selected item

Stereotypes.

Well all know what a stereotype is. It is, by definition, a widely held but fixed and oversimplified image or idea of a particular type of person or thing. Few, if any, know the root of the word. I believe it’s

[17th century] Latin I don’t fucking know.

However I’ve been wrong on occasion.

Personally, I like stereotypes. Not only are they hilarious, but it’s the perfect way to live your life and avoid a dragged out confrontation whenever possible. Let’s look at a few real-world scenarios and how to handle them in case you’re ever stuck in a similar situation, using stereotypes as our ever-definitive guide to problem solving: