Showing posts with label webpage. Show all posts
Showing posts with label webpage. Show all posts

Sunday, September 26, 2010

CSS Tutorial : Image maps

Image maps enable you to define multiple links within a single image; for example, if you
have a weather map, you could use an image map to link to each region’s weather forecast;
or if you had a picture of your office, you could use an image map to make each of
the objects clickable, leading to pages explaining more about each of them. Clickable
regions within image maps can be fairly basic—rectangles or circles—or complex polygonal
shapes. Note that there are both server-side and client-side versions of image maps—
server-side image maps are now considered obsolete and pose accessibility problems, and
even client-side image maps tend to be avoided by most designers, although use of alt text
can help them become reasonably accessible.
Regardless of the complexity of the image and the defined
regions, the method of creating an image map remains the
same. To the right is the image used in this section to show
how a basic image map is created. It contains three geometric
shapes that will be turned into clickable hot-spots.
The image is added to the web page in the usual way (and
within a block element, since img is an inline element), but
with the addition of a usemap attribute, whose value must be
preceded by a hash sign (#).
<div id="wrapper">
<img src="image-map-image.gif" alt="Shapes" width="398" height="398"
å usemap="#shapes" />
</div>
The value of the usemap attribute must correlate with the name and id values of the associated
map element. Note that the name attribute is required for backward compatibility,
whereas the id attribute is mandatory.
<map id="shapes" name="shapes">
</map>
The map element acts as a container for specifications regarding the map’s active areas,
which are added as area elements.
<map id="shapes" name="shapes">
<area title="Access the squares page." shape="rect"
å coords="29,27,173,171" href="square.html" alt="A square" />
<area title="Access the circles page" shape="circle"
å coords="295,175,81" href="circle.html" alt="A circle" />
<area title="Access the triangles page" shape="poly"
å coords="177,231,269,369,84,369" href="triangle.html"
å alt="A triangle" />
</map>
Each of the preceding area elements has a shape attribute that corresponds to the
intended active link area:
rect defines a rectangular area; the coords (coordinates) attribute contains two
pairs that define the top-left and bottom-right corners of the rectangle in terms of
pixel values (which you either take from your original image or guess, should you
have amazing pixel-perfect vision).
circle is used to define a circular area; of the three values within the coords
attribute, the first two define the horizontal and vertical position of the circle’s
center, and the third defines the radius.
poly enables you to define as many coordinate pairs as you wish, which allows you
to define active areas for complex and irregular shapes—in the previous code
block, there are three pairs, each of which defines a corner of the triangle.
Creating image maps is a notoriously tedious process, and it’s one of the few occasions
when I advise using a visual web design tool, if you have one handy, which can be used to
drag out hot-spots. However, take care not to overlap defined regions—this is easy to do,
and it can cause problems with regard to each link’s active area. If you don’t have such a
tool handy, you’ll have to measure out the coordinates in a graphics package.


**Note:  that some browsers will place a border around the image used for an
image map. This can be removed by using CSS to set the image’s border to 0
(either via applying a class to the image, or via a contextual selector).

Links and images

Although links are primarily text-based, it’s possible to wrap anchor tags around an image,
thereby turning it into a link:
<a href="a-link.html"><img src="linked-image.gif" width="40"
å height="40" /></a>
Some browsers border linked images with whatever link colors have been stated in CSS (or
the default colors, if no custom ones have been defined), which looks nasty and can displace
other layout elements. Historically, designers have gotten around this by setting the
border attribute within an img element to 0, but this has been deprecated. Therefore, it’s
best to use a CSS contextual selector to define images within links as having no border.
a img {
border: 0;
}
Clearly, this can be overridden for specific links. Alternatively, you could set an “invisible”
border (one that matches the site’s background color) on one or more sides, and then set
its color to that of your standard hover color when the user hovers over the image. This
would then provide visual feedback to the user, confirming that the image is a link.
a img {
border: 0;
border-bottom: 1px solid #ffffff;
}
a:hover img {
border-bottom: 1px solid #f22222;
}
In any case, you must always have usability and accessibility at the back of your mind when
working with image-based links. With regard to usability, is the image’s function obvious?
Plenty of websites use icons instead of straightforward text-based navigation, resulting in
frustrated users if the function of each image isn’t obvious. People don’t want to learn
what each icon is for, and they’ll soon move on to competing sites. With regard toaccessibility, remember that not all browsers can zoom images, and so if an image-based
link has text within it, ensure it’s big enough to read easily. Whenever possible, offer a textbased
alternative to image-based links, and never omit alt and title attributes (discussed
earlier in this chapter). The former can describe the image content and the latter can
describe the link target (i.e., what will happen when the link is clicked).
Therefore, the example from earlier becomes the following:
<a href="a-link.html"><img title="Visit our shop"
å src="linked-image.gif"width="40" height="40"
å alt="Shopping trolley" /></a>

The difference between a and a:link

Many designers don’t realize the difference between the selectors a and a:link in CSS.
Essentially, the a selector styles all anchors, but a:link styles only those that are clickable
links (i.e., those that include an href attribute) that have not yet been visited. This means
that, should you have a site with a number of fragment identifiers, you can use the a:link
selector to style clickable links only, avoiding styling fragment identifiers, too. (This prevents
the problem of fragment identifiers taking on underlines, and also prevents the
potential problem of user-defined style sheets overriding the a rule.) However, if you
define a:link instead of a, you then must define the visited, hover, and active states,
otherwise they will be displayed in their default appearances. This is particularly important
when it comes to visited, because that state is mutually exclusive to link, and doesn’t
take on any of its styling. Therefore, if you set font-weight to bold via a:link alone, visited
links will not appear bold (although the hover and active states will for unvisited
links—upon the links being visited, they will become hover and active states for visited
links and will be displayed accordingly).

Correctly ordering link states

The various states have been defined in a specific order in the previous example: link,
visited, hover, focus, active. This is because certain states override others, and those
“closest” to the link on the web page take precedence.
There is debate regarding which order the various states should be in, so I can only provide
my reasoning for this particular example. It makes sense for the link to be a certain
color when you hover over it, and then a different color on the active state (when
clicked), to confirm the click action. However, if you put the hover and active states in
the other order (active, hover), you may not see the active one when the link is clicked.
This is because you’re still hovering over the link when you click it.
The focus state is probably primarily use keyboard users, and so they won’t typically see
hover anyway. However, for mouse users, it makes logical sense to place focus after hover,
because it’s a more direct action—in other words, the link is selected, ready for activation
during the focus state; but if you ordered the states focus, hover, a link the cursor is
hovering over would not change appearance when focused, which from a user standpoint
is unhelpful.
However, there is a counter argument that recommends putting focus before hover, so
that when an already focused link (or potentially any other focused element for non-IE
browsers) is hovered over, it will change from the focused state to indicate that it is now
being hovered over. Ultimately, this is a chicken-and-egg scenario—do you want a hovered
link to change from hover to focus to active? The focus will get lost somewhere in there
until the link is depressed (and the active state removed), by which time the link will be
in the process of being followed.
In the end, the decision should perhaps rest with how you’re styling states and what information
you want to present to the user, and often the focus state is a duplication of hover
anyway, for the benefit of keyboard users. And on some occasions, it doesn’t matter too
much where it’s put, if the styling method is much different from that for other states—
for example, when a border is applied to focus, but a change of color or removal of
underlines is used for the other states. However, if you decide on LVFHA or some other
order, you’ll have to make your own way of remembering the state order!

Defining link states with CSS

CSS has advantages over the obsolete HTML method of defining link states. You gain control
over the hover and focus states and can do far more than just edit the state colors—
although that’s what we’re going to do first.
Anchors can be styled by using a tag selector:
a {
color: #3366cc;
}
In this example, all anchors on the page—including links—are turned to a medium blue.
However, individual states can be defined by using pseudo-class selectors (so called
because they have the same effect as applying a class, even though no class is applied to
the element):
a:link {
color: #3366cc;
}
a:visited {
color: #666699;
}
a:hover {
color: #0066ff;
}
a:focus {
background-color: #ffff00;
}
a:active {
color: #cc00ff;
}

Top-of-page links

Internal page links are sometimes used to create a top-of-page/back-to-top link. This is
particularly handy for websites that have lengthy pages—when a user has scrolled to the
bottom of the page, they can click the link to return to the top of the document, which
usually houses the navigation. The problem here is that the most common internal linking
method—targeting a link at #top—fails in many browsers, including Firefox and Opera.
<a href="#top">Back to top</a>
You’ve likely seen the previous sort of link countless times, but unless you’re using Internet
Explorer or Safari, it’s as dead as a dodo. There are various workarounds, though, one of
which is to include a fragment identifier at the top of the document. At the foot of the
web page is the Back to top link shown previously, and the fragment identifier is placed
at the top of the web page:
<a id="top" name="top"></a>
This technique isn’t without its problems, though. Some browsers ignore empty elements
such as this (some web designers therefore populate the element with a single space); it’s
tricky to get the element right at the top of the page and not to interfere with subsequent
content; and, if you’re working with XHTML Strict, it’s not valid to have an inline element
on its own, outside of a block element, such as p or div.
Two potential solutions are on offer. The simplest is to link the top-of-page link to your
containing div—the one within which your web page’s content is housed. For sites I
create—as you’ll see in Chapter 7—I typically house all content within a div that has an id
value of wrapper. This enables me to easily control the width of the layout, among other
things. In the context of this section of this chapter, the wrapper div also provides something
for a top-of-page link to jump to. Clicking the link in the following code block would
enable a user to jump to the top of the wrapper div, at (or very near to) the top of the
web page.
<a href="#wrapper">Top of page</a>
Note that since standalone inline elements aren’t valid in XHTML Strict, the preceding
would either be housed within a paragraph or a footer div, depending on the site.
Another solution is to nest a fragment identifier within a div and then style the div to sit
at the top left of the web page. The HTML for this is the following:
<div id="topOfPageAnchor">
<a id="top" name="top"> </a>
</div>
In CSS, you would then add the following:
div#topOfPageAnchor {
position: absolute;
top: 0;
left: 0;
height: 0;
}
Setting the div’s height to 0 means it takes up no space and is therefore not displayed; setting
its positioning to absolute means it’s outside the normal flow of the document, so it
doesn’t affect subsequent page content. You can test this by setting the background color
of a following element to something vivid—it should sit tight to the edge of the browser
window edges.

Creating and styling web page links

With the exception of search boxes, which are forms based on and driven by server-side
scripting, online navigation relies on anchor elements. In its simplest form, an anchor element
looks like this:
<a href="http://www.friendsofed.com/">A link to the friends of ED
å website</a>

The href attribute value is the URL of the destination document, which is often another
web page, but can in fact be any file type (MP3, PDF, JPEG, and so on). If the browser can
display the document type (either directly or via a plug-in), it does so; otherwise, it downloads
the file (or brings up some kind of download prompt).
There are three ways of linking to a file: absolute links, relative links, and root-relative
links. We’ll cover these in the sections that follow, and you’ll see how to create internal
page links, style link states in CSS, and work with links and images. We’ll also discuss
enhanced link accessibility and usability, and link targeting.

Absolute links
The preceding example shows an absolute link, sometimes called a full URL, which is typically
used when linking to external files (i.e., those on other websites). This type of link
provides the entire path to a destination file, including the file transfer protocol, domain
name, any directory names, and the file name itself. A longer example is
<a href="http://www.wireviews.com/lyrics/instar.html">Instar lyrics</a>
In this case, the file transfer protocol is http://, the domain is wireviews.com, the directory
is lyrics, and the file name is instar.html.
If you’re linking to a website’s homepage, you can usually leave off the file name, as in the
earlier link to the friends of ED site, and the server will automatically pick up the default
document—assuming one exists—which can be index.html, default.htm, index.php,
index.asp, or some other name, depending on the server type. However, adding a trailing
slash after the domain is beneficial (such as http://www.wireviews.com/). If no default
document exists, you’ll be returned a directory listing or an error message, depending on
whether the server’s permissions settings enable users to browse directories.

Relative links
A relative link is one that locates a file in relation to the current document. Taking the
Wireviews example, if you were on the instar.html page, located inside the lyrics directory,
and you wanted to link back to the homepage via a relative link, you would use the
following code:
<a href="../index.html">Wireviews homepage</a>
The index.html file name is preceded by ../, which tells the web browser to move up one
directory prior to looking for index.html. Moving in the other direction is done in the
same way as with absolute links: by preceding the file name with the path. Therefore, to
get from the homepage back to the instar.html page, you would write the following:
<a href="lyrics/instar.html">Instar lyrics</a>
In some cases, you need to combine both methods. For instance, this website has HTML
documents in both the lyrics and reviews folders. To get from the instar.html lyrics
page to a review, you have to go up one level, and then down into the relevant directory
to locate the file:
<a href="../reviews/alloy.html">Alloy review</a>

Root-relative links
Root-relative links work in a similar way to absolute links, but from the root of the website.
These links begin with a forward slash, which tells the browser to start the path to the file
from the root of the current website. Therefore, regardless of how many directories deep
you are in the Wireviews website, a root-relative link to the homepage always looks
like this:
<a href="/index.html">Homepage</a>
And a link to the instar.html page within the lyrics directory always looks like this:
<a href="/lyrics/instar.html">Instar lyrics</a>
This type of link therefore ensures you point to the relevant document without your
having to type an absolute link or mess around with relative links, and is, in my opinion,
the safest type of link to use for linking to documents elsewhere on a website. Should a
page be moved from one directory to one higher or lower in the hierarchy, none of the
links (including links to style sheets and script documents) would require changing.
Relative links, on the other hand, would require changing; and although absolute links
wouldn’t require changing, they take up more space and are less modular from a testing
standpoint; if you’re testing a site, you don’t want to be restricted to the domain in
question—you may wish to host the site locally or on a temporary domain online so that
clients can access the work-in-progress creation.
All paths in href attributes must contain forward slashes only. Some software—
notably older releases from Microsoft—creates and permits backward slashes (e.g.,
lyrics\wire\154.html), but this is nonstandard and does not work in non-Microsoft
web browsers.

Monday, September 20, 2010

Working with style sheets for print

In the old days (and, frankly, in the not-so-old days, since the practice somehow survives),
designers often worked on so-called printer-friendly sites, run in parallel with the main
site. However, if you’re using CSS layouts, it’s possible to create a style sheet specifically for
print, which you can use to dictate exactly which elements on the page you want to print,
which you want to omit, and how you want to style those that can be printed.
As mentioned earlier in the book, a print style sheet is attached to web pages using the
following HTML:
<link rel="stylesheet" type="text/css"media="print"
å href="print-style-sheet.css" />
The media attribute value of print restricts the CSS solely to print, and within the print
style sheet, you define styles specifically for print, such as different fonts and margins. In
the example in the download files, I’ve used a version of the business website, which you
can access via the sme-website-print folder in the chapter 10 folder. The print style
sheet is sme-print.css, and if you compare it to the main style sheet, you’ll see that it’s
much simpler and massively honed down.
The defaults section houses a single body rule, defining padding (to take into account varying
printer margins, 5% is a good horizontal padding to use), the background color (white
is really the only choice you should use, and it’s usually the default, but setting it explicitly
ensures this is the case), the text color (black is best for contrast when printing), and the
font. There’s absolutely no point in trying to ape your onscreen design and typography in
print—instead, use values that enhance the printed version. In the example’s body rule
(shown in the following code block), serif fonts are defined for font-family, because serifs
are easier to read in print. Note that you’re not only restricted to web-safe fonts at this
point either—you can define choices based on fonts that come with the default install of
Windows and Mac OS, hence the choices of Baskerville (Mac) and Palatino Linotype
(Windows), prior to Times New Roman and Times.
body {
padding: 0 5%;
background: #ffffff;
font-family: Baskerville, "Palatino Linotype", "Times New Roman",
å "Times", serif;
line-height: 16pt;
}
In the structure section, the #masthead declaration sets display to none. That’s because
this area of the page is of no use for printed output—you simply don’t need website masthead
and navigation offline. (This is, of course, a generalization, and in rare cases this may
not be applicable; however, in the vast, vast majority of websites I’ve created, the printed
version has not required the masthead and navigation links.) Note that if other areas aren’t
required, just use a grouped selector instead of this rule with a lone selector, as shown in
the following code block (which isn’t in the example CSS):
#element1, #element2, .class1, .class2 {/* these items won't be
å printed */
display: none;
}Because pixel values don’t tend to translate to print well, some settings may need to be
redefined. An example in this case is the two-column section of the page. The widths and
margins were initially defined in pixels, but in the print CSS, it makes more sense to define
these values in percentages. (Note that the 9.99% value is there in case of rounding
errors.)
.columnLeft, .columnRight {
float: left;
width: 45%;
}
.columnLeft {
margin-right: 9.99%;
}
In the links and navigation section, only one rule remains. While links are of no real use
offline, it’s still a good idea to make it apparent what text-based content was originally a
link, in order for people to be able to find said links should they want to, or for reasons of
context. Just ensuring the default underline is in place should do, and that can be done via
the following rule:
a:link, a:visited {
text-decoration: underline;
}
For browsers other than Internet Explorer (although JavaScript workarounds exist for IE
compatibility—e.g., see www.grafx.com.au/dik//printLinkURLs.html), you can also provide
the href values alongside any printed links by using the following code:
a:link:after, a:visited:after {
content: " (" attr(href) ") ";
font-size: 90%;
}
In terms of fonts, keeping things simple makes sense. It’s also worth noting that because
you’re working with print, sizes in points are more useful than sizes in pixels. (Note that
in the body rule, the line-height value was 16pt, not 16px or 1.6em.) Therefore, the
font-size values all reflect that. Note in the p.footer rule that floated content still needs
clearing in the print style sheets.
The final section, images, is not changed much. The images within the columns were
deemed superfluous, and so display has been set to none for .columnLeft img,
.columnRight img. Elsewhere, the margins on the floated image have been set to values in
centimeters (cm) and the border value for #content img is in millimeters (mm), since we’re
working in print. (Values in pixels are permitted, but they tend to be less accurate when
working with print style sheets—for example, if elements have a one-pixel border, they
may not all be even when printed.)
One final thing that’s useful to know is how to create print-only content. In this example,
removing the masthead from the print output has also removed the site’s corporate ID. A
cunning way to bring this back is to create a black-and-white version of the company logo,
and add that as the first item on the web page, within a div that has an id value of
printLogo.
<div id="printLogo">
<img src="assets/we-lay-floors-bw-logo.gif" alt="Web Lay Floors,
å Inc. logo" width="267" height="70" />
</div>
Then, in the main style sheet, create a rule that displays this element offscreen when the
page is loaded in a browser window.
#printLogo {
position: absolute;
left: -1000px;
}
The content will then show up in print, but not online. Note, however, that you should be
mindful to not hide weighty images in this manner, otherwise you’ll compromise download
speeds for anyone using your website in a browser, only for making things slightly better
for those printing the site. A small, optimized GIF should be sufficient.
If there’s other content you want to hide in this manner, you can also create a generic
printOnly class to apply to elements you want hidden in the browser, but visible in print.
The following CSS rule applied to your screen style sheet would be sufficient for doing
this:
.printOnly {
display: none;
}
The reason for not using this generic method with the logo is because at the time of writing,
Opera appears to only print images cached from the normal page view—in other
words, if the image isn’t displayed in the standard browser window, Opera won’t print it.
Therefore, if using the generic printOnly class, be aware that any images hidden won’t
print in Opera, but text will.
An example of how the print style sheet looks is shown in the following screenshot.
 

Note that you can take things further in terms of layout, but it’s best to keep it simple.
Also, ensure that you use the Print Preview functions of your browser test suite to thoroughly
test your print style sheet output and ensure that there are no nasty surprises for
visitors to your site. Ultimately, it’s worth the extra hassle—just amending the fonts and
page margins and removing images and page areas that are irrelevant to the printed version
of the site not only improves your users’ experience, but also makes the site seem
more professional.

Using CSS to wrap text around images

You can use the float and margin properties to enable body copy to wrap around an
image. The method is similar to the pull quote example in the previous chapter, so we
won’t dwell too much on this. Suffice to say that images can be floated left or right, and
margins can be set around edges facing body copy in order to provide some whitespace.
For example, expanding on the previous example, you could add the following rules to
ensure that the surrounding body copy doesn’t hug the image:
.photo {
border-width: 8px 8px 20px 8px;
border-style: solid;
border-color: #ffffff;
float: right;
margin-left: 20px;
margin-bottom: 20px;
}
This results in the following effect shown in the following image.
 
See using-css-to-wrap-around-images.html, using-css-to-wrap-around-images.css,
and sunset.jpg in the chapter 4 folder for a working example of this page.

Choosing formats for images

n order to present images online in the best possible way, it’s essential to choose the best
file format when exporting and saving them. Although the save dialogs in most graphics
editors present a bewildering list of possible formats, the Web typically uses just two: JPEG
and GIF (along with the GIF89, or transparent GIF, variant), although a third, PNG, is finally
gaining popularity, largely due to Internet Explorer 7 finally offering full support for it.

JPEG

The JPEG (Joint Photographic Experts Group) format is used primarily for images that
require smooth color transitions and continuous tones, such as photographs. JPEG supports
millions of colors, and relatively little image detail is lost—at least when compression
settings aren’t too high. This is because the format uses lossy compression, which removes
information that the eye doesn’t need. As the compression level increases, this information
loss becomes increasingly obvious, as shown in the following images. As you can see
from the image on the right, which is much more compressed than the one on the left,
nasty artifacts become increasingly dominant as the compression level increases. At
extreme levels of compression, an image will appear to be composed of linked blocks (see
the following two images, the originals of which are in the chapter 4 folder as tree.jpg
and tree-compressed.jpg).
 

Although it’s tricky to define a cutoff point, it’s safe to say that for photographic work
where it’s important to retain quality and detail, 50 to 60% compression (40 to 50% quality)
is the highest you should go for. Higher compression is sometimes OK in specific circumstances,
such as for very small image thumbnails, but even then, it’s best not to go over
70% compression.
If the download time for an image is unacceptably high, you could always try reducing the
dimensions rather than the quality—a small, detailed image usually looks better than a
large, heavily compressed image. Also, bear in mind that common elements—that is,
images that appear on every page of a website, perhaps as part of the interface—will be
cached and therefore only need to be downloaded once. Because of this, you can get away
with less compression and higher file sizes.
Some applications have the option to save progressive JPEGs. Typically, this format results
in larger file sizes, but it’s useful because it enables your image to download in multiple
passes. This means that a low-resolution version will display rapidly and gradually progress
to the quality you saved it at, allowing viewers to get a look at a simplified version of the
image without having to wait for it to load completely.

GIF

GIF (Graphics Interchange Format) is in many ways the polar opposite of JPEG—it’s lossless,
meaning that there’s no color degradation when images are compressed. However,
the format is restricted to a maximum of 256 colors, thereby rendering it ineffective for
color photographic images. Using GIF for such images tends to produce banding, in which
colors are reduced to the nearest equivalent. A fairly extreme example of this is shown in
the following illustration.
 

GIF is useful for displaying images with large areas of flat color, such as logos, line art, and
type. As I mentioned in the previous chapter, you should generally avoid using graphics for
text on your web pages, but if you do, GIF is the best choice of format.
Although GIF is restricted to 256 colors, it’s worth noting that you don’t have to use the
same 256 colors every time. Most graphics applications provide a number of palette
options, such as perceptual, selective, and Web. The first of those, perceptual, tends to prioritize
colors that the human eye is most sensitive to, thereby providing the best color
integrity. Selective works in a similar fashion, but balances its color choices with web-safe
colors, thereby creating results more likely to be safe across platforms. Web refers to the
216-color web-safe palette discussed earlier. Additionally, you often have the option to
lock colors, which forces your graphics application to use only the colors within the
palette you choose.
Images can also be dithered, which prevents continuous tones from becoming bands of
color. Dithering simulates continuous tones, using the available (restricted) palette. Most
graphics editors allow for three different types of dithering: diffusion, pattern, and noise—
all of which have markedly different effects on an image. Diffusion applies a random pattern
across adjacent pixels, whereas pattern applies a half-tone pattern rather like that
seen in low-quality print publications. Noise works rather like diffusion, but without diffusing
the pattern across adjacent pixels. Following are four examples of the effects of
dithering on an image that began life as a smooth gradient. The first image (1) has no
dither, and the gradient has been turned into a series of solid, vertical stripes. The second
image (2) shows the effects of diffusion dithering; the third (3), pattern; and the fourth (4),
GIF89: The transparent GIF
The GIF89 file format is identical to GIF, with one important exception: you can remove
colors, which provides a very basic means of transparency and enables the background to
show through. Because this is not alpha transparency (a type of transparency that enables
a smooth transition from solid to transparent, allowing for many levels of opacity), it doesn’t
work in the way many graphic designers expect. You cannot, for instance, fade an
image’s background from color to transparent and expect the web page’s background to
show through—instead, GIF89’s transparency is akin to cutting a hole with a pair of scissors:
the background shows through the removed colors only. This is fine when the “hole”
has flat horizontal or vertical edges. But if you try this with irregular shapes—such as in the
following image of the cloud with drop shadow—you’ll end up with ragged edges. In the
example, the idea was to have the cloud casting a shadow onto the gray background.
However, because GIFs can’t deal with alpha transparency, we instead end up with an
unwanted white outline. (One way around this is to export the image with the same background
color as that of the web page, but this is only possible if the web page’s
background is a plain, flat color.)
Because of these restrictions, GIF89s are not used all that much these days. They do cling
on in one area of web design, though: as spacers for stretching table cells, in order to lay
out a page. However, in these enlightened times, that type of technique should be
avoided, since you can lay out precisely spaced pages much more easily using CSS.
PNG
For years, PNG (pronounced ping, and short for Portable Network Graphics) lurked in the
wilderness as a capable yet unloved and unused format for web design. Designed primarily
as a replacement for GIF, the format has plenty to offer, including a far more flexible
palette than GIF and true alpha transparency. Some have mooted PNG as a JPEG replacement,
too, but this isn’t recommended—PNGs tend to be much larger than JPEGs for photographic
images. For imagery with sharp lines, areas of flat color, or where alpha
transparency is required, it is, however, a good choice.

The reason PNG is still less common than GIF or JPEG primarily has to do with Internet
Explorer. Prior to version 7, Microsoft’s browser didn’t offer support for PNG alpha transparency,
instead replacing transparent areas with white or gray. Although a proprietary
workaround exists (see Chapter 9’s “Dealing with Internet Explorer bugs” section), it isn’t
intuitive, and it requires extra code. With post–version 6 releases of Internet Explorer
finally supporting alpha transparency (and Internet Explorer’s share of the market decreasing
somewhat, primarily due to competition from Firefox), it’s worth looking into PNG
when creating layouts.
The three adjacent images highlight the benefit of
PNG over GIF, as shown in a web browser. The first
illustration shows two PNGs on a white background.
The second illustration shows this background replaced
by a grid. Note how the button’s drop shadow is partially
see-through, while the circle’s center is revealed
as being partially transparent, increasing in opacity
toward its edge. The third illustration shows the closest
equivalent when using GIFs—the drop shadow is
surrounded by an ugly cutout, and the circle’s central
area loses its transparency. Upon closer inspection,
the circle is also surrounded by a jagged edge, and the
colors are far less smooth than those of the PNG.
Other image formats
You may have worked on pages in the past and added the odd BMP or TIFF file, or seen
another site do the same. These are not standard formats for the Web, though, and while
they may work fine in some cases, they require additional software in order to render in
some browsers (in many cases, they won’t render at all, or they’ll render inconsistently
across browsers). Furthermore
noise.