MBar is based on an old flash navigation element that looked like it would be relatively easy to implement in CSS. And here it is.

The first version relied on :hover pseudoclasses for DIV elements. IE only supports :hover on anchors. In this revised version, anchors are used rather than DIV blocks. Some workarounds to get it to render better in NS4 were also done.

Compatibility is good on win32 platforms. I haven't tested Mac browsers. Version 4 and earlier browsers degrade without breaking the user's ability to view and navigate the site.

The IE 5.0 Problem

The dark-colored tabs, as well as the other line of links above it, are all anchor tags with display:block set. This is because (vertical) padding and borders (and margins) on inline elements are not handled consistently across browser platforms. So to get a consistent rendering of padding and borders, we set the anchors as blocks.

To get blocks to line up in a row they must be floated next to each other. Floating a block removes that block from the flow of the document. Thus, to get the parent block containing the floated elements to actually contain them visually (thus allowing the background color to carry down and around the floated blocks) we need one more block element at the end of this parent block (and after the buttons) with a clear attribute set. I use a DIV block because an empty DIV block will not generate white-space, thus allowing the floated elements to line up on the bottom border of the parent element. The problem is that IE 5.0 doesn't like the empty div block. So it puts the next piece of visible content INSIDE that empty DIV to satisfy its own needs. Thus making the parent block, the one with the background color, to carry down and around that first piece of visible content AFTER the MBar area. Thus, the h1 tag is appearing inside the gray area under IE 5.0

The paradox is this: to get IE 5.0 to render the buttons, we must use floats. The use of floats leads to this new rendering bug. So we trade one bug for another. Is there an end to the madness?

One fix that appears to work is floating the block that also does the clearing. However this breaks the layout in (at least) Mozilla and Opera. So what we do is use a selector with incorrect case as CSS selectors should be case sensitive but in IE 5 they aren't.

Further investigation into inline boxes and padding alternatives, such as increasing the line-height and use of vertical-align set to center may make this approach obsolete.

The Search Problem

In the original MBar, the search form was placed between two other items in the top horizontal list. However some older and text-based browsers treat forms oddly. Even when set to inline, a form tag still generates a line break in these older browsers. To degrade in the best-possible manner (given the circumstances) placing the search last in the HTML (making it first in the list because the elements are all floated) makes the list degrade in a more logically sound manner.

The NS 4 Problem

Netscape 4 actually renders MBar fairly well. There's a ton of extra padding, but that's in part to NS4's need to add 2px of padding to every block for no damn reason. And the inability to remove said 2px of padding.

The real problem, however, is that floated anchors no longer act as anchors. In other words, you can't click on the links. Well that defeats the whole purpose of MBar. For now we just hide the entire mbar stylesheet by specifying a media for the stylesheet. Maybe someone will find a CSS to fix this NS4 bug.