September 24, 2004
Website Updates and Upgrades
I’ve decided to make a few changes around the site in order to ease future design updates. The previous underlying HTML, although providing good consistency across many browsers, was one of my earliest attempts at leaving behind <table>-based layout and therefore, it was both heavy with nested <div>s AND difficult to restyle through the use of style sheets alone. The newer HTML is still pretty consistent across various browsers, but it’s a hell of a lot cleaner! The only area where I’m slightly disappointed are the weblog pages. Let me explain why…
The new pages are made up of either 4 or 5 main areas, depending on whether the page is made up of 2- or 3-columns. I decided that in order to cut out excessive markup, I would simply apply a float:left declaration to the main content area and the ‘modules’ that were to appear in the right-hand column, and to set a left-hand margin on the main area, equivalent to the width of the menu plus the width of the ‘gutter’ (see fig. 1)
The menu block is then absolutely positioned 104 pixels from the top of the screen (the height of the header plus gutter), and everything turns out to look pretty similar cross-browser, or at least as far as I can tell using BrowserCam.
Unfortunately, problems arise when, as with the weblog pages, extra items are required underneath the menu block. It’s quite easy to apply a rule similar to that applied to the menu block itself - just add the height of the menu to the value of the top property - but the actual height of the menu depends upon the browser users’ text size setting. One way around this may have been to use Javascript, but I really don’t like to use programming for layout purposes.
The only alternative that I could see was to place the menu and other left-floating items inside an extra block, and then apply the same positional style declarations to this block as those applied previously to the menu block itself. Once again, this approach looks pretty consistent across various browsers (according to BrowserCam), and all being well the extra markup will not pose too much of a problem to future site layouts.
Looking at the various pages, you may have noticed one or two other subtle visual changes, such as the main content changing to a serif font (Georgia), and, to improve usability, a specific style for visited page links (you must have been to websites where you’ve wondered whether you’ve previously visited a particular page), but generally there’s no major differences from last time.
Problem Areas: Mac Internet Explorer 5.2 and Konqueror
IE 5.2 users cannot fail to have noticed that the header is aligned to the left-hand side of the page while the rest of the content sits in the middle (see fig. 2). This is due to a well-known bug in your browser, triggered by the overflow:hidden declaration applied to the header block. On removing this, the header alignment problem is cured - unfortunately, as the content now flows out of the container, it pushes the main content and the right-hand content areas downwards, thus wrecking the layout!
There is a cure for this problem, but it involves adding extra markup, something that I wanted to avoid. If you place the entire page within an extra container of fixed width, the problem is eradicated. This also fixes a display issue in the Konqueror browser where the right-hand column and the main content is aligned with the right-hand side of the window (see fig. 3)
Great, you may be thinking, a wonderful (!), cross-browser site. Unless you’re a Mac IE 5.2 or Konqueror user, in which case you’ll be wondering why I haven’t fixed it. The answer is Opera 6 (on the Mac, but it might also apply to other platforms). Before adding the extra container, 
Opera 6 seemed perfectly happy, but now it ‘throws a wobbler’, placing the menu at the extreme left of the window, outside the new container. Fig. 4 shows the problem, with the new content container indicated by a red border.
The problem is caused by the negative margin-left value - if I could target Opera 6 with a reduced (OK, in real terms, increased, from -368px to around -240px) value, then I can position the menu correctly. I attempted using an Opera-only hack described on John Albin Wilkins‘ Owen Hack page, but Opera 7.54 applied the value too - completely undesirable. So after a period of experimentation, I decided to bite the bullet.
According to my website log files, 0.8% of my visitors in the past couple of months use the Mac version of Opera 6, whereas IE 5.2 and Konqueror users added together, only come to 0.02%. Leaving the CSS and HTML as it is means that everyone can access the content and I use fewer markup ‘crutches’, like extra <div>s. Frankly, as both Opera 6 and IE 5.2/Konqueror provide such a small percentage of site visitors, I may as well go with the larger figure, especially as it means that I don’t have to do any extra work. If I happen to see a marked increase in IE 5.2 usage, then of course I would make the amendments, but IE 5.2 is well beyond it’s last legs now!
