This site will look much better in a browser that supports web standards, but it is accessible to any browser or Internet device.
x x x x x this is to test the italics bug in ie x x x x x
Similar to the original 2 column w/footer layout except column background colors are produced entirely with CSS. The problem is getting the colors to carry the full height of the content regardless of which column is taller. The solution explored in this layout was first demonstrated here. Basically a color mask for the two columns is fixed to the viewport and placed on the lowest layer possible with content placed on top of it.
Compatibility is certainly in mind for this layout. However compatibility here means the ability to read the text of the webpage and to retain the logical breakdown/separation/formatting of the information as intended. In other words, hide all CSS from old browsers so they see a flat file with no color. Testing platforms for this layout are IE/Win >=5, Mozilla 1.x, Opera 7, Safari and IE5/Mac.
This is a work in progress. Feel free to use any or all of the HTML/CSS/etc that you find here, just understand you may encounter a small percentage of users whose browsers horribly break the layout. Check back here for updates to the layout.
For a moment, look at the layout and imagine the top layer has been peeled off. What's left? You would see the two columns filling the entire height of this page. Now imagine you've got a short content area. The footer is going to appear well above the bottom edge of the browser's viewport. What is going to appear below the footer in this short content webpage? The columns! But you don't want that. It breaks the illusion of the layout and it just plain looks bad.
So what can we do? The first idea would be to simply not create a viewport-wide footer, but rather have a content-column (white) wide footer. You can see this approach in several existing CSS layouts that have tried to tackle the two-column problem. It works. But perhaps you're like me and, for some reason you can't understand, want the viewport-wide footer. This means you'll need a background color on that footer to cover up the columns that are on the bottom layer. This also means you need to find a way to cover up the whitespace that may appear below the footer on short content webpages.
How? Well, I'm still working on that one. Right now the approach is to create an empty block with the same background-color as the webpage and place it below the footer. Sounds reasonable, but getting that block's height to exactly the height that remains between the bottom of the footer and the bottom edge of the viewport is difficult, if not impossible using only CSS. JavaScript is certainly an option that would work, but we're trying for a CSS-only solution.
The current approach is to set that block's height to 100%. This gives it the same height as the viewport. This means regardless of how short your layout is, that block will always be taller than whatever space is left. This works fine, but now there's a 100% tall "empty space" at the bottom of your web page. Right now, your users will just have to live with that. Should this be a big issue? Probably not. The only problem is that a scrollbar will always be displayed.
But I don't want a scrollbar if I can help it. And you can through some more css hackery. Setting a bottom-margin of -100% on this color mask block should, in theory, move the browser's understanding of where the bottom of the webpage is up -100%, thus negating the area the color mask takes up, while still displaying it. Well theories are nice, but in practice, this isn't the case. All browsers I've tested still make room for the entire block, even though any objects placed below the color mask (in the HTML) will be rendered in the flow of the document as if the color mask doesn't exist.
But under IE6/Win, when #pageFrame does not have a position attribute set, floating this color mask, with the -100% bottom margin, does the trick. This appears to work only in IE6/Win. IE5/Win still display the entire color mask.
So what about other browsers? Setting a position of fixed to that color mask will get Mozilla to ignore the color mask's dimensions when calculating the height of the webpage. IE/Win doesn't understand fixed positioning, so you don't even need to worry about hiding the CSS. Or do you? Turns out Opera doesn't like this approach. And it actually makes the layout look a bit worse. So we have to use the owen hack to hide this bit of CSS from Opera.
So the current score is IE6/Win and Mozilla look great. IE5/Win and Opera (7) have a 100% tall area of whitespace below the footer. It could be worse. Mac browsers we'll get to later.
So this is a first approach to this curious problem. If you've got any suggestions or ideas, please e-mail me as I'd love to hear them.
IE5/Mac is working now. Not setting a width or height on the html element seems to resolve an earlier issue with IE5/Mac. I had set width and height on the html element because Mozilla and IE6, at one point, seemed to require it. But things work fine in both browsers without it, so there we are.
By setting #flowing to a position of relative rather than absolute, IE5/Mac's horizontal scrollbar finally disappears. #flowing can, of course, be relative without breaking the other layouts. We just need to explicitly set 0 margins (or padding for you Opera users) to the body element to make sure we have border-to-border use of the viewport.
Safari is working as the layout is intended with one small rendering issue. It seems when the page is loaded with content taller than the height of the window, a gutter of about 1em (perhaps the height needed for a horizontal scrollbar?) appears on the bottom-layer color mask. When you manually resize the window, this gutter space disappears.
This bug seems to be caused by how Safari is calculating the height of the webpage. When the content (#flowing) layer is removed, the columns carry the full height. There are other indicators when I play around with height values. I'll have to investigate further.
Opera seems to have a related bug. On pages with content taller than the viewport (thus generating a vertical scrollbar) if I minimize Opera, then maximize, I get the same gutter effect on the bottom of the viewport that I see with Safari.
Safari is supposedly based off of Konqueror, perhaps Opera has some Konqueror code in there, or vice-versa?
The fixed hack for IE brings with it an odd problem. The bottom layer has no scroll-bar, while the top-layer might. If left untreated, when the layout is tall enough to force scrolling, the bottom layer (the columns' color mask) becomes offset by the width of the scrollbar. We can force a scrollbar to always appear in IE regardless of height of the content. This allows us to assume the existence of a scrollbar to then work out a hack on the lower-layer to keep it in correct position.
So right now, a 16px padding is added to the right-side of the lower layer. However with the introduction of XP themes, as well as altered versions of IE for those with eyesight problems that enlarge the scrollbar, this 16px isn't going to align the color mask correctly.
I have no fix for this. If the scrollbar isn't 16px wide, the masthead and footer's right-hand border won't line up with the background color mask. This problem is only in IE, the extra padding CSS is only seen by IE, and it appears IE >=5 (the only IE versions that should see the CSS) have 16px wide scrollbars by default. The default XP theme is the same. Are there other themes out there with different scrollbar widths? I don't know. If you're okay with maybe 85% coverage, then this layout is probably okay.
First, let me just say that you can copy and paste every style sheet, except for fixed_ie.css, into one giant stylesheet and include that in your webpage. You do not need 9+ separate stylesheets to make this layout work.
The reason for the 9+ stylesheets is for better understanding about how the layout works. It allows anyone to focus on one specific aspect of the layout, such as how the horizontal nav is generated from unordered lists, without having to sort through a few hundred lines of CSS. It also makes the rather bulky CSS easier to handle. One layout could be shared across an entire website, with sub-sites having different color schemes or font styles. Should a bug crop up in the layout, you don't have to worry about updating 20 different base.css implementations, you can update just the one and all other sub-sites will be updated at the same time.
With 9+ stylesheets, you can create separate screen.css and print.css stylesheets that import only those parts of the layout you need. For example, not including colors.css in a print.css stylesheet means black and white text for everything when printed.
Caveat webmaster, for 9+ stylesheets means every page hit will generate at least 10 lines in your webserver's log. For even a moderately trafficked website, this could mean 5-10gb logfiles every month. Move the CSS into 1 (2) file, and now you've reduced those logfiles by up to 70%!
My suggestion, if you plan to implement this layout, compress all layout-related CSS (base.css, vnav.css, hnav.css,gutters.css) into one file, and compress all theme-related CSS (colors.css, borders.css, fonts.css) into another. This allows sub-sites to share the same layout but change the theme up however they want.