Above the Fold: The Blog

After three hours of staring at books, installing a plug in for Firefox that allows me to render pages (screenshots only, but good for clues) as various versions of Internet Explorer and tearing out my hair, I figured out the problem. I even worked out why the layout worked a few weeks ago and doesn’t work now.

It’s the code that I was cleverly sharing. More importantly, at certain screen resolutions (i.e. anything not widescreen) that code overflows the content area because of the way that the <code> tag works. Unlike normal text, anything inside a <code> tag does not flow onto the next line. It simply continues in one long line until there is a carriage return.

Firefox, Opera, IE7 et al. cleverly decide not to do anything to the content boxes and just allow the stray lines to overflow. IE6, on the other hand, decides that this calls for changing the box sizes to accommodate the overflow, thus breaking my tried and tested three-column layout tricks.

Actually, it belongs to A List Apart, but that’s beside the point.

So I had two options. I could edit the posts below to introduce appropriate line-breaks, but leave the layout still subject to potential breakage if I ever try that again. Or I could fix the layout.

I chose option two and added the following to the overrides css file:

#main-content {
overflow: hidden;
}

And ta-da! IE6 now works exactly as it did a few weeks ago. My problems are solved.

It is moments like this that some kind of unified approach to how browsers implement standards such as CSS starts to really appeal. It’s a shame that the idea will remain just a fantasy.

After my triumphant declaration yesterday that I had fixed all the compatibility errors, it turns out that the blog is now broken in IE6. This would be the blog that worked perfectly in IE6 but broke in IE7, of course!

More frustratingly, when I restore the old theme (without the modifications) it is still broken in IE6. That is the part that I don’t understand because, five weeks ago, it was perfectly happy in IE6.

The only changes that I have made are to separate out the hacks that render things correctly in IE so that IE7 can read them and restore the Blogroll. I changed nothing in the old theme so, theoretically, there should be no reason for the old theme to break when it previously worked. In fact, I changed none of the CSS apart from doing the conditional comments trick to ensure that the overrides file could be read. And even more frustratingly, it’s the same styles and basic HTML layout as are used in the main site and that works perfectly in IE6 and IE7.

So it’s off to perform some Google-fu and work out why the blog has broken. I’m starting to wonder whether it’s the HTML rather than the CSS. Hmm.

A while ago I noticed that the Blogroll had disappeared from this blog. As with so many things during my final months at my previous job, I just didn’t have time to dig through the WordPress documentation to find out why.

Today I did some nosing around and discovered that the old WP tags to generate the blogroll had been deprecated and removed a while ago. Hence the non-working blogroll.

One of the nice things about WP is the resources out there documenting how all the nuts and bolts work. If you really wanted to, you could customise WP to run an entire, complex website and not just a simple blog like this.

I came up with the new wp_list_bookmarks tag that was needed to replace the old code. Part of me sighed at the idea of upgrading to break people’s blog templates, but another part of got a little excited about the fact that this would be much easier than my old code.

To demonstrate, here is the old code:

<?php
$link_cats = $wpdb->get_results(
"SELECT cat_id, cat_name FROM $wpdb->linkcategories");
foreach ($link_cats as $link_cat) {
?>
<li id="linkcat-<?php echo $link_cat->cat_id; ?>">
<h3><?php echo $link_cat->cat_name; ?></h3>
<ul>
<?php get_links($link_cat->cat_id, '<li>', '</li>', '',
FALSE, 'name', FALSE); ?>
</ul>
</li>
<?php } ?>

Using the new WP tag, I have one line of code:

<?php wp_list_bookmarks('title_before=<h3>&title_after=</h3>'); ?>

It does essentially the same thing, only much less wordy. The wp_list_bookmarks tag defaults to ordering by name (something that had to be specified in the get_links tag) and retrieving all the categories. The one frustration is that it defaults to putting the category names in H2 tags, but that’s what the title_before and title_after parts of the argument do - change that behaviour to H3 tags so that I don’t have to re-jig the CSS.

WordPress has its negatives (the frequency that you have to upgrade and the time it takes to do the upgrade being the biggies) but it does have some nice features hidden under the bonnet. I’m not sure that anyone could use them if they don’t have at least a basic understanding of PHP first, though!

I have been intending to go in and fix Above the Fold for months. Months and months and months. Why?

When Internet Explorer 7 was released they fixed a number of the escapes that had been used to target IE with fixes where the CSS doesn’t render correctly. Sadly they didn’t fix the CSS rendering. The layout on this site uses some clever CSS to create the three-column layout without needing to resort to tables yet maintaining the liquid layout so that it scales to any screen size.

I did some research when IE7 was first released and found some references to fixes. They involve stripping the overrides out of the main CSS file, putting the overrides into a new file and then using conditional comments to link to that new file. e.g.

<!--[if IE]>
<link rel=”stylesheet” type=”text/css” href=”ie_overrides.css” />
<![endif]–>

The bit that I was scared about was working out exactly where those overrides were in the default layout file. There always seemed to be something else that needed to be done more urgently so it got left.

And left.

Today I dusted off that default CSS file, went through it with a fine tooth comb and discovered that the six lines of code that I needed to move (much less than I’d imagined) had all been grouped together and commented as IE hacks. It took me less than thirty minutes to sort it out - if only I’d know that months ago!

The slightly more complicated part was repeating that process for the WordPress files. In the default stylesheet for WP I’d helpfully put all the IE hacks at the end so they could easily be found. The more difficult bit was working out what link to use for the IE override stylesheet. A bit of Google-fu solved the problem and I added this to my header file:

<!--[if IE]>
<link rel=”stylesheet” type=”text/css” href=”/ie_overrides.css” />
<![endif]–>

I’m quick surprised by how much easier it was to sort out than expected. In fact, the most complicated part of today’s operation was upgrading the WordPress installation! That really isn’t my favourite job but it does have to be done for the security updates if nothing else.

With a little help from a friend, I managed to fix the acorns in the left-hand menu! It turns out that IE gets thoroughly confused occasionally and needs some elements specified in the CSS down to the nth degree before it will work properly. Sadly, I haven’t been able to replicate the same trick on the right-hand menu so I’ve done a little hacking around so that the right-hand menu has no acorns. Poor, deprived menu.

The acorns are still there in all other sensible browsers, though.

That trick also doesn’t work with the blog post titles, so they’re still being hacked around to work dully in IE and work in full, maple-leaf glory in Firefox, Opera etc.

One day, Microsoft will release a browser that actually does the same things that other browsers do and we’ll be able to junk all the hacks. Until that day, we just have to find new ways to work with the ‘undocumented features’.