We’re off for a few days’ family visit. Happy Chanukah, Merry Christmas, and Joyous Kwanzaa to all. Our site’s redesign is nearly complete — most primary landing pages are done and many browser bugs have been squashed — but the last jots and tittles must wait until we return. For those who enjoy such things, here are a few notes:
The two-column structure consists of a centered “wrapper” element containing a primary content column that’s floated left, a static sidebar, and a footer. This time around, we avoided applying horizontal padding or borders to any core layout division. Eschewing those elements saved us the trouble of doing the arithmetic necessary to compensate for the incorrect CSS box model in old versions of IE/Windows. (Instead, we used margins to establish horizontal space between elements.)
Initial iterations of the layout, including the first version to go live, gave Opera 6 the willies. Instead of placing sidebar content where it belonged, Opera stuck it 450 pixels outside the wrapper. We resolved the problem by removing the explicit width from the sidebar rule. (See “The Float Model Problem” to understand why.)
The primary navigation menu is based on Pixy’s well-known approach to creating preload-free CSS rollovers. Our first version used nonstructural divs to sketch and test the idea; it also employed nonsemantic span elements to avoid a “flickering” issue in IE/Win. Albeit with latency issues in some browsers, it worked everywhere except IE5/Mac.
The present version dumps the spans and uses an unordered list instead of meaningless divs. It still fails in IE5/Mac, even though it works in IE5/Mac when taken out of context. Pour yourself a stiff one and follow along:
The menu is absolute-positioned and individual list items are floated. The absolute positioning is not necessary except for one thing: without it, the menu will not display in IE/Win. All other browsers tested understand that the menu should begin at the end of the preceding (header) element. But IE/Win doesn’t get it. It needs help.
Absolute positioning forces IE/Win to display the menu instead of hiding it in a virtual spider hole. But the fateful combination of floated items within an absolute-positioned containing element seems to throw IE5/Mac out of whack. (And the floats are needed to avoid triggering a different bug in IE5/Mac.) There is probably a solution but we haven’t come up with it yet.
There is a minor latency issue in Safari 1.0 in Mac OS X Jaguar, and there are back-button-related rollover state errors in IE/Win, but those are unavoidable — IE/Win just does that; always has.
There are more little geeky things we could talk about, and there are more interesting subjects (such as aesthetic goals of the redesign), but for us and for many readers it’s holiday time — time better spent with close friends and family. Have a safe and lovely week; see you soon.