Several things are worth noting here. The first is that TIFF is not at all suited as a web format, simply because it is not supported by any major browser. (This will not be a big surprise to the web designers in the audience.) Even as an editing format, TIFF's main strength is its speed. With regard to portability between image-editing apps, the facts are a little murkier, however. GIF traditionally has been the best-supported format due to its simplicity, but a number of shareware and freeware applications have dropped support due to patent-licensing issues. TIFF has been widely supported, too, but it has also been widely cursed for its incompatibilities among apps. And PNG, of course, is still relatively new. By now it is supported by most of the main image editors, but some of its features (such as 48-bit truecolor) are often supported as read-only capabilities or ignored altogether.

The choice of a web format depends almost entirely on what features are required in the image. Transparency automatically rules out JPEG; partial transparency rules out GIF, as well. For animation, GIF is the only choice. For opaque, photographic images, JPEG is the only reasonable choice--its compression can't be beat. The truly critical issue, however, is portability across browsers. GIF and JPEG are relatively safe bets, but what about PNG? By late 1997, it was supported (at least minimally) in virtually all browsers; Microsoft's Internet Explorer 4.0 and Netscape's Navigator 4.04 finally got native PNG support in October and November 1997, respectively.[9] But gamma correction was supported only by Internet Explorer, and PNG transparency was almost unusable. At the time of this writing, Navigator 5.0 is still unreleased, and IE 5.0 for Windows is unchanged from version 4.0. But there are strong indications that the Big Two will finally support both gamma and full alpha-channel transparency in their next major releases.

[9] Most other web browsers have supported PNG natively since 1995 or 1996.

Of course, that begs the question of when it is safe to start using PNG on the Web. In theory, the extended OBJECT tag in HTML 4.0 provides the means to do so immediately. OBJECT is a ``container'' in HTML parlance, similar to FONT tags or BLOCKQUOTE; it affects the stuff inside it, between the <OBJECT> and </OBJECT> tags--including other (nested) OBJECTs. Unlike most container tags, however, OBJECTs refer to their own data (as part of the <OBJECT> tag itself), and this can include images. In fact, one can think of an OBJECT as an extremely enhanced IMG tag. Whereas IMG refers to a single datatype (just images) and can display a small amount of plain text if the image can't be rendered (via the ALT attribute), OBJECTs can refer to numerous datatypes (images, VRML, Shockwave, Java applets, and so on) and can display arbitrary HTML if their main datatype cannot be rendered (via the contents of the OBJECT container). Thus, browsers peel OBJECT blocks like onions, first trying to render the outermost layer and moving inward until they find something they can handle. As soon as they find something to render, the remainder of the block is discarded. (This is the sense in which the inner stuff is ``affected'': it may be completely ignored. Indeed, only one layer is not ignored...at least according to the HTML 4.0 specification.)

So the preferred approach for PNG images is simply to wrap an OBJECT tag around an old-style IMG tag, where the OBJECT refers to the PNG and the IMG refers to a JPEG or GIF version of the same image. I'll provide some concrete examples of this in Chapter 2, "Applications: WWW Browsers and Servers", Applications: WWW Browsers and Servers. Newer browsers that support both PNG and OBJECT will render the PNG in the outer OBJECT, ignoring the IMG tag. Older browsers will either ignore OBJECT as an unknown tag or else parse it but recognize that they cannot render the PNG; either way, they will use the GIF or JPEG from the inner IMG tag, or the text in the ALT attribute if they do not support images.

At least, that's the theory. The main problem with this approach is that no version of Navigator or Internet Explorer up through the latest 4.x releases handles OBJECT tags correctly. Both browsers will attempt to find a plug-in to handle an OBJECT image; lacking that, they will either render the inner IMG or fail entirely. I'll look at this in more detail in Chapter 2, "Applications: WWW Browsers and Servers".

But plug-in oddities notwithstanding, the IMG-within-an-OBJECT approach works moderately well now and will only get better as browsers improve their conformance with WWW standards and as the need for external PNG plug-ins diminishes. Indeed, most of the images on the Portable Network Graphics home site are referenced in this manner. As for referring to PNG images directly in old-style IMG tags, which is more commonly thought of as ``using PNG on the Web''--that depends on the images and on the target audience. For example, the Acorn home site already uses PNG images in places; their audience is largely Acorn users, and Acorn Browse has perhaps the best PNG support of any browser in the world. But sites targeted at the average user running Navigator or Internet Explorer must keep in mind that any given release of the Big Two browsers achieves widespread use only after a year or so, and even then, a large percentage of users continue to use older versions. From a PNG perspective, this means that late 1998 was about the earliest it would have been reasonable to begin using IMG-tag PNGs on general-purpose sites. Sites that would like to make use of PNG transparency or gamma support will have to wait until about a year after the 5.0 releases occur, which presumably means sometime in the year 2000. (PNG as the Image Format of the New Millennium[10] has a nice ring to it, though.)

[10] That would be the millennium of four-digit years beginning with the numeral ``2,'' which, of course, is what everyone will be celebrating on New Year's Eve, 1999. (The Third Millennium is the one that starts on January 1, 2001.)