Got Geek?

In a previous life (read: job) my colleague and I spent a lot of time learning css tricks and tweaks to get our work looking just perfect in all browsers under all conditions. We even discovered and developed a few of our own. No flash? No problem! No javascript? No problem! No brain? No problem – it handled IE as well!

Here’s one of the latest tricks from Eion Robb that’s worth an email home about: a gradient background on a stretchy box with rounded corners.

In summary,
Use an svg image for the background. They’re stretchy, and can have rounded corners.
They can’t usually be background images, so wrap your content in a div, absolutely position the image inside it to be the background.
Use a fallback for IE, e.g. VML, or a normal 4 corners/ 2 sides / top and bottom / no rounded corners solution.

Until a few years ago anyone with an email address had a very personal relationship with penis enlargement, cheap meds, and nude celebrities.

These days email providers are making a real effort to protect the helpless civilians from an ever increasing barrage of spam, and most are learning not to give their email address to questionable websites.

While said civilians go about their lives receiving “poked” notifications, and sending jokes they insist are “OMG the funniest thing you’ll ever see” we ask that you take a minute of silence to remember us webmaster@s, support@s, and contactus@s. In the name of business we climb from the trenches and publish our contact addresses to the enemy.

Before you decide this is Gallipoli all over again, we have been given a few defenses to use at our discretion.

1. Secret Question – We can start our defense by removing the blindfold. We realize spam bots exist, and that sooner or later they will try to take advantage of us. This is a poor man’s attempt at a Turing test where we can ask the user to answer a simple question the answer to which both parties are likely to know. “What animal is man’s best friend?”; “What is one plus two?”.
2. Hidden Fields – Most spam bots know that if they don’t fill out all of the fields (name, email address, message) their submission will likely be rejected. Thus they simply fill in all of the fields. This is where we can out-smart them by deploying our decoy. A hidden field. It’s not visible to the user and should never be filled in.
   A spam bot, on the other hand, reads the code and not the screen. All it sees is a field, thus it fills it with text.
   If your form is submitted and the hidden field isn’t blank, you’ve got a spam message and can safely discard it.
3. Sessions – Any good soldier is suspicious of a new face. The comrade to your left has fought by your side before. You trust him. When he submits the form he does so with a hidden one time code. It can be hidden so he doesn’t even know he had it.You gave him the code in a hidden field when he loaded the form, and kept a copy in his session. Upon submission you compare the code he’s offered with the one in his session. If he’s given you the wrong code, burn the message.
4. CAPTCHA – This is our super power. Like all programs, spam bots are bound by logic. A CAPTCHA leverages a human’s interpretive powers to deduce an answer a spam bot’s logic can’t. Again this is a secret code that our server knows.. but instead of giving it to the user in plaintext (even hidden a spam bot can still read it!) we encode it as an image. Sometimes even warp it or bury amongst tangles of superfluous lines. This makes the code unreadable to a program. Even one with character-recognition.

A good soldier doesn’t step onto the battle field unprotected. Neither should a web developer.

If you ask anyone “who are the biggest software giants in the world?” chances are their response will be:

In the evil corner: Microsoft; And in the good corner: Google.

As I am a big fan of playing devil’s advocate, my stance on the the accuracy of these reputations often varies depending on that with whom I’m discussing it. The dichotomy aside we can all agree these are metaphorical giants.

Google in particular has piqued my interested in the past few days in large part due to the failure of some Gmail accounts (mine among them). There are so frequently minor issues and outages related to Google that I find my programming ideals challenged.

In programming I am characteristically defined by my moralistic and idealistic upbringing, a good base education in software engineering, and frequent struggles with others’ esoteric programming methodologies. I thus strive to achieve solutions that are error free and that don’t cause disruption to the user.

This is not an easy road to take in modern programming environments. More often now we are reporting to a manager with knowledge limited to what he wants and when he wants, without any sense of the scope of the work he’s asking of you. It’s a constant battle for the time and resources to plan, to implement, and to test new features (hopefully in some variety of iterative process!)

Google, however, seem to have many minor issues with their software. Their flagship product – Google Web Search – fails an html validation with many more than a few errors. The translator fails in different areas. They have the Google Dance, coined to describe the phenomenon occurring due to the lack of synchronicity between their datacentres.

The issue that concerns me here is: nobody cares! There are murmurs and grumbles and gripes but for the most part people seem to accept it and move on with their lives. I was very inconvenienced by not having access to my work and personal email for a couple of days while Gmail refused me entry, and yet I’d still swear by it, and have no intention of discontinuing my use of the service.

Is it worth banging your head against your boss’ brick wall? Do you really need to tear your hair out on behalf of your less meticulous colleagues?

Perhaps, against everything your heart tells you, the answer is:

No.

Sure, it matches joe.blogs@example.com, or joe-blogs@example.com… But how about joe.blogs+work@example.com, or joe.blogs+support@example.com, or e=mc^2@example.com, or many other valid (albeit uncommon) email address varieties?

Email address validation and storage is a rarely considered but often encountered  concept on the web.  Many developers thoughtlessly implement validations that prevent legitimate email addresses being entered into a membership, support form, or being subscribed to a newsletter.

The most common barriers I’ve encountered are length limitations, domain black lists, or imitation standards compliance.

Length Limitations

One of the implementations of this blunder that I’ve come across is database field lengths. Arbitrary lengths are painfully common.  Next time you’re designing database and think to yourself “100 characters seems long enough” please stop, and ask yourself why you’re imposing a length limitation. And why 100?

• By old standards (RFC822) an email address could be up to 320 characters long.  That’s 64 (local user) + 1 (”@”) + 255 (domain).
• And by new standards (RFC 2822) up to 992.  That’s 1000 – 6 (”From: “) – 2 (\r\n).

The other reason email address lengths are often limited is more forgivable as it is conceivably the result of migrating from a specifically chosen login username to using an email address as a login.

Domain Black Lists

Spam is now an accepted inconvenience. But blocking @hotmail.com, or @gmail.com email addressed from using your support form is a misguided defense mechanism. Amongst the proportionally few spam email addresses with each provider are many legitimate users. Don’t punish them for your site’s popularity in a spam network. There are a variety of more effective anti-spam techniques you can implement.

Standards Compliance

This is my second most hated web development faux pas. One that even MSDN .NET documentation has screwed up for 7 years. Disallowing characters like +, %, *, $. At first glance a developer might see these as harmful, but such a developer would be amateur in thinking so. In any syntax where a character might be considered something other than it’s literal meaning an escape sequence is available. For example + and % are special characters in a url, but a thorough developer should encode them to %2B and %25 respectively.

I recommend the limit to your email validation to checking for the “@” character, and testing the domain part for a “.” character. This will ensure your users have at least attempted to enter an email address. The rest will be resolved in what experienced developers say is a significant part of any email validation:  sending an email. Here you may find such an address as e=mc^2@example.com is valid, while  john@example.com may not exist and thus be invalid.