Most readers probably don’t realize that Little Green Footballs is semi-unique in the blogosphere, because the whole site runs on a custom-designed PHP platform, instead of one of the various open source or commercial blog packages. It’s a flat-file based system, which makes it very fast, and it has many security/administration features that evolved while battling some of the web’s ugliest trolls in the early days of LGF.

If you’ve noticed some oddities in the way things look at LGF for the past few days, it’s because I’ve been reworking big chunks of the LGF Blog system infrastructure, getting rid of dead code and slowly migrating toward a more XHTML and template-based framework. Man, don’t you love jargon?

In pursuit of this goal, one of the things I did was to revamp the way comments are displayed, getting rid of the HTML tables that used to enclose each comment, and replacing them with CSS-styled <div> tags. (This might help some of you whose Norton Internet Security program objects to the larger comment threads, by the way.)

Doing this, I ran into a thorny problem. When each comment was enclosed in a table, the table acted as a sort of virtual corral; if the comment contained an unclosed <b> tag, for example, the bold text only extended to the end of that table, and the unclosed tag didn’t spill over and affect the rest of the page.

When the comments are enclosed in <div> tags, however, there is no such protection. An unclosed tag affects every comment below it. Somebody forgets to close an italics tag and the whole page goes into italics mode.

And not to knock you lizardoids, but let’s face it—when there are ~3000 comments posted every day, the chances that some of them will contain malformed HTML approach statistical certainty.

So today I implemented a miniature version of the well-known (among nerds) HTML Tidy program, which fixes unclosed and unopened HTML tags, and also strips out all possible active content such as Javascript, with the help of an excellent PEAR class titled HTML_Safe.

This isn’t a challenge, by the way; I’m sure if you really work at it you can construct some HTML bad enough to confuse the HTML_Safe parser. But it should catch most of the common errors.

Since all this construction work involved modifications to lots of files, including our master CSS file, if you see anything that doesn’t look right, try emptying your browser cache and reloading the page to make sure you’re looking at the latest versions of everything.