Days: it’s a blog thing

Since August, 2001. Surely it can’t last…

Sunday, July 28, 2002 ↓


I can’t recall now whether it was Rob or Ben who first pointed me to Shannon Campbell, but I’ve been reading her Pet Rock Star blog for some time and finally got round to adding it to my Regularly Watches list. Do yourself a favour and download some of her music (MP3).

Posted at 3:52 PM


While I was booking my flight’s for this week’s trip to Gothenburg, it struck me that it was almost a year ago that I wrote about problems using KLM’s web site. I’m sad to say that not only have matters not improved over that time, they have actually got worse. The flaky behaviour I reported last August began with what I thought was a one-off event, which then became occasional, then frequent, and now afflicts me every time I try to make a reservation. It’s particularly annoying that I have to go through a number of fill-in-the-form screens before the system reaches the point where it bombs; all just time wasted. Perhaps stupidly, I persist; but a few weeks back I gave up and telephoned them because I simply couldn’t wait any longer to make sure I’d have tickets for the flights I needed. It wasn’t particularly reassuring to find that KLM’s UK telesales staff experienced the same problem with their internal booking system, and couldn’t actually make a booking for me there and then — they had to call me back a couple of hours later to tell me they had managed to get me on my chosen flights.

I’m left wondering: what’s so difficult about this? And am I just unlucky, and this problem only manifests itself on the route I want to fly almost every week, or is it a systemic problem affecting the whole booking system? And have more people complained to KLM? (I have.)

Looking on the bright side, though, KLM has recently introduced e-ticketing on this route, so I no longer have to queue up at one desk in the airport to collect my tickets, before queuing up at another to check in. All progress is welcome.

Posted at 3:22 PM


The excellent Jeffrey Zeldman and the revitalised Web Standards Project are much happier with the current crop of browsers than ever before. Conceding that IE6/Win, IE5/Mac, NN6, Opera 5 and the long-awaited Mozilla 1.0 all exhibit pretty good support for key web standards, both Zeldman and the WaSP are urging web developers to turn their backs on the hacks of the past and embrace standards-compliant design, while simultaneously encouraging the software vendors (Macromedia, et al) to produce tools that generate valid code.

Of course, they are correct. With decent browsers on most desktops these days, and various methods available to hide CSS from browsers where it would do damage, now seems like a good time to dispense with table-based layouts. Control your presentation with CSS, let users of new browsers see your pages as you intended, and let older browsers harmlessly display a simpler, unstyled page. Great. In fact, that’s the approach I’ve taken on all my recent web work.

But not everything in the browser garden is rosy (will it ever be?). Recent experiences with this little site, with a client site, and with the redesign of one of my business sites (yes, it really was time that I smartened it up a bit and added some content!) underlined for me how far browsers still have to go in the CSS direction. I’ve seen deficiencies in three broad categories:

  1. Browsers don’t all support the same CSS properties — or at least, not to the same extent. This is possibly the biggest problem. Incomplete support for CSS wouldn’t be so bad, if all the common browsers offered the same level of support at any point in time. (Wouldn’t it be nice if the vendors all got round the table and agreed, “Right, in our next versions, we’re all going to support x, y and z.”) I had a situation where the ideal would have been to present text in a fixed-size DIV, with a scroll bar popping up automatically when the content is bigger than the DIV. No problem, that’s what the div {overflow: auto} rule was made for, no?

    Yes. Except that it doesn’t work properly in all of the current, “pretty good compliance” browsers. So to achieve the effect I wanted, I had to go for a more complicated IFRAME set-up, of which perhaps more later.

  2. The same browser doesn’t support the same CSS properties on different platforms. This is a real bitch. I built the new design for my aforementioned business site with correct, valid code. Guess what? It looks exactly right under IE5.5, IE6, NN6, Opera 5 and Mozilla 1.0 for Windows. On the Mac (and I suppose I should specify OS 9, for reasons you’ll see later), NN6 and Mozilla get it right. IE5 and Opera 5 fail spectacularly. I’ve left it that way for the moment, a testament to browser inconsistency. First chance I get, I need to spend some time exploring which bits of the CSS the buggy browsers don’t like, and trying to find some (doubtless ugly) workarounds. We can’t escape from hacks, it seems.

    In similar vein, since IE5 for MacOS X was released, a number of people have contacted me to tell me that the browser explodes when trying to view this very site. Given that the code and CSS are valid, I’m pretty confident that it’s the browser that’s at fault. Particularly when IE5 for MacOS 9 renders the site perfectly… and I’ve heard several other reports of the OS X version cracking up under quite harmless, valid CSS.

  3. New versions of browsers “forget” how to do something that the last version did properly. I have come across a number of examples of things that IE5.5/Win did correctly, which IE6/Win does not. Some of these are highly idiosyncratic. On one of my client sites, every page has an absolutely-positioned DIV with a background image. The image is not the same on all pages, the distinction being created by having different classes of the DIV. In IE5.5, everything works just fine. In IE6, the background image is displayed on the Home page, but not on any of the other pages! I don’t have a solution to this yet.


Posted at 1:03 AM

Previous entries

Older material is stashed away under Replays.