The new layout seems to be causing problem for readers with particularly long and difficult to spell last names (well probably not, but the first people to report the problem were Larry Zappaterrini and Richard Duivenvoorde). It seems to be caused by a small font size. For the moment, if you're not seeing everything, try increasing the text size a few points. The stylesheet does not set any absolute font sizes, just uses whatever default you've picked.

OK. I have a partial fix. It should be OK for any readable font size, though you can still reproduce it if you shrink the font to something illegible. The problem is that the width of the navbar is specified in ems and the min-width is specified in pixels. I need to do this to make sure the navbar is wide enough for both the text and the images. However, the right margin of the content area is given in ems, which works as long as the distinction between ems and pixels doesn't get too far out of whack from what it usually is. The hack is to specify roughly half the margin I want in ems and put the other half in pixels in padding. This isn't a perfect solution. CSS desperately needs a way to place an element at an offset from another element, rather than at a fixed position on the page.

Another big missing feature is the ability to specify min and max margins and paddings. The problem here happens because I need to set the contents right margin to at least the width of the navigation bar on the right. Sometimes that margin is set by the width property and sometimes its set by the min-width property. Which is bigger depends on the font size. I have no way to specify that the right margin of the contents is the maximum of the navbar's width and min-width. I have to set the margin to one or the other. :-(

Can anyone suggest why Mozilla/Firefox can't find its AppleScript dictionary? I've been able to use some old Mac OS 9 Applescripts with Mozilla 1.7 so it has the necessary classes, but the Script Editor only shows a few basic entries in the dictionary. Alterantely does anyone have a good reference to scripting Mozilla on Mac OS X? Suggestions appreciated.

There didn't seem to be any major issues with the last iteration of the CSS layout for this page, so I've switched the main page over. If no one notices any problems with this, I'll probably switch Cafe au Lait in a week or two.

A lot of people kept getting hung up on the pre element in September 24 that extends past the width of the window if the window isn't grossly large. I can't quite find it in myself to call this a bug though. It's an unusual but legal and important use of the pre element. In the particular example at hand, it was critical to reproduce the white space exactly, long though it was. In essence this was an unintentional stress test that demonstrated how different layout algorithms coped with an impossible situation. The three major different layouts (table, absolute positioning, and float-based) all handled this differently. The table layout expanded the content area to be wide enough to hold the content and added scroll bars if necessary. The absolutely positioned layout runs the extra text under the righthand navbar, but doesn't change the size of the rest of the content area. The float layout overlaid the overly wide text on top of the navbar, but also didn't change the size of the content area. Readers who noted the problem were roughly equally divided as to which solution they preferred. There was no clear consensus that one was right and one was wrong. Personally, I think the smartest solution was overlaying the wide content like the float-based layout did. It's also possible the content area shoudl have received horizontal scroll bars of its own (something none of the layouts did). Possibly I can hack this behavior in with additional CSS properties. I'll explore that soon, but this is an unusual situation and not worth holding up the major changes for. It's a complete fluke that one of the rare news items I postetd with over-wide content happened to fall within the week where I was exploring CSS layouts. Most weeks this won't be an issue, and any other week no one would have noticed the problem.

One issue a couple of people raised was whether I should set a maximum width on the content area. This is based on the general prinicple that long lines are harder to read. I explored that option but decided against it. Practically, if I set a maximum width on the content area, I couldn't make the navbar flush left up against the content instead of leaving big ugly patches of white space in the middle of the page. More importantly, the more I thought about it, the more it seemed to me that this principle was just plain wrong for the Web. Unlike a newspaper, a web browser allows users to set the width of the window to fit their needs, rather than those of the publisher. If the lines are too long, it's easy to make the window smaller. While there may be a nice sweet spot for line length that mostly satisfies most users most of the time, it's not going to fit everyone. In particular, I suspect it may not fit readers with very babd eyesight who like to bump up their font sizes very high. Therefore I think it's much more important to give users the option to make the lines narrower or wider than it is to set a maximum width. I'm still open on this one though, if anyone can make a really strong argument for maximum line layout that takes into account the difference between screen based layout and print, and considers the needs of visually impaired but not completely blind users. However, so far all I've seen on this point seems to be based on old rules for working in print, repurposed for the web world without a great consideration for the very real differences between onscreen display and paper.