reCAPTCHA and XHTML

I’ve been relying on reCAPTCHA using the official WordPress plugin to protect against spam on the blog for some time. All the while, I’ve just assumed whatever markup it spat out would be XHTML 1.0 Strict. Then yesterday, while tinkering with something unrelated, I decided to run the blog through the validator and noticed the reCAPTCHA stuff was far from valid XHTML. I thought this was odd so I searched for a discussion on the subject, but I didn’t find much. I did run across a discussion on the reCAPTCHA mailing list though. In it, I found this little bit:

The reCAPTCHA team is not going to be developing XHTML fixes.

And that’s from someone at recaptcha.net. Why not just release a quick fix and get it over with? Is it just me or is this really odd behavior? Why wouldn’t they make it valid out of the box? The fact that you have to hack the scripts in order to use it with XHTML is a huge turn-off for a lot of people.

As a result of this, I’ve decided to remove reCAPTCHA from the blog in protest. Come on Recaptcha! Get with the program.

TFOOT in the table header

Today was my first encounter with the HTML tag <tfoot>. It’s a tag that represents the footer of a table. There’s <thead> for the header and <tbody> for the, drum roll, body. I carefully constructed the markup for my PHP script that listed incoming orders in a e-commerce application. My plan was to sum up the order totals and display them in the footer of the table. I did this by adding each order total to a variable in the tbody loop and then echo’ed the sum in the tfoot. Everything was working beautifully until I decided to run my markup through the W3C validator. This turned up:

document type does not allow element “tfoot” here.

I looked through the markup and couldn’t find anything wrong with it. I then had a look in the HTML 4.01 spec regarding tfoot and noticed the following:

TFOOT must appear before TBODY within a TABLE definition so that user agents can render the foot before receiving all of the (potentially numerous) rows of data.

The footer must appear before the body! Call me stupid, but why would a browser want to display the footer before the rest of the table has been rendered?

In my case, I had two choices. I either jump through hoops and somehow calculate the order sum before I start outputting the body of the table (a rather complex operation, I might add) or I just leave tfoot out of the equation completely and use a regular table row in the body to represent the footer. I chose the latter.

A decent torrent client for OS X

I hope the post heading didn’t deceive you. You see, there is no such thing. Lets see what our options are:

Azureus - the Windows Vista of torrent clients. This is what I use today. Every time I start it up, a piece of me dies. This thing has one thing going for it and a million thing going against it. What’s good about Azureus is that it actually works rather well. Download and upload speeds are generally very good and the client is friends with most private trackers. It also supports all the bells and whistles of the Torrent world such as DHT and encryption. Now, the issue with Azureus is what I hinted at when I compared it to Windows Vista - it’s a resource hog. Not only is the application itself immensely complex and bloated, but to make matters worse, it’s Java. That means you have to live with the overhead of the Java virtual machine whenever Azureus starts up.

The fact that it’s Java usually means another thing, it’ll look like hell. I have yet to encounter a Java application that looks good on OS X or Windows. The applications sometime try to mimic the widgets and controls of the operating system it’s running on, but it never quite looks right. In the case of Azureus, they haven’t even bothered to make it looks remotely Mac:ish. Don’t stare directly at the following image, it might cause permanent damage.

The hideous user interface of Azureus

What the hell happened there?

Moving on. The next client on the list of potentials in Transmission. It’s actually a rather nice client with a solid looking UI and a decent feature set. My issue with Transmission is that I just don’t get the same speeds as I do with Azureus. Download speeds are pretty much the same, but for some reason, it won’t upload anywhere near as much as Azureus does. The UI is nice, but I’m not a big fan of the main listing where each torrent takes up a lot of screen real estate. When you have 30 torrents in the list, it quickly gets difficult to get an overview.

Next on the list is XTorrent. This client is arguably the best looking client I’ve ever seen. Good looks aside, it has a few issues. First of all, it is based on libTransmission (the torrent library used in Transmission) and most likely has the same speed issues as Transmission. Secondly, it costs $26. I have no problem at all paying for good software, but before I do, I like to get an opinion of how well the software works and that’s just not possible with the unregistered version of XTorrent. It’s severely limited. Lastly, the person behind XTorrent, David Watanabe, has a reputation for being a real a**hole and that just doesn’t fly with me.

Finally, we have BitRocket. BitRocket appeared on the scene a little over a year ago and personally, I thought it looked extremely promising. That being said, a little over a year has passed and not a lot has happened. The website is, should we say, spartan and the forums have been down for some time. I’m not sure if the project is abandoned or what is going on, but this doesn’t bode well.

Apart from the 4 clients I’ve mentioned, there are a few more. The only two I can think of right now are Bits on Wheels and Tomato Torrent. Nothing I would recommend though.

What the OS X world needs is µTorrent. The developers claim that a port is still in the works (nice forum software btw), but this song and dance has been going on since 2005 and I’m starting to doubt whether it will ever happen. You can run µTorrent in OS X using Darwine or CrossOver Mac, but that’s like hooking up a caravan to a Ferrari.

PHP eats my newline

Have a look at the PHP manual page on Instruction separation. In particular:

The closing tag for the block will include the immediately trailing newline if one is present.

What this means is that a newline character directly after the PHP end tag will be stripped out. Have a look at this code.

Line 1
<?php echo 'Line 2'; ?>
Line 3

Looking at it, one would expect the output to be three lines. However, due to the aforementioned oddity, the output is:

Line 1
Line 2Line 3

This might not be the end of the world for most people because it hardly ever has any impact on the actual appearance of your pages. However, for someone like me, it’s very annoying. You see, I am extremely anal when it comes to the appearance of markup in my scripts. If I see a line of markup that isn’t properly indented or if I see missing or redundant whitespace, my programmers OCD kicks in and I start adding “\t” and “\n” all over the code.

The manual doesn’t mention anything about the reasoning behind the behavior and I haven’t been able to find anything online on the subject. The only reason I can think of is that the behavior is there to prevent a single newlines at the very end of scripts. This in turn to prevent “Headers already sent” errors when sending HTTP headers (for example cookies). Still, I think it hurts more than it helps.

Putting in the hours

for (i = 0; i < ∞; i++)
{
    Start with a regular 8 hour work day.
    Come home and have dinner.
    Then sit down for another 5 or 6 hours of work on other projects.
    In the meantime, try to get your car repaired and plan a wedding.
}

Not recommended.

Updated: Forgot the infinite loop!

Useful sites

Looking for online software downloads?

Download source code, PHP, ASP, CGI Scripts at Source Code Online.