I’ve been lacking on posting to this blog lately. I’ve not had much time with a big project looming at the office. I need to get back into the swing of things, but I digress…

I recently logged in to check on the status of this blog, and when I did, I found 10’s of thousands of spam caught in the Akismet trap. Had I needed to delete all of those spam messages by hand, it would have taken me weeks. Akismet is a spam recognition filter. It looks for words known to be associated with spam messages, it flags those comments as spam until I can deal with them. Thanks to the handy-dandy one-button deletion, removing all the unwanted spam was a cinch.

For the blogger, spam is becoming a huge problem. The reason behind it isn’t to get you (the author) of the blog to read the spam… it’s not even to get the readers of your comments to click the spam links. It’s to amass a huge amount of inbound links from sites all over the internet. Since Google (and other search engines) algorithms are trained to rank sites based (in part) on the number of incoming links, and these search engines don’t really know or care about the difference between weblog and website, having millions of incoming links posted on blogs everywhere is quite valuable.

There are other methods one might employ when dealing with spam, but in a lot of cases, it’s a hassle or burden to the commenter. Things like verification images, a simple spelling or math question are quite effective at eliminating the bot comment traffic, but forces the human  commenters to perform a trick to prove they’re human. While it’s becoming more and more common, it’s still burdensome to most and should be avoided when possible. That is why I prefer a more passive approach to dealing with comment spam using a method like Akismet.

Anyone who’s ever designed a website for themselves or for anyone else should have considered the cross-browser issue. A lot of times, the same content will appear differently from one browser to the next, which is a huge pain. You’ve spent a lot of time and effort to make your page look great, but there’s always going to be cross-browser concerns when it comes to the web.

The same problems arise when delivering a CMS solution to your clients. You have to be concerned about this on both fronts, the backend and the frontend. You need to be aware that your CMS (if it happens to be browser-based) might not always be loaded on the same browser or operating system for that matter that your clients are going to use. Depending on your contract, you might be permitted to enforce one standard on them, but as a developer you can’t count on that. On the frontend, you have to be sure the content you or your clients are producing won’t have the same problems showing in both browsers. This can be a tough one, because there’s never any way to know what a user is going to do with your software once it leaves your graces!

The good news is that most browsers are subscribing to XHTML and XML (of which HTML is a subset of tags) compliance. This is to say that for most formatting options, you are able to force a browser to display content according to a set of rules which exist for the content, independent of the browser. Implementing this is simple, but enforcing XHTML or XML compliance might uncover some things about your own coding and authoring style which you didn’t know you were doing incorrectly.

To force XML or XHTML compliance, you only need to add a single tag to your pages: The DOCTYPE tag. This tag looks like this:

It goes before the opening tag on your pages. In the example above, we’re specifying that the current page subscribes to the XHTML 1.0 protocol. This forces the browser to display the HTML as XHTML. *You might see somethings wrong which weren’t wrong before.*

I recommend all your pages include this tag. It will eliminate or really reduce the formatting gaps you’ve been seeing between Firefox and Internet Explorer, and Opera, and Safari…