Yes, that’s right: red on blue. We never said we were discriminating when tossing together code examples. But before you slam this book shut in a fit of palette-driven indignation, let’s examine how these two ele- ments appear on the page. As you can see in Figure 7-3, we’ve taken the liberty of applying some basic type information to our document as well (Times New Roman is so 1995). But with our (somewhat garish, we’ll admit) colors and borders activated, we can see that the two divs are placed in the normal docu- ment flow — the inner block is a child of the outer block, and the page’s current display reflects that. Figure 7-3: Our bland-looking elements in the normal document flow However, by using CSS to change the value of the inner element’s position property, our design does- n’t have to be reflect this parent-child relationship. We can add three brief lines to our #inner selector: #inner { background: #FDC; border: 4px solid #930; position: absolute; right: 20px; top: 20px; } 248 Chapter 7 09_588338 ch07.qxd 6/22/05 11:26 AM Page 248 The difference is rather marked, as Figure 7-4 shows. We’ve visually broken the parent-child relationship between the two divs. While the inner block is still a child of the outer one in the markup, we’ve used CSS to override the former’s position in the normal document flow. Instead, we’ve positioned it abso- lutely, offsetting it 20 pixels from the topmost and rightmost edges of the body of our document. Figure 7-4: In the markup, the topmost block is a child of the bottom one. However, using position: absolute; removes the block from the document flow and positions it relative to the viewport. The inner block typically appears in the normal flow of the document, in the context established by the other block-level elements that surround it in the markup. Our rule has redefined that context, and placed it in one that is relative to the boundaries of the browser window. This is why the body root of our docu- ment — the html element — is also known as the initial containing block, as it typically provides the posi- tioning context for all elements contained within it. Furthermore, this new positioning context for #inner has redefined that of its child elements — namely, the paragraph contained therein. In other words, we’ve not only repositioned the div, but any and all elements contained therein. This becomes a bit more apparent if we add a few more paragraphs to our absolutely positioned block, as we see in Figure 7-5. When two new paragraphs are added to #inner (our absolutely positioned block), they inherit their parent’s positioning context— which is all a fancy way of saying that since their parent block is abso- lutely positioned, it will expand to contain its new children. 249 FastCompany.com: Building a Flexible Three-Column Layout 09_588338 ch07.qxd 6/22/05 11:26 AM Page 249 Figure 7-5: Adding more content to our absolutely positioned block demonstrates just how far we’ve come. Another important thing to note in Figure 7-5 is that after increasing the height of our absolutely posi- tioned block, the outer block is partially obscured. Remember that by applying position to the block, we’ve removed it from the normal flow — and in the case of absolutely positioned elements, the browser doesn’t reserve any space for it within the document. Because of this, absolutely positioned elements are designed to overlap other elements on the page, be they positioned or not. This is a very important issue to consider when building a layout with absolute positioning, and one we’ll return to later in greater detail. Positioning That’s Absolutely Relative But what if we want to exercise a bit more control over the position of that inner block? What if we don’t want to position it relative to the browser window, but to the outer div? As it turns out, the absolute positioning we’ve seen so far is only the default behavior. If an absolutely positioned element isn’t placed within another positioned element — that is, if all of its ancestor elements are in their default, static posi- tion — then it will be placed as our example is in Figure 7-4: relative to the boundaries established by the initial containing block, the body element. If you noticed that the last sentence contained quite a few “if”s,” we’re happy we haven’t put everyone to sleep. So, if our absolutely positioned element is contained within another positioned element, what happens then? Let’s see what happens when we apply this bit of logic to the outer div, which, as we determined previously, is the parent to our absolutely positioned element: 250 Chapter 7 09_588338 ch07.qxd 6/22/05 11:26 AM Page 250 Done em.#outer { background: #DDF; border: 4px solid #006; height: 300px; margin: 120px 20px 0; position: relative; } As shown in Figure 7-6, the changes to our inner div are quite striking. Because the outermost div is now a positioned element, it establishes a new positioning context for all absolutely positioned descen- dant elements — in this case, the #inner block. So, the offset of right: 20px; and top: 20px; no longer position the inner div in relation to the root of our markup, but to the container div to which we applied the position: relative; rule. Just to hammer the point home, let’s change the top: 20px; in our #inner selector to bottom: 20px;, like so (see Figure 7-7): #inner { background: #FDC; border: 4px solid #930; position: absolute; right: 20px; bottom: 20px; } Figure 7-6: By setting the outer block to position: relative; the inner block is now positioned in relation to its parent. 251 FastCompany.com: Building a Flexible Three-Column Layout 09_588338 ch07.qxd 6/22/05 11:26 AM Page 251 Figure 7-7: Courtesy of CSS: bulletproof bottom-edge positioning. Ain’t technology grand? Rather than creating a vertical offset between the inner box’s top edge and that of its parent, we’ve instead positioned it 20 pixels from the bottom— all by changing one line in our selector. As we continue through this chapter, we’ll discuss the benefits of this approach in more detail. For now, this relationship between absolutely positioned elements within relatively positioned containers will serve as the basis for our work creating a flexible, three-column layout in the style of FastCompany.com. Building Three Columns: Laying the Foundation Just as when we converted the Harvard University home page to an all-CSS/XHTML layout (see Chapter 2), our three-column layout must be founded upon lightweight, well-meaning markup. To do so, we begin by taking a quick inventory of the content areas on the page (see Figure 7-8). 252 Chapter 7 09_588338 ch07.qxd 6/22/05 11:26 AM Page 252 Figure 7-8: Identifying the areas of content we’ll need to incorporate into our markup. (The footer’s not shown because of the length of the page.) For the purposes of this chapter, we’ll focus on the primary areas of the home page’s layout: ❑ The horizontal header that spans the top of the page ❑ The primary center column, which contains high-priority content and other features of interest ❑ The left- and right-hand columns, which house such auxiliary content as subnavigation, adver- tising banners, and the like Think of each of these top-level blocks as a container for other content — which is, in fact, exactly how FastCompany.com uses them. Within each block, we can store other discrete chunks of content, and apply CSS rules to precisely control the presentation of each. Establishing this flexible, three-column layout is the primary goal of this chapter. Once that has been estab- lished, we can style the finer points of the design to our heart’s delight. Therefore, we’ll focus on establish- ing this layout framework —of header, content, left- and right-hand columns — to prepare our page for a truly professional-looking design. 253 FastCompany.com: Building a Flexible Three-Column Layout 09_588338 ch07.qxd 6/22/05 11:26 AM Page 253 Writing the XHTML: From Mockup to Markup With this in mind, let’s create a basic markup document to reflect this framework, as shown in Listing 7-1. Listing 7-1: The Markup Foundation for Our Three-Column Layout <!DOCTYPE html PUBLIC “-//W3C//DTD XHTML 1.0 Transitional//EN” “http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd”> <html xmlns=”http://www.w3.org/1999/xhtml”> <head> <title>My 3-column layout</title> <meta http-equiv=”Content-Type” content=”text/html; charset=utf-8” /> </head> <body> <div id=”header”> <p>How do you like them apples?</p> <hr /> </div> <div id=”left”> <h2>This is the left column.</h2> <p>Some basic information goes here.</p> <! More content here > </div> <div id=”right”> <h2>This is the right column.</h2> <ul> <li>Did you know that lists rock?</li> <li>They do.</li> <li>Quite a bit.</li> </ul> <! More content here > </div> <div id=”content”> <h1>Welcome to my page layout.</h1> <p>Certe, inquam, pertinax non ero tibique, si mihi probabis ea </p> <! More content here > </div> <div id=”footer”> <hr /> <p>Them apples were <em>tasty</em>.</p> </div> </body> </html> Reflecting the three areas of our content inventory in Figure 7-8, we’ve simply marked up the four divi- sions in our page as such — that is to say, by using the div element. Each of those divs has been given a unique id, which in turn corresponds to the section of the document it represents: the first div is “header,” the next “left,” and so on. We’ve also taken the liberty of including a “footer” block at the bottom of the page. 254 Chapter 7 09_588338 ch07.qxd 6/22/05 11:26 AM Page 254 The ids used in our sample markup here (and throughout the rest of the chapter) are from the markup used on the Fast Company site. While their pages were built nearly two years ago, recent thinking sug- gests it’s best to avoid “presentational names” such as these. By naming our elements according to how they might look, or where they might be positioned on-screen, we’re effectively wedding our markup to one particular presentation. Should we ever redesign our site, what happens when our #left div sud- denly is displayed on the right of the page? Or on the top? Instead, we should consider the meaning of the content contained in our elements, and name those elements accordingly. Perhaps #right would be better described as #advertising, or #left as #subnav. There are no right answers here; instead, we should make our names as descriptive as possi- ble, ensuring an even cleaner separation of structure from style. Within each section of the page, we’ve settled on some simple (and admittedly, pretty arbitrary) content to serve as placeholders. However, even when coding gibberish, we try to keep our code well-meaning: the most important header on the page has been tagged with an h1, the titles of the left and right columns have been accorded a place next in line with h2, and the remainder of the page’s text has been marked up with proper list and paragraph elements. Without any style rules, our markup looks pretty unimpressive indeed (see Figure 7-9). Figure 7-9: Our unstyled HTML document, replete with meaningful markup . . . and, well, meaningless text 255 FastCompany.com: Building a Flexible Three-Column Layout 09_588338 ch07.qxd 6/22/05 11:26 AM Page 255 It’s at this stage that the need for well-meaning, semantically rich markup becomes a bit more evident. When using style sheets to control your site’s presentation, it’s important to consider exactly how users will access your content if they don’t have a CSS-aware browser. When presented with a page that looks like the one in Figure 7-9, users might not be presented with your meticulously planned design. However, they will still be able to access your site’s content; hence our use of horizontal rules ( hr elements) in the header and footer divs. While we’ll use CSS later to hide these elements in our design, these ele- ments can provide a nice break in the content for users on legacy, CSS-blind browsers. For a bit more detail, take the two levels of heading elements we’ve used in our markup. Sighted users surfing sans CSS will be able to quickly tell that “Welcome to my page layout” is weighted with more importance than the titles of our side columns. Screen readers will announce at what level the header has been marked up, which will enable non-sighted users to quickly orient themselves in the page’s hierarchy. And, as accessibility advocates are quick to point out, the biggest blind user on the Web is Google — which is a trite way of saying that search engines don’t care about presentation, but content. Applying this kind of intelligent markup to your content not only helps human users navigate your pages, but helps search engines better understand how they should weight and index them. A Layer of Style With that little digression out of the way, let’s apply some basic presentational rules to our content, as shown in Listing 7-2. Listing 7-2: Applying Basic CSS Rules to Our Document body { color: #000; font: 76%/1.5em “Lucida Grande”, Verdana, Geneva, Helvetica, sans-serif; margin: 0; padding: 0; } h1, h2 { font-family: “Trebuchet MS”, Verdana, Geneva, Helvetica, sans-serif; font-weight: normal; line-height: 1em; margin-top: 0; } #header { background-color: #DFD; border: 2px solid #060; } #footer { background-color: #FDD; border: 1px solid #C00; } #left, #right { background-color: #DDF; border: 2px solid #00C; } 256 Chapter 7 09_588338 ch07.qxd 6/22/05 11:26 AM Page 256 #header hr, #footer hr { display: none; } The first rule applies some basic color and type information to the body element, information that is inherited from each of its descendant elements in the document tree — that is, until we override it in the second rule. By applying a different font-family value to the header elements in our document (h1 and h2), we can override the inheritance and apply a different style than the default. This should, we hope, give them a bit more visual prominence in our rough-cut design. The next three rules apply borders and background colors to the main sections of our document: a bright green for our header, an eye-catching red for the footer block, and a striking blue for the left- and right- hand columns. We’re going for contrast here, not panache — and as you can see from Figure 7-10, that’s exactly what we have. Figure 7-10: We’ve used CSS to apply some basic type and color information to our bare bones HTML document. 257 FastCompany.com: Building a Flexible Three-Column Layout 09_588338 ch07.qxd 6/22/05 11:26 AM Page 257 [...]... to invoke our core .css file, like so: @import url(“core .css ); We’ve effectively created a “wrapper” style sheet — a CSS file that acts as a gateway to other style sheets With this main .css file in hand, we can now include it — and with it, core .css — in our XHTML with one simple link element, placed in the head of our document: And voilà! Our... Figure 8-1: Our unstyled XHTML document, partying like it’s 1994 279 Chapter 8 And again, as always, we can apply a rough style sheet to this document, and slap a bit of mascara on that otherwise unimpressive wall of serifs To begin, let’s create a new style sheet called core .css, and include the rules in Listing 8-2 Listing 8-2: The core .css Style Sheet /* default font and color information */ body... explore different techniques for democratizing our design through the use of style sheet switching By applying a different CSS file to a markup document, we can drastically change any or all aspects of its design — the layout, typography, or color palette This technique may hold incredible appeal to designers because it exponentially decreases the amount of overhead required to redesign a site But, as you’ll... CSS — be wary of this, as proprietary code will invalidate your style sheet and could adversely affect other, more-compliant browsers Additionally, Dean Edwards has written “IE7” (http://dean.edwards.name/IE7/), a library of JavaScript modules that improve Internet Explorer 5+’s support for the CSS specification As a JavaScript-only solution, Edwards’ work has no chance of invalidating your style sheets. .. block in the head of our document Of course, that would muddy our markup with presentational information — and honestly, who wants to hunt down style information across a few hundred XHTML documents? That’s right, some call it “adhering to a strict separation between structure and style. ” We call it “lazy.” In either event, let’s create a second style sheet, and name it main .css; at the top of that... saw briefly how the cascade was written with our users’ needs in mind, that user style sheets are ultimately given precedence over the author style sheets we write The authors of the specification didn’t do this to spite those that design for the Web, but rather to empower those who read it After all, the true wonder of the Web is its promise of universal access: an avenue through which a user can gain... ignore the style sheets that they wouldn’t otherwise understand An added benefit to this intermediary style sheet is that we can place multiple @import rules therein This could come in handy if we needed to break our site’s presentation into multiple files (for example, one for layout, another for color, yet another for typography) Or even better, we can use this technique to manage our various CSS hacks,... readers to forget all that we have taught them about CSS so far, to look beyond the surface of the pool and discover the truth within the truth or something like that Honestly, we’re more fun at parties than we might seem After seven chapters, it’s worth remembering that as convenient as it is to site designers, cascading style sheets can also drastically improve the online experience for the users... as possible Let’s dive right in Laying the Foundation As with other chapters, let’s begin with a valid XHTML document For the purposes of our style sheet switching experiments, the document in Listing 8-1 will do nicely Listing 8-1: The Markup Foundation for Our Style Switcher Experiments ... to test and evaluate it fully before using it in a production environment 275 Chapter 7 Summar y Our whirlwind tour of the Fast Company layout began with a blank slate: the default, normal flow of an unstyled document From there, we examined how CSS positioning could be used to override this default scheme, and allow us to remove elements from their normal place in the document flow This understanding . you can see from Figure 7- 10, that’s exactly what we have. Figure 7- 10: We’ve used CSS to apply some basic type and color information to our bare bones HTML document. 2 57 FastCompany.com: Building. proper list and paragraph elements. Without any style rules, our markup looks pretty unimpressive indeed (see Figure 7- 9). Figure 7- 9: Our unstyled HTML document, replete with meaningful markup divs. While we’ll use CSS later to hide these elements in our design, these ele- ments can provide a nice break in the content for users on legacy, CSS- blind browsers. For a bit more detail,