One-pixel transparent GIF

This is a neat trick that allows one some control over the layout of his (or her) text when writing HTML. As you may know, HTML is a little unkind to whitespace, only drawing a single space between words regardless of how many spaces, tabs or newlines you write in the source. This is a particular pain if you want to indent your text without having to mess about with <blockquote>s. Simply create a GIF image of a single pixel in size (1x1) and set that pixel to the transparent colour. Then using the width and height attributes the invisible image can be set to take up as much space as required allowing you to put giant gaps between words or indent your text by precisely 17 pixels or 10% of the available text area. This can also be used to position other (visible) images and so on.

If the proper optimisations are used such a GIF need only be 85 bytes in size, which though far greater than the single byte for each space/tab/newline it replaces is really pretty small. Besides it's only loaded once, cached and then the cached copy used for the rest (with any modern browser anyway). Paint Shop Pro 7 has a built in image optimiser which is very good at helping you create teeny weeny gifs.

Also the pixel needn't be transparent. One could use exactly the same technique except with a black pixel for creating horizontal or vertical lines (or big fat black boxes).

Of course all of this assumes you're hardcore enough to give a toss about HTML. WYSIWYG yuch.

The one-pixel transparent GIF is typically viewed as a crutch by the more hard-core HTML formatters such as myself. In general, there are better ways to make a buffer space around any elements in the web page, and also to position things exactly where you want them. Indenting text is nothing that a handful of &nbsp; tags can't do, although I must reiterate that you're not supposed to do that in the first place.

Tables have the "cellpadding" and "cellspacing" attributes to create buffer space in the individual cells. Images have the "hspace" and "vspace" attributes to create buffer space around them. In general, when you want precision alignment, tables are your best tool. The table cells can be set to specific pixel widths and heights, or even as a percentage of the available space. If you're careful with formatting your formatting code (meta-formatting?), nesting tables isn't a problem.

The one use I have found for the one-pixel transparent GIF is in ensuring that your table cells can be set to some minimum width and no smaller. Setting the size of the table cell only ensures its maximum width. In most cases this will work out fine, and the table will display the way you want it to, at the width you set it. However if the table requires more room than the browser window has available, the browser will compress any cell columns with spare room to make up the difference. The only thing stopping this compression will be images in the cell (not background images, and certainly not text), or HTML entities with a fixed width such as nested tables or horizontal rules.

Normally this shouldn't be a problem because you should be designing your web page to display properly on any reasonable browser window size. Unfortunately there is no way to ensure that your viewer is being reasonable.

The solution is to put your one-pixel transparent GIF in the cell and use the "width" attribute of the <img src...> tag to set it to your desired cell width. This acts like a cross-brace to prevent the walls from collapsing. This will, of course, protect the entire column of cells in which this is done to one cell. If the viewer tries to use a browser window too narrow to view the page the way you designed it, a horizontal scroll bar will appear at the bottom of the window to view the rest of the web page which is sticking out the side of the viewable window.

In general I find it handy to use this brace to set the exact width of all but one of my table cells and to set a minimum width of the remaining table cell (invariably the one containing the page's main content). So in most of my cells, the transparent GIF will be set to the actual cell width, while in the remaining cell it will be set to, say for example, 500 pixels to prevent the cell from collapsing any narrower than that. It can expand as far as is necessary, but will not be collapsed beyond that minimum width.

I understand that there's these fancy-schmancy div things and cascading style sheets available that can also help. I've never seen the need to use anything beyond HTML, CGI, and javascript myself though, so I've never learned how to use them.

The one-pixel transparent gif is a throwback to the bad old days of web design—an anachronism that every web designer should know about but should never use. Otherwise known as a spacer gif; an image with fixed dimensions to take up space on a page, thus forcing other elements into their proper position. They can be used stand-alone, but achieve maximum effectiveness when used in table-based layouts where they can function as a minimum width and height constraint inside table cells. This concept is not bad per se, but is the tip of the iceberg of a whole slew of bad practices developed during the browser wars that conspire to prevent the forward progress of web design.

Using a transparent gif is just a passive-aggressive way of saying "give me space!"

History

Probably the main reason for the rise to prominence of the transparent gif is that early browsers had quite a bit of trouble adhering to width and height attributes in table cells. Why should table cells matter? Well HTML was never intended to support design or layout; tables were just the only tool available at the time that allowed enough control to satisfy graphic designers who were used to things like PostScript and writing on paper! Transparent gifs were just one of the tools available to coerce tables into a Frankenstein's monster of presentational power. Font tags, nested tables, and spacer gifs were just the marketing-driven solution to a dot-com bubble that needed fuel. No one stopped to question whether these were the right tool for the job. Sure, CSS had been specced out in 1996 and 1998, but we needed solutions now, and all this gobbledygook worked in the browsers of the day.

Web Standards

It was all business as usual until 2000 when all the startups went poof, and suddenly $100,000 for a website didn't seem so reasonable anymore. It was at this time that the web standards movement really began to take off. CSS 1 and 2 were starting to see respectable support in all the new browsers, and being able to lay out a complex page without going three levels deep into tables became reality.

Of course these old practices had become the defacto standard, and you still see a sizable population of professional designers using techniques such as the transparent gif. Given that there's a large amount of development around this methodology, it's no wonder that designers are having a hard time making the jump to CSS. Designers using Dreamweaver can continue down this road blissfully indifferent to needless complexity of the code they're creating. Unfortunately most web design does not live in a vacuum anymore. There are databases and applications to integrate, and that means programmers need to slice and dice mockups into dynamic code. This becomes a problem when you can't figure out which <table> goes with which </table> and which of those 100 spacer gifs needs to be included and where.

Alternatives

Don't get me wrong, I'm not a purist along the lines of "thou shalt not use table for layout." I don't scoff at the occasional use of presentational HTML. I won't whine about valign and width attributes in HTML. I'm a pragmatist. Learn CSS, you won't regret it.

If you want to indent text use:

text-indent: 20px

If you want your table cell a certain size:

width: 100px

If you want space in between paragraphs use:

margin-bottom: 20px

Of course there's a learning curve associated with CSS, but it's really the right tool for the right job.

One-pixel transparent gifs may be a web developer's crutch, or they may not be. One thing they often are, however, is a subtle way of eroding your privacy. Because the HTTP spec (the thing that defines how web pages are accessed and transmitted) allows a site to attach cookies to images, users of a website may be transmitting all of their browsing information not just to the website they intend to browse, but also, unknowingly, to a third party that only serves up one-pixel transparent gifs. This way of tracking people was, for a time, so common that these were referred to as web bugs.

Whole services have been built on the idea that a person won't notice a one-pixel transparent gif. If you want to track whether a person has opened and read your email, then there exist (or at least used to exist) services that will give you an image to put in your html email. If that image ever gets downloaded, then your email's recipient has most likely read your message. This tactic is also frequently used by spammers in order to figure out which email addresses are valid. They put pictures at unique URLs for each email they send out, and all the images that get downloaded correspond to email addresses that people actually read.

Because when your computer downloads an image it also sends a whole host of other data to the server it is requesting the image from, they also know what download and display tool you are using, allowing them to specifically target viruses and trojans towards only the people who are infectable.

All of the tactics that use email can be foiled if you choose not to display remote images in your email reader, or if you don't use HTML email at all. This latter is actually recommended, as your text is what is important, not the font you use. Despite the relative ease with which these attacks can be rendered useless, their prevalence in the early days of the web and HTML email has led to a distaste for one-pixel transparent gifs amongst privacy advocates. Much adblocking software will block them, and their presence in an email will often trigger spam warnings.

If you are using them with the best of intentions, and only for spacing and the like, these little dots should be used with care. The abuse of these in the early days of the web has meant that web browsers and privacy filters prevent them from being dealt with in a consistent manner across all browsers. If your layout depends on people doing something that has historically been bad for them, you might want to fix that.