mozilla

Revision 168143 of Images, Tables, and Mysterious Gaps

  • Revision slug: Images,_Tables,_and_Mysterious_Gaps
  • Revision title: Images, Tables, and Mysterious Gaps
  • Revision id: 168143
  • Created:
  • Creator: Mathieu Deaudelin
  • Is current revision? No
  • Comment
Tags: 

Revision Content

Almost no matter when you started creating Web pages, odds are pretty high you have one or more designs based on the classic "convoluted tables and lots of images" paradigm. Whether you've sliced up a logo so it fits in well with the design, or used tons of single-pixel spacer GIFs, the principles (and perils) remain largely the same. Back in the early days, this approach worked, because browsers would usually make a table cell exactly as wide and tall as an image it contained.

Fast forward to 2001, and the rise of standards-based browsers that lay out pages using HTML and CSS instead of their own private layout algorithms. Thanks to an obscure corner of the CSS specification, every design based on a precise layout of small images in table cells have become visual disasters just waiting to happen. All it takes is a modern browser and the right DOCTYPE, and kaboom!

The Components

Let's take a close look at the breeding ground for trouble, and why this is a problem. We start with a simple case, illustrated in Figure 1: a one-cell table containing an image.

Figure 1

Obviously most designs are a touch more complicated than this, but we don't need anything more for our purposes. One image, one cell-- that's all it takes. There's nothing apparently wrong with that example. There isn't supposed to be, since it's an example of how browsers have traditionally behaved.

Now let's see what that same simple table looks like in a modern browser when the page has a strict DOCTYPE.

Figure 2

Original Document Information

  • Author(s): Eric Meyer
  • Last Updated Date: March 21st, 2003
  • Copyright Information: 2001-2003, Netscape

Revision Source

<p>Almost no matter when you started creating Web pages, odds are pretty high you have one or more designs based on the classic "convoluted tables and lots of images" paradigm. Whether you've sliced up a logo so it fits in well with the design, or used tons of single-pixel spacer GIFs, the principles (and perils) remain largely the same. Back in the early days, this approach worked, because browsers would usually make a table cell exactly as wide and tall as an image it contained.
</p><p>Fast forward to 2001, and the rise of standards-based browsers that lay out pages using HTML and CSS instead of their own private layout algorithms. Thanks to an obscure corner of the CSS specification, every design based on a precise layout of small images in table cells have become visual disasters just waiting to happen. All it takes is a modern browser and the right DOCTYPE, and kaboom!
</p>
<h3 name="The_Components"> The Components </h3>
<p>Let's take a close look at the breeding ground for trouble, and why this is a problem. We start with a simple case, illustrated in Figure 1: a one-cell table containing an image.
</p><p><img align="none" alt="Figure 1" src="File:en/Media_Gallery/Images-tables-gaps-figure1.gif">
</p><p>Obviously most designs are a touch more complicated than this, but we don't need anything more for our purposes. One image, one cell-- that's all it takes. There's nothing apparently wrong with that example. There isn't supposed to be, since it's an example of how browsers have traditionally behaved.
</p><p>Now let's see what that same simple table looks like in a modern browser when the page has a strict DOCTYPE.
</p><p><img align="none" alt="Figure 2" src="File:en/Media_Gallery/Images-tables-gaps-figure2.gif">
</p>
<div class="originaldocinfo">
<h3 name="Original_Document_Information"> Original Document Information </h3>
<ul><li> Author(s): Eric Meyer
</li><li> Last Updated Date: March 21st, 2003
</li><li> Copyright Information: 2001-2003, Netscape
</li></ul>
</div>
Revert to this revision