Think carefully before using
images. Background tiling is neat, and if used appropriately,
backgrounds can enhance both the practical and asthetic value of your pages.
However, it is very easy to make slow, "colorblind," and, in some
cases, unreadable pages. So, if you decide to use a background, you should
take care to use images that are both simple and small.
Consider using a solid background color instead. Just modify
your page's <BODY> tag:
Don't forget that not every browser supports backgrounds. Thus,
don't put a critical image in the background because some browser users
will never see it (furthermore, unless those readers look at the source,
they will never know it even exists). Keep in mind that backgrounds are
meant to enhance text, not replace it! Also, in certain
circumstances, browsers may not display the background even if they support
background tiling (such as if image loading is turned off, or if the
background contains non-ditherable colors).
If you do decide to go with a background, keep it small (under
25 Kb)! Interlacing will help by making the background seem
to load faster. JPEG images are fine (in fact, they may be preferable)
for backgrounds. Don't even think about using a
GIF background to avoid tiling--it may look cool, but most people will
abort before it's done loading. A small background doesn't necessarily
mean boring or unattractive. Some of the best patterns I've
seen are under 10 KB.
Don't assume that a background will look the same on every platform.
A background that looks good on your specific browser may look horrible
on another system. Even worse, it may make the text impossible to read,
even if you take care to pick contrasting color schemes.
Case in point: I used to have this image as the background for the HPCS:
I didn't think there would be a problem, especially since I was using black
text. However, I soon discovered that the page text was indecipherable
on Macs with greyscale or 16.7 million color displays. Although the background
looked fine on all other flavors of Netscape, for some reason it caused
a serious usability problem. So I opted for a solid background color instead.
The moral of the story is that you should extensively test your pages for
compatibility on as many different browsers and computer platforms as possible.
"Ramping-up," and "color fade-in" will no longer
work. In Netscape Navigator 1.1, there was a bug that allowed page
creators to have more than one <BODY> tag in their documents. The
net result was that you could cause background colors to change several
times before the page was drawn (supposedly creating a colorful effect--I
was never very impressed with this). Well, no longer! Netscape has acknowledged
that this is bad HTML since there can only be one <BODY> tag per
document. Thus, Netscape, beginning with version 1.2b1, only recognizes
the first <BODY> tag.
One "feature" that this bug allowed was multiple text colors.
Recent version of Netscape Navigator now support multiple text colors in
the same document using the <FONT COLOR> tag.
If you use a background texture, always include a BGCOLOR argument
in the <BODY> tag. The BGCOLOR will load before the texture,
providing a visual cue to the reader that something is going to
happen (a very important cue when the network connection is slow). Although
some browsers can now load the body elements before the background, using
a BGCOLOR argument will have an important secondary function: specifying
the background color if the background tile cannot load. If you do not
include BGCOLOR and the texture cannot load, Netscape will automatically
default to the standard (grey) background and link colors. An example <BODY>
tag that will avoid that:
That will first change the browser window color to sky blue then begin
loading "background.gif", replacing the sky blue color. If "background.gif"
is unavailable, then the sky blue background remains. In either case, the
text and link colors will be black, cornsilk, medium blue, and gold, respectively.