Adventures in markup land, part 1

For those reading in news aggregators, this weblog has a new design. One of my goals for the redesign was to try to grok Cascading Style Sheets (CSS). A lot of people are really excited about this technology, and up until this point my knowledge was limited to basic syntax.
So the other day, during a power outage when there wasn’t much better to do, I dropped into a local bookshop and started thumbing. I walked out with Christpher Schmitt’s Designing CSS Web Pages and Jason Cranford Teague’s DHTML and CSS for the World Wide Web. Chapter 3 of Schmitt’s book spells out several baffling bits: the import statement, the difference between span and div, the difference between class and id, and a catalog of the different types of selectors and how they work. Unlike Schmitt’s site-specific, whole-page examples, Teague’s book breaks its examples down by control type, making lookups easier when you just need to figure out how, say, vertical-align works. As a side note, it was a slightly maddening to discover that most CSS books, despite talking the browser compatibility talk, feature almost exclusively screenshots from Macs. Considering that most of the world views web pages in IE on Windows, this is a red flag.
So the Big Idea in CSS is that it lets you separate the content and structure of an HTML document from its presentation. Translating the buzzwords, “content and structure” means what you’d be telling someone if you said, “Here is my page broken down into parts. First comes a list of navigation items containing ‘XML’, ‘archives’, ‘search’ and ‘about’, then comes a heading containing the text ‘Andrew Grumet’s Weblog’, then a paragraph containing some text, then another paragraph containing some more text. Oh, and those paragraphs, they are examples of something I’m calling an ‘entry’.” The content and structure always go in the .html file.
“Presentation” means what you’d be telling someone if you said, “The whole page will have 0.5 em-height of padding around it. The guts of the page will have an additional 2 em-height of padding. Second-level headers will be 1.25 times the size of the body text.” The presentation may go directly in the .html file, either at the top of the file or embedded directly in element tags, but it is frequently placed in a separate .css file.
Separating out the presentation means, at least in theory, that you can redesign your page without touching the .html file. This adds a measure of safety when you want to experiment with new designs, or have a division of labor where some people specify the structure/content while others specify the layout. The latter ought to lead to innovations in weblog authoring tools. A default img style, for example could relieve authors of having to specify alignment and padding at the HTML level when they want to embed thumbnail images. It also means that readers who don’t like your design and want to apply their own rules, or just-want-the-content-thank-you, can disable style. It also means that you can define multiple alternate styles for, say, print vs screen.
I say “in theory” above because, unless the page design uses absolute positioning, the final layout depends on the sequencing of the content in the .html document. In some designs it may not be possible to move an item listed early in a .html file to the bottom of the displayed page (not that this is an especially good idea, as it makes the layout harder to understand).
What about absolute positioning? I find it labor-intensive, confusing because it becomes hard to guess what parts of the HTML source appear where on the page, and not especially robust to browser resizing and font resizing. The same goes for pixel-based layouts, they tend to fall apart when you bump the font sizes up.
But a lot of CSS designs use both absolute positioning and pixel-based layout. I think this is to solve certain classes of layout problems that are hard to do any other way in CSS. Consider, for example, the banner for this weblog. It contains an image, a title, a navigation menu and a shaded background. The navigation menu is right-justified. To achieve this effect in CSS, I had to “float” it to the right. But in doing so I pulled it out of the layout flow, which means that it doesn’t play a role in determining the height of the shaded background. That means, for some font sizes on some browsers, the right-hand navigation may poke out below the banner. Could I fix this by specifying the heights of the both the banner and the navigation box, and making them equal? If I specify in text-relative units (em-height), for small fonts the banner height would shrink below the height of the image, which is fixed-height. Yuk. But if I specify in pixel units, the text could easily overrun the banner for large fonts. These problems are handily solved with a layout based on an HTML table. The table lets me specify different text alignment for each cell, and has a height that can be compressed but not beyond the image height. Unfortunately using a table means I’ve snuck layout into what should be a structure/content part of the document. Is there a solution, a way to specify HTML table-like layout in a style sheet? I don’t know, but it would make certain problems a lot easier to solve.
I think I’ve rambled enough for now, but in general I’m happy with doing layout this way despite a wart or two. Having good tools is essential. At the risk of sounding like a broken record, the Web developer extension for Firefox is very, very handy as both a design tool and a learning tool. For example, you can use it to see the effect of making small edits to someone else’s stylesheet (see the Miscellaneous -> Edit CSS menu option). Now that’s cool.