Category list

- page 33

Summary

You may be familiar with the term baker's dozen . A smart baker will always add an extra muffin, cookie, or whatever to the batch. If one of the cookies burns or falls apart (or gets eaten by the baker), there's always an extra to make a complete dozen. In this way, the baker plans for the unpredictable. Why not bake an extra cookie or two when you've gone to all the trouble of mixing up an entire batch? Sometimes, the extra cookie is needed; sometimes it isn't.

All cookies aside (but still within reach, of course), when we build vertical expansion of horizontal components into our designs, it's as if we're making a baker's dozen of our ownwe're planning for the unexpected and making room for text adjustments and varying amounts of content. In the end, we're saving time and giving the user (as well as site editors) better control and increasing accessibility.

Here are some points to remember when you're building horizontal design components:

Taking nonessential graphics out of the markup and using background images within the CSS can help control code bloat.
Use the "opposing floats" method for positioning content on opposite sides of a container.
When the amount of content to be placed inside a design component is unknown, use two background images to let that component expand and contract.
Plan for more space than you think you need. Make that extra chocolate chip cookie.

Chapter 4. Creative Floating

Use floats to achieve grid-like results.

In previous chapters, we started each bulletproof approach by first deciding how the component we're dealing with should be structuredthat is, what markup is most appropriate for the content being displayed? This, I believe, is an important step when building any Web site. With a goal of selecting elements that convey the most meaning to what they surround, you hope to be left with enough "style hooks" to apply a compelling design with CSS. But more importantly, choosing the best markup for the job means the content of the page has the best chance of being understood properly across the widest possible range of browsers and devices. It's the foundation and should convey a clear message, regardless of the design applied on top of it via CSS. Additionally, if we take time to consider optimal structure (meaningful XHTML) and design (CSS) separately , changing that design later on down the road becomes less like finding a needle in a haystack and more like changing the slipcover on a sofa.

Settling on an optimal structure doesn't have to limit the way it's displayed, however. As we'll explore in this chapter, the creative use of the float property can give us grid-like resultswith a fraction of the code we'd need with the nested-tables approach. By paring down the markup to its barest essentials, we make it easier for browsers, software, and all devices to read our contentat the same time making it easier for other designers and developers to modify and edit these components .

We start this chapter off by rebuilding a box containing multiple pairings of an image, title, and description. This is a common layout requirement found on sites all over the Web, and one that we can handle elegantly using minimal markup and CSS.

A Common Approach

Often found on sites to display teasers to articles, products, files, and so forth, the image/title/description package should look familiar to you. A related image is usually aligned to one side against the title and quick description (Figure 4.1).

Figure 4.1. Image, title, and description "packages" like this one are found throughout the Web.

There might also be several of these pairings in a row, each pointing to an article, product, or other destination. Traditionally, one might use a <table> to structure all of this, using spacer GIFs to control white space and gutters in between the items (Figure 4.2).

Figure 4.2. Tables and spacer GIFs may be used to space and position the items.

Some could argue that what we're dealing with here is tabular data (think spreadsheets, calendars, statistics) and I'm not here to debate the use of tables. What we will do is use a particular component from a popular real-world site as a guideline, which we'll then reconstruct using far less markup and CSS to achieve table-esque results. In the end, we'll toss out extraneous markup and unnecessary images to create something more flexible, accessible, and manageable from an editing viewpoint.

Figure 4.3 shows the component from Furniture Shack (a fictitious online merchant of fine home furnishings) that we'll reconstruct. As you can see, it's a bordered box containing three "teasers" to a variety of products available from the Furniture Shack stores.

Figure 4.3. The Furniture Shack home page features a box of "teasers."

Each "teaser" contains a product image, title, and short description. Both the style and layout fit the look of the company's stores and catalogsso, well done there.

Under the hood, this box is built using a series of nested tables and spacer GIFs, and it's worth pointing out that the title text is served as an image. The code required to render this particular layout could easily fill a beautiful cherry-stained chest of drawers (with brushed-nickel knobs ).

WHY IT'S NOT BULLETPROOF

For this particular example, the amount of code required could be reason enough for considering a better approach (Figure 4.4). Reducing the code will not only cut down on file size (which in turn will reduce required server space and speed up the downloading of pages) but it will also make the editing of the component from a production standpoint far easier. When we take the time to choose the best markup for the task at hand, the simplified results will be easier for servers and site editors to read and understand. Think of it as flexibility in terms of maintenance as well.

Figure 4.4. Avoid drowning in a sea of code.

Because of the code bloat, the common approach also scores low in terms of accessibility to a wide range of software and devices. Accessing the rigid construction of nested tables and spacer GIF shims that are used to lay out the design with anything but a standard Web browser could certainly prove to be trying for any user . As we'll discover, deflating the code bloat and increasing the accessibility doesn't have to compromise the design.