April 28, 1999

In the ongoing battle against slow download speeds, many Web developers splice large images into several smaller pieces and then re-assemble them into an HTML table. Image splicing is a popular technique and has many advantages.

While slicing up large images can dramatically improve the download time of your pages, large spliced images can lose integrity, or "break", when viewed through a WebTV browser. In the extreme example below, basic image integrity has been lost.

Note: Image breaking can only occur in spliced images - normal JPEGs and GIFs will never exhibit the behavior below.

The good news is that it takes only a few small additions to your code to rehabilitate these broken images, without visible differences in other browsers. This article will cover the basics of making sure that your spliced images display well on a WebTV browser.

Figure 1 - A spliced image can lose integrity

Figure 2 - Same image - still spliced - with a few adjustments

The spliced image in Figure 1 has broken apart instead of re-assembling properly in its table. Pieces seem randomly scattered around. The way in which this image broke, however, is not random at all, and is easy to avoid once we understand a little bit more about how the WebTV browser optimizes tables for display on television.

Horizontal Real Estate on Television

Televisions have a smaller screen resolution than computer monitors, and the WebTV browser does not allow horizontal scrollbars. This means that all Web page content must be compressed or otherwise made to fit in a 544 pixel-wide space. The WebTV browser applies different rules to do this as gracefully as possible, but problems can sometimes arise.

HTML text is never compressed with the WebTV browser. Text will be "re-flowed" to fit the space it is allotted, but the size of the HTML text will never change. Conversely, single images will be compressed as much as is necessary to make them fit into a 544 pixel-wide space; there isn't any other option.

Once multiple images are placed inside of a table, as is done in image splicing, things get more complex. Wrapping a table row to the line below is an option, and might be preferable if the enclosed images are in danger of being compressed to the point of illegibility. Wrapping, unfortunately, harms the linear integrity of the table, and should be used only as a last resort.

Scenarios For Table Compression

In order to make the best decision - to wrap or to compress - the WebTV browser applies a few intuitive rules when deciding how to present table data in a narrower space. If a table row is wider than 544 pixels, the browser must decide whether to wrap the row or compress the images. There are three possible scenarios for shrinking table rows; behavior will be different in each.

Rule One: Images that are stored in separate cells within a table row will never wrap to the next line. The browser will compress all the images in a table row as much as needed to fit on the screen.

Example:

<TABLE name="No_Wrap_Table">
   <TR>
      <TD>
         <IMG src="Big_Image1">
      </TD>
      <TD>
         <IMG src="Big_Image2">
      </TD>
      <TD>
         <IMG src="Big_Image3">
      </TD>
   </TR>
</TABLE>

---

Rule Two: When images are in the same table cell, but are either:

• enclosed by <NOBR> tags, or
• within a table or cell with an explicit width,

Example:

<TABLE name="Compress_Then_Wrap_Table">
   <TR>
      <TD width=600>
         <NOBR>
         <IMG src="Big_Image1">
         <IMG src="Big_Image2">
         <IMG src="Big_Image3">
         </NOBR>
      </TD>
   </TR>
</TABLE>

Rule Three: If images are in the same table cell, and explicit width or <NOBR> tags are not present, the WebTV browser will wrap all images to the next line that don't fit in a 544 pixel-wide table row.

Example:

<TABLE name="Wrap_And_Do_Not_Compress_Table">
   <TR>
      <TD>
         <IMG src="Big_Image1">
         <IMG src="Big_Image2">
         <IMG src="Big_Image1">
      </TD>
   </TR>
</TABLE>

These rules for table row wrapping attempt to anticipate the desire of the author. If adjacent images are not in separate cells, then the author's intent is probably not precise layout, but rather presentation. In that case, legibility is paramount and the images will not be compressed to more than 80% of their original size, even if that means wrapping the content of the cell to the next line. If, on the other hand, images are in distinct cells, layout is probably just as important as content, and table integrity must be maintained.