• Create BookmarkCreate Bookmark
  • Create Note or TagCreate Note or Tag
  • PrintPrint
Share this Page URL

Chapter 4. Creative Floating > A Common Approach

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 catalogs—so, 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).


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.

  • Creative Edge
  • Create BookmarkCreate Bookmark
  • Create Note or TagCreate Note or Tag
  • PrintPrint