The steps involved in preparing your page for CSS flexible layout are no different than those for CSS fixed-width layouts. Since this isn’t an introductory book on CSS, I’m assuming you already know the basic steps of page setup. For a quick review, however, here’s what you need to do in between slicing the graphics (as we did in the last chapter) and writing the CSS for layout (as we’ll do in this chapter).
To set up your (X)HTML pages properly to the point where CSS can be applied to them, do the following:
1. | Choose a DOCTYPE. Note You can read up on the XHTML rules at http://xhtml.com/en/xhtml/serving-xhtml-as-html and http://en.wikibooks.org/wiki/XHTML_(XML)#Converting_HTML_to_XHTML. Most of these rules can be complied with even when writing HTML, in order to make conversion to XHTML or XML easier if you decide to go that route in the future.
| |
2. | Place the content in the page, and apply semantic markup. Each piece of content needs to be marked up with the proper (X)HTML element to indicate what it is, such as a paragraph, first-level heading, or block quotation. Don’t add any presentational markup, such as font, b, or center elements, as this will all be controlled with CSS. One of the many benefits of semantic markup is that it provides more “hooks” to attach our CSS to, which we will definitely be taking advantage of later, when we style our layouts. For more on semantic markup, read “Integrated Web Design: The Meaning of Semantics (Take I)” by Molly Holzschlag (www.peachpit.com/articles/article.aspx?p=369225). | |
3. | Group the content with divs. Although divs are semantic-neutral elements, they’re fine to add to your page—in moderation. Use the minimum number needed to group large chunks of content into organizational or thematic groups, such as navigation, main content, and footer. Ideally, you would never have to add any extra divs to accomplish visual effects, and your divs could be put in the most logical order in the source without regard for where they will appear visually on the page, but this is rarely how it works out in reality. Browser and CSS limitations make it necessary to adjust divs somewhat to accommodate visual formatting, so we’ll go over the proper div structure for each of the layouts we’ll be building as we come to them. | |
4. | Attach one or more style sheets. Use the link element or @import directive in the head of the page to attach your style sheets. You may want to simply embed the styles in the individual page during initial development, by placing them in the style element in the head. You can then move the styles to an external style sheet once you’re satisfied with them and ready to apply them to multiple pages, before you make your pages live. Most of this book’s example files are set up with embedded styles so that you have everything in a single file to work with and refer to. |
Once you’ve completed these initial steps, you’re ready to start filling in those style sheets to create your layout.
In addition to the universal page setup steps that you’d follow for every page, there are a few things you can expect to see in all of the examples in this chapter.
First, all of the examples shown in this chapter will use the following basic div structure (so get familiar with it!):
<div id="header"></div> <div id="content-main"></div> <div id="sidebar"></div> <div id="footer"></div>
Second, for each method we go over, we’ll start out with two-column structures to demonstrate the basic techniques, and then move on to adding more columns.
Naming ConventionsFeel free to use whatever naming convention you like for your id values. I’m partial to using dashes to separate words, so that’s what you’ll see throughout this book, but it’s no more “correct” than using underscores or camelCase or just smooshing all the words together. Just be consistent with whatever you choose. However, in terms of the actual words that you choose, I do have some universal advice. It really is best to avoid vague and presentational names like “sidebar” for your divs whenever you can help it. Use id values that are more descriptive of the content within the div, such as “secondary-nav” or “featuredProducts” or “latest_news.” But since this chapter contains simple examples in which we don’t know or care what the content within the sidebar will be, we’ll stick with a generic name of “sidebar” here, which you can later replace with an id more appropriate to your page. If you’re interested in using the same names as other CSS developers use, see Andy Clarke’s suggestions in his article “What’s in a name (pt2)” at www.stuffandnonsense.co.uk/archives/whats_in_a_name_pt2.html. Andy advocates for names that are not only meaningful but standardized across sites, which can help you reap the following benefits:
|
Third, I’ve applied some basic CSS for visual formatting to the page; mostly background colors on the divs so that you can see where each one lies in the example pages you’ll see throughout the book.
body {
margin: 0;
padding: 0;
font-family: "Lucida Sans Unicode", "Lucida Grande",
sans-serif;
}
div {
padding: 1px 0;
}
#header {
background: #DDDDDD;
}
#sidebar {
background: #FFA480;
}
#content-main {
background: #F0EE90;
}
#footer {
background: #DDDDDD;
}Tip
When you want to see where divs or other block elements lie, background colors can be much more effective than borders. Borders affect both the box model and margin collapsing; therefore, they influence how elements are spaced out from each other and can change where divs lie once they are removed. Background colors don’t interfere in the layout this way, so they’re a safer option for developing and debugging CSS.
Note
Each of the completed example files is available for download from this book’s companion web site at www.flexiblewebbook.com. Download the file ch4_examples.zip to get the complete set. I’ll let you know which file goes with which technique as we go along.
With these divs in place and no styling apart from changing the font and background colors, we already have a liquid layout (Figure 4.1). Divs, and all other block elements, automatically expand to fill all available horizontal space in their parent elements. That means, for instance, that our sidebar div is always as wide as the viewport, because it expands to fill the full width of the body element (its parent in this case), which is equal to the viewport size.
What’s the Point of One Pixel of Padding?You may notice that the formatting CSS shown on the previous page contains a rule setting one pixel of top and bottom padding on every div. That padding is there to stop margin collapsing. Margin collapsing is when two vertical margins that touch each other combine together into whichever margin value is larger. This happens all the time without you knowing it: paragraphs have both top and bottom margins on them by default, but instead of the two margins between successive paragraphs stacking on top of each to leave a doubly large margin, the two touching margins collapse together into one. The divs in our example pages each contain paragraphs whose default top margins touch the margins of their containing divs. Because those containing divs have margins of zero by default, the paragraph margins are larger and therefore “win,” collapsing together with the div margins and leaving a gap on top of every div. A quick and easy way to stop this gap from appearing is to put something in between the edge of the div and the edge of the paragraph to stop the margins from touching. Padding and border can both be used, but since one pixel of padding is less noticeable than a border, that’s the solution I’ve gone with here. If this were a real page, you’d probably want to remove the top margins from the paragraphs to keep them from collapsing outside the div. But for the purposes of these simple examples, the padding trick works just fine. You can read more about how margin collapsing works in the article “Uncollapsing Margins” by Eric Meyer (http://complexspiral.com/publications/uncollapsing-margins). |