CSSing: Structuring your pages: Part I

One of the precursors to any website redesign bent on using Web Standards is asking, then answering, the question: "how should I structure my page?" Structure, in the sense discussed here, is how content is represented in HTML code. This discussion does not include structuring anything outside the body tag, rather it will focus on the structure of a page's content and the page's content containers.

The structure of the code between the body tags is generally represented in code by two concepts: structural markup and content markup.

Structural markup can be thought of as the skeletal framework of any HTML code. It has no real meaning except to divide the page up into logical sections in which content markup can be added. I used the word divide on purpose. Since structural markup is meant to represent essentially meaningless, but organizational, divisions, it is customary to use a <div> tag. We will discuss the considerations of marking up every structural block below.

The second type of markup is content markup. Content markup are the semantic containers in which a page's content resides. As it turns out, most content falls into three categories of elements: headings, lists or paragraphs. These elements are usually represented in code with tags like: ul, ol, li, dl, dt, dd, h1, h2, h3, h4, h5, h6, and p. Unlike the structural markup, these tags have real meaning and their use represents something both in code, to a machine, and to human looking at the code. As a note, just about anything can be content markup. In some sense, even the structural markups are a type of content markup, and there will inevitably be times when generic containers built from div tags would fall under this category.

In each case, there is a mental process and a set of decisions to be made during the process. Some are trivial; others are not. In this section, we will first look at structural markup. In a later post, we will examine content markup.

Structural

Structural markup seems to be the toughest concept for new developers to understand. In part, I blame this on the fact that never before have table-jockeys had to even consider this concept in the abstract. Rather they created a series of table cells and placed their content within the appropriate table cell. Nevertheless, those table cells are probably the primordial ooze from which to begin thinking about how a page is going to be structured.

A general case can be made that most webpages have at a very minimum a header, a content and a footer section. In tables, these might well be three table-rows and three table cells. Conceptually, this would put the header on top, the content in the middle and the footer on the bottom. Indeed, the table structure would also, in most cases, dump to the screen exactly like this. For example:

<table>
	<tr><td>Hi! This is my header</td></tr>
	<tr><td>This is where I'd put all my content!</td></tr>
	<tr><td>I'd probably have a copyright, and footer information down here.</td></tr>
</table>

As always, this type of table-think is dangerous. While in the simple case, this might work, it will nevertheless lock a developer into a particular design concept. What happens when you add navigation? Two navigations? What if you want to switch the order of the navigation and the content? In every case, you begin to complicate what started off as a simple, short table.

The tabular layout is also wasteful. Notice that to simply get the stacking effect we needed a wrapping table tag, three rows, and three cells. It would seem that at least three, if not four, of those elements are unnecessary.

Instead, let's think about what is really being said in when developers layed out that table. The mental process probably went like this:

Hmmm... I need a page
I know I want my logo and stuff at the top
I have some copyright information that goes at the bottom
And all my pages will have some content that will be different.
I'll also want to have some navigation

As I noted above, this discussion is only dealing with the stuff between the body tags. As such, the creation of a body tag gives us the first step: "I need a page." In table-think, it would be the combination of <body> and <table> that would fulfill this first step. We'll see in a bit, that for the sake of "more containers" we may add another element here, but for now, let's not.

Deciphering the mental process

The second step, "I need stuff at the top", begins the more difficult work. "I need stuff at the top" isn't much help, until you translate the "need" into something more elaborate as "I need a special section [division] to add the important branding information at the top of the page." There are three components to this step: the elemental, the division, and the visual/logical placement.

What the mental process in the second step is telling us is that the developer already has is a concept about what he needs (a discussion of elemental markup), where it needs to go (a pseudo-CSS discussion), and that this is somehow distinct from other parts of the page (the structural discussion). In the instant gratification world, most table-thinkers skip right to the elemental and layout discussion. However, this skips perhaps the most important step: the first step in our structural plan.

The header

In the publishing world, this logical division is called masthead or in simple terms the "header". Aside from what the developer thinks is appropriate content for the "header", we need no further information to build our first structural element, we'll call it "header":

<div id="header">
<!-- I will put all the stuff for my header:
	logo, slogan, etc between these tags -->
</div>

There are a couple things happening in this small piece of code. First, the <div> tag becomes a container for anything that the developer feels belongs in the header. We need nothing more than these two itty-bitty tags (one open and one close). Second, we have identified the header using the id attribute.

Using ids vs. classes

Allow me to digress for a moment. A common question is raised about when to use an id and when to use a class. While there is no hard and fast rule because they can function the same way, I tend to think of ids as special cases of classes where I can guarantee the uniqueness. Since High-level structural elements are almost certainly unique and as such they are best described as a class. Since a page probably should not have more than one header, using an id makes some sense. In addition, we can logically directly address ids in both script and CSS with little concern that there will be more than one of them.

What are block level elements?

A <div> tag, by itself does nothing. It is a generic block level element. Block level elements, by default, are elements which force a line break on open and on close. Block level elements, by default, consume the entire available horizontal space. By default, they consume only as much vertical space as necessary. In addition, block level elements stack on top of each other. They can also contain other block level elements and other inline elements. In addition, they are supposed to apply padding, margins and borders according to the traditional box model. All of these are the default behaviors of a <div>. Nonetheless, these behaviors can be altered by CSS.

Knowing this, though, we can now think about where this container (note: I will use block, element and container synonymously) in code. Which leads us to another part of the ideas in the mental process: placement.

Conceptually, logically and perhaps visually the header belongs first. The first two are satisfied simply by placing the code first: ie. right below the <body> tag:

<body>
	<div id="header">
	<!-- I will put all the stuff for my header:
		logo, slogan, etc between these tags -->
	</div>
</body>

Also, knowing the default behavior of a block level elements, placing the header block first in code will also mean that it will display at the top of the page. Though there are a few things to note. First, the default behavior of the body is to have some margin and padding. If you expect your header to be flush against the viewport (the rendering part of the browser), then you need to turn of the margins and/or padding in the stylesheet: body { margin: 0; padding: 0; }. Second, no matter what you inside the header block, by default, everything subsequent to header will stack. If you start changing the default behavior, ie. using position: absolute; or float: left;, you may change how subsequent elements interact with this block. For example, floating blocks within the header, may cause the header to not contain those elements. All of this discussion are problems innate to CSS, not to the structure, though.

The stacking behavior, though, is the behavior most developers expect, and it is an important default behavior to remember. Knowing this alleviates the "how do I get my header and footer to be on top of and below my content, respectively" questions.

With this in mind, we are finished discussing the header, and will make understanding the footer and content blocks easier. Oops, I've given away parts of the subsequent mental process. You'll find that once you're familiar with structuring one part, each additional part becomes easier.

The third is a common requirement for a more or less static footer, "I have some copyright information that goes at the bottom". This can be translated as, "That legal mumbo-jumbo needs to be below my other stuff." Using the methodology from above we know a few things:

We need a container
This is probably unique and we can give it an id
We don't need to worry about the content yet
This is, for now, conceptually, logically, and visually last
By default, blocks will stack, we don't need anything more

With this in mind, we can make our container. Almost universally, the bottom of a page is called a "footer". As such, we'll name it to match. Again, there are probably not two footers and thus we can use an id.

<div id="footer">
<!-- I will put all the stuff for my footer:
	copyright, contact info, etc -->
</div>

Since we know that the blocks will stack and that this is conceptually last, we can add the block to our code:

<body>
	<div id="header">
	<!-- I will put all the stuff for my header:
		logo, slogan, etc between these tags -->
	</div>
	<div id="footer">
	<!-- I will put all the stuff for my footer:
		copyright, contact info, etc -->
	</div>
</body>

If we were to fill in some dummy content, for header and footer, we would see that they're exactly how we had imagined them. The divs do not change much about the output. They do, however, in code, logically group the content within the containers. Since they're grouped using ids, we can manipulate individual elements' style in CSS using the following format: #header h1 { ... } and #footer p { } which will apply styling specifically for that container.

We can now add the content block.

The content block

The content block is no different than the header or the footer. The content block, however, is the block that usually contains all the "content" (imagine that) that a end user is looking for. In mental process three, we said, "And all my pages will have some content that will be different." Here there is no explicit reference to a container, but one can be inferred.

In theory, you don't need any containers for anything. You can develop a perfectly legitimate page without ever marking up the structure. However, when it comes for us to code or differentiate parts of content, if we do not have the containers, we fall back on classing every element on a page. For example, if we place a <h1> in our header and our content has an <h1> as well, if we didn't have the containers how could we differentiate the two? You could do <h1 class="header"> and <h1 class="content">, but that's ugly and inefficient. You'd very quickly realize that every element had to have a class.

So as we think about the content section, we can see that two things are possible. First, we could just simply allow the developer to add the new content between the header and footer sections, or, second, we can add another block.

Here in lies one of the more difficult decisions: to block or not to block. The decision is a both a design issue and a practical issue.

Practically speaking, adding more divs increases overhead, a little, and increases the code's complexity, a little. However, it also increases your specificity, provides more elements upon which to apply styles, and may ultimately improve readability and maintenance. On the other hand, embedding too many divs into your code can lead to the polar opposite.

As a compromise, I personally always try to wrap related content, at least one time. In this case, while our content could potentially go without any container doing so might potentially allow hundreds of content elements which should be related to not be. As such, we'll create a block called "content."

<div id="content">
<!-- This is where the content for
	a page will be entered -->
</div>

From our previous rules, we know that this block will be between header and footer.

<body>
	<div id="header">
	<!-- I will put all the stuff for my header:
		logo, slogan, etc between these tags -->
	</div>
	<div id="content">
	<!-- This is where the content for
		a page will be entered -->
	</div>
	<div id="footer">
	<!-- I will put all the stuff for my footer:
		copyright, contact info, etc -->
	</div>
</body>

With only three tags we have done much the same as the table whilst providing infinitely more specificity and flexibility. However, we haven't yet completed our fifth requirement. As we mentioned before adding navigation to the tabular layout meant knowing something more about the design and would further complicate the simple table. Using the structure we've created, and knowing nothing about the ultimate layout, we can add a container for navigation very quickly. So quickly in fact, that it doesn't get it's own section.

Though, before we add navigation, we need to consider one more thing. Our business rules say nothing about where the navigation should go relative to the content. That is, we know that navigation belongs between header and footer, but beyond that we're offered no additional help. Furthermore, we have not considered any design issues left/right/top/bottom in our structure, so we cannot look to this for guidance. What we do know is that search engines rank content by order in code. The nearer the top the better the content (top-down precedence), or at least so the theory goes. We also know our navigation is probably repetitive, but still necessary. However, it is the "content" on the page that is the most important. As such we probably want the navigation below content. We also know that our footer is last, that was another design requirement.

With that in mind, we can add navigation:

<body>
	<div id="header">
	<!-- I will put all the stuff for my header:
		logo, slogan, etc between these tags -->
	</div>
	<div id="content">
	<!-- This is where the content for
		a page will be entered -->
	</div>
	<div id="navigation">
	<!-- This is where my navigation links
		will be -->
	</div>
	<div id="footer">
	<!-- I will put all the stuff for my footer:
		copyright, contact info, etc -->
	</div>
</body>

In a typical tabular layout, with navigation on the left and content on the right, the navigation would probably be ahead of the content in code. In addition, a tabular layout requires us to move code around if we were to want to move navigation to the other side.

More structural elements?

Looking at our code above, it is conceivable to find several more logical groupings. The most obvious is a grouping around content and navigation. Why? Simple, header and footer have hard and fast rules about location: top and bottom, respectively. Everything else, in this case content and navigation, is between those two. There seems to be a relationship of "everything else" there. Whether or not this particular grouping is good or not might also affect how flexible a design could or could not be (ie. relatively positioning navigation, etc).

Another possible grouping would be a div containing all the blocks. This would be strictly a shortcut for some design features that reflected how all the containers were handled (ie. max width and horizontally centered blocks).

Conclusion

Structural markup is conceptually very simple. So simple, that once you've found a structure that you like, most subsequent designs will follow almost exactly the same structure. The key to figuring out an appropriate structure is figuring out your page's content needs and asking the sometimes difficult business questions.

CSSing

Wednesday, August 11, 2004

Structuring your pages: Part I