A few days ago I started reading Shelley Powers’ new book, Adding Ajax, a free copy of which Shelley generously sent me. In the very first chapter, Shelley said something that helped me solve a nagging problem that I’ve had for months.
Readers of this blog and my other one may have noticed (and some of you have remarked) that when my sidebar length exceeded the content length, the sidebar overlapped the footer and extended into dark space. How amateurish. But I had spent way too many hours tweaking the HTML and CSS trying to remedy the situation, and had finally given up. The thing is, I knew how to avoid this aberrant behavior, but not without either displaying the sidebar first or making the content section fixed-width. What I wanted was to have the content size fluid, the sidebar size fixed, and to display the content before the sidebar (for the benefit of all readers, but especially those using a screen reader or mobile device). So I used a large right margin on the content and applied an absolute position to the sidebar. But with that arrangement, clear:both on the footer ignored the sidebar’s length. For someone who cut their web teeth using tables (or dare I admit it, frames) for layout, it was enough to drive me crazy.
In Shelley’s book, she gives a very clean and simple example that applies float:left to the content and float:right to the sidebar, drawing the latter last and applying clear:both to the footer — which works fine, except that in that case a fluid content section will take up all the available space, forcing the sidebar to appear beneath it. But Shelley hinted that this was possible with fluid layouts, and said something even more useful at the end of her example:
For additional reading on CSS layouts, search the web for “fluid fixed elastic CSS layouts”.
Now, I had previously googled until my googler was sore trying to find a solution to this problem, but I hadn’t used those exact search terms before. Since I’m not interested in fixed or elastic layouts, I omitted those words and googled anew. This led me to the Holy Grail of web design. Matthew Levine explains a simple but unique approach to making fixed-width sidebars float either left or right of a fluid center section, with a footer below them all. In brief:
- Enclose all three sections within a container section, using position:relative and float:left to keep them from stacking vertically.
- Apply padding to the left and right side of the container for the desired size of your sidebars. This restricts the fluid center section to the remaining space.
- Use negative margins on the sidebars, to move them back out over the container’s padding.
- For the left section, specify the position. The right section gets bumped out automatically by the size of the center section.
- Use clear:both on the footer, to position it beneath all three sections.
Since I don’t have a left sidebar, I was able to do this even more simply:
- Enclose the content and sidebar sections within a container section, using position:relative and float:left.
- Apply padding to the right side of the container for the space to reserve for the sidebar.
- Use a negative right margin on the sidebar.
- Apply clear:both to the footer.
Naturally, this didn’t work the first time (when does it ever?) — I had issues with inherited padding, prematurely closed div’s, and other such nonsense that had accumulated like dust in my theme files over the course of many tweaks. These were relatively easy to hunt down using the Web Developer toolbar for Firefox (which Shelley also recommends in her book), using the Display Block Size and Display Div Order options on the Information menu. One issue that I suspect would have taken me much longer to hunt down had it not been for this feature was a conflict between div class names — my theme used “content” for the class of the main content section, and the Brian’s Threaded Comments plugin uses the same class name for the section that includes the contents of each comment. So when I added float:left to ”.content”, the comments section went haywire. That’s a good example of why, when writing a plugin, you shouldn’t use common class names or ids for elements it produces — you should always prefix them with something to make them unique, because you never know who else might be using that name as well. To work around it, I just renamed my “content” class to “blogcontent”.