Easy Web Graphics

Author Julie Adair King Pages 304 Disk N/A Level Beg/Int Published 01/17/2001 ISBN 9780735611924 ISBN-10 0-7356-1192-0 Price(USD) $19.99 To see this book's discounted price, select a reseller below.	More Information About the Book Table of Contents Sample Chapter Index Related Series About the Author Support: Book & CD Rate this book

Chapter 3: Pixels, Palettes, and Other Pesky Details

• Think Pixels, Not Inches
• Squaring Away Pixels
• Comparing Screen Pixels and Image Pixels
• Designing for the Small Screen
• Choose "Safe" Colors
• Making Color with Light
• Keeping Colors in Bounds
• Preview, Adjust, and Preview Again!

Chapter 3 Pixels, Palettes, and Other Pesky Details

• Working with pixels
• Sizing pictures and other page elements
• Designing your page for no-scroll viewing
• Choosing "safe" colors
• Matching colors from one page to another

Remember when your elementary-school teacher introduced you to finger painting? If you were like me, you were so thrilled with the chance to be messy that you slopped on as much paint as you could, realizing too late that such excess resulted in warped paper and colors that ran together. If you were lucky, your teacher gave you a second sheet of paper and showed you how to adapt your technique to better suit your artistic medium. More likely, though, you didn’t get a chance for a redo, and when your teacher tacked everyone’s pictures to the bulletin board, you were roundly mocked for your rumpled, runny mess.

You can suffer similar humiliation if you don’t understand the properties of the digital canvas you use when creating Web pages. Because of the way monitors and browsers display graphics and text, you need to use some different techniques than when you design printed materials. Otherwise, your audience may see something entirely different than you had in mind.

In this chapter, we’ll cover the two most misunderstood aspects of Web design: working with color and sizing graphics. I’ll warn you up front that this stuff is fairly technical, which is a polite way of saying that you’ll be tempted to wander off to chapters that look like more fun. But trust me, this information is essential if you want visitors to linger and admire your work instead of pointing and snickering, "My first-grader could do better!"

Think Pixels, Not Inches

Squaring Away Pixels

To see pixels in action, take a look at Figure 3-1. In the upper-left image, the pixels are so small that you can’t make out the individual squares, and your brain perceives a seamless image. The blocklike nature of the graphic doesn’t reveal itself until you magnify the view, as I did to create the other two examples in the figure.

Click to view graphic

Figure 3-1 Everything you see on-screen is merely a collection of colored squares, called pixels.

Unfortunately, most people have trouble getting a good fix on how pixels work, which leads to some mistaken approaches to creating Web graphics. So perhaps an analogy will make the situation clear. Imagine drawing a picture by coloring the individual squares on a piece of graph paper. You’re limited to one color per square—you can’t fill half the square with blue and the other half with red, for example. And if you add color to a square, you must fill the square completely; you can’t leave a portion of the square empty and dump color in another area.

Your computer uses this same approach to reproduce your Web pages. But whereas you can make a square lighter or darker by varying the pressure you use when you rub the crayon on paper, the computer simply adjusts the brightness of a pixel.

Comparing Screen Pixels and Image Pixels

It’s important to differentiate between the pixels in your Web graphics and the pixels that your monitor uses to display your Web pages. Each image pixel contains data that describes the color and brightness of that particular area of the picture. When you load a Web page that contains an image, the computer reads the image data and then adjusts the screen pixels as necessary to render the picture on-screen.

At this point, you’re no doubt saying to yourself, "Gad, why is she dragging me through this technical swamp? I don’t care about this behind-the-scenes junk; I just want to be creative!" To which I’m forced to reply, "Sorry, but you really have to care, at least a little, if you want to create good-looking Web graphics." Understanding screen pixels and image pixels is key to sizing your page elements correctly and avoiding jaggedy, blurry pictures, as I’ll explain in the next two sections.

Measuring page elements in pixels

All monitors can generate a finite number of screen pixels. Typically, the user can choose from several settings, each of which results in a different number of horizontal and vertical pixels. For example, I have a 19-inch monitor that offers a choice of five settings ranging from 640 by 480 pixels to 1600 by 1200 pixels. (The horizontal pixel count is always listed first.) My laptop computer, however, is limited to just two display options: 640 × 480 and 800 × 600. Naturally, as you raise the number of pixels, the pixels get smaller because you’re cramming more pixels into the same space.

Regardless of the screen resolution or monitor size, a Web browser always uses one screen pixel to represent one image pixel. If you create a picture that’s 400 pixels wide and 300 pixels tall, for example, the graphic consumes 400 horizontal screen pixels and 300 vertical screen pixels. If the user raises the screen resolution, the pixels—and your graphic—just appear smaller. Conversely, when the screen resolution goes down, pixels get bigger, which means that your graphic gets bigger.

Figures 3-2 and 3-3 illustrate this point. In Figure 3-2, you see a Web page displayed on a monitor running at a screen resolution of 640 × 480. The second figure shows the same page on a monitor running at a resolution of 800 × 600. In Figure 3-3, the screen pixels are smaller, which means that more of the page can be displayed in the browser window.

Click to view graphic

Figure 3-2 When displayed at the 640 × 480 screen resolution, this Web page doesn’t fit within the browser window.

Click to view graphic

Figure 3-3 Changing the screen resolution to 800 × 600 reduces pixel size so that more of the page is visible.

Resampling vs. resizing graphics

While you’re building your site in Microsoft FrontPage 2000, you can enlarge a selected graphic by dragging a corner handle, as I’m doing to the larger bird image in Figure 3-4. When you do this, you’re not changing the number of pixels in the image but simply magnifying the image, which destroys that one-to-one relationship between image and screen pixels. The image pixels get bigger, which means the browser uses more screen pixels to reproduce each image pixel. If you enlarge the graphic significantly, the individual image pixels become noticeable, and the result is a blocky-looking—read "ugly"—picture. Compare the smaller bird image with its larger neighbor to get a better idea of the kind of quality loss you can expect.

Click to view graphic

Figure 3-4 Enlarging an image in FrontPage increases the size of the image pixels; the number of pixels remains constant unless you resample the picture.

After stretching or shrinking an image in FrontPage, you can choose to resample the image by clicking the Resample button on the Pictures toolbar. (See Figure 3-5.) Resampling means to add or delete image pixels. FrontPage adjusts the pixel count as needed to match the new screen area that the picture occupies. For example, if you enlarge a 100-by-100-pixel image so that it occupies a 200-pixel square area of the screen, the software adds 100 pixels horizontally and 100 pixels vertically. Now the one-to-one screen pixel to image pixel ratio is restored. Unfortunately, your image probably looks even worse than it did before you resampled. The program has to guess at the color and brightness of the pixels it adds, and even for the most sophisticated software, that’s a difficult proposition. Your images usually lose detail and become blurry. Figure 3-5 shows the enlarged image from Figure 3-4 after I resampled it in FrontPage.

Click to view graphic

Figure 3-5 Resampling the picture in FrontPage does even more damage.

Adding pixels not only degrades image quality but also adds to the size of the picture file because each pixel brings with it a certain amount of extra data. Deleting pixels usually does less visible damage and has the added benefit of reducing file size, which translates to shorter download times. But for the best results, don’t enlarge or reduce your pictures in FrontPage. Instead, do this work in your image editing program, which is probably better equipped to handle the resampling work than FrontPage.

Sizing graphics by percentage

Some Web design programs enable you to specify the size of graphics either in pixels or as a percentage of the visible browser window. For example, you can set a graphic to occupy 10 percent of the horizontal window space and 15 percent of the vertical space. When a user loads your page, the browser automatically adjusts the graphic as necessary so that it occupies the specified percentage of the window.

This option has its pros and cons. On the upside, you don’t wind up with a graphic that’s too big when displayed on a monitor running at a low screen resolution or too small on a monitor set to a high resolution. No matter what the screen resolution, the graphic occupies the same percentage of the browser window.

The downside is that if the browser has to enlarge the graphic substantially, the picture quality can suffer, as Figures 3-4 and 3-5 illustrate. Or if the browser dramatically reduces the graphic, users might not be able to see the details in the graphic clearly. For these reasons, I recommend that you stick with pixels when setting the size of important graphics. That’s the only way to retain control over the quality of the image.

Designing for the Small Screen

If you make your Web pages too wide or too long, you create a similarly cramped environment for visitors to your Web site. They have to keep scrolling up and down, back and forth, to find out what you’re selling or saying. All that scrolling takes a toll on the user’s patience, not to mention the strain on the finger that has to hold down the mouse button or flick the scrolling wheel.

So what’s the perfect page dimension? The answer depends on whom you ask—the grandfather who sets his monitor to VGA resolution (640 × 480 pixels), the businesswoman with a laptop running at SVGA resolution (800 × 600), or the graphic designer who has a screen as big as a city block and works at a screen resolution of 1600 × 1200. (I believe that’s called big-as-a-city-block resolution.) The page area that each user can display without scrolling is different, so each user will have different ideas about the dimensions of the perfect page.

You can’t please everyone, so your best option is to design with the lowest common denominator in mind. Ideally, that means placing the vital elements of a page within the first 640 × 480 pixels of the page—in other words, the area that the user sees first when your page loads. Some people refer to this area as "above the fold," which is the lingo that newspaper designers use to refer to the top half of a newspaper page. Most people read the area above the fold first, so that’s considered prime page space. People passing by a newspaper vending box see only the area above the fold on the front page and may make a buying decision based on that content. Similarly, people logging in to your site may decide to click away if what they see in that first browser window doesn’t intrigue them.

Practically speaking, though, 640 × 480 is a very limiting size. And if you ask around, you’ll likely find that most people these days surf the Web using a screen resolution of at least 800 × 600, if not higher. (Many people won’t even know they can change the screen resolution to a lower setting than the factory default.)

Here’s my advice: on your home page, try to keep important links and information in that above-the-fold zone, assuming an 800 × 600 screen resolution. If you can whittle it down for a 640 × 480 screen, so much the better. If you do extend your page beyond the viewable area, as most people do, duplicate vital links so that they’re always within easy reach.

Remember too that the browser interface itself eats up part of the available screen area—the exact number of pixels you lose to the interface varies depending on the browser and which browser tools the user displays. In Microsoft Internet Explorer 4 and later, you have less screen space at your disposal when the History bar is displayed, as in Figure 3–6, than if it’s hidden.

Click to view graphic

Figure 3-6 When sizing your pages, don’t forget that the browser interface consumes some of the available screen area.

Of course, if you have a content-heavy site, limiting yourself to such a small design area means that you have to spread information over many pages. And having to navigate through a long series of linked pages to view related content can be just as irritating as being forced to scroll. So you just have to try to strike a balance that enables people to get everything they want from your site with as little effort as possible.

Debunking the Resolution Myth

If you explore some Web design sources or lurk in online discussion groups devoted to the subject, you’ll no doubt be told that you should size your image in inches and then set the image resolution to 72 pixels per inch or 96 pixels per inch. Although this method is popular, it’s not the best approach.

Pixels per inch—ppi, for short—applies only when you print pictures. Then the number of pixels per inch determines the print quality. The smaller the print size, the more pixels per inch, and the better the image looks on paper. You establish the resolution in your image editing program before sending the picture to the printer.

For screen display, all that matters is the number of horizontal and vertical pixels in the graphic. A computer screen pays no attention to the resolution value that you set in your image editor. It simply displays as many pixels as the user’s screen resolution setting allows, as the earlier section "Measuring page elements in pixels" explains.

So where did the 72 ppi/96 ppi thing come from? Well, back in the early days of computers, most PC monitors left the factory set to a screen resolution that resulted in about 96 screen pixels per linear inch of viewable screen area. The default Macintosh screen resolution gave you approximately 72 pixels per inch. So if you set your image size to, say, 2 inches by 2 inches and set the image resolution to 96 ppi, you wound up with exactly the number of pixels you needed to fill 4 square inches of a PC screen; if you set the resolution to 72 ppi, you got enough pixels to consume 4 square inches of a Macintosh screen. But this didn’t happen because the monitor paid attention to the image resolution—it still simply matched screen pixels to image pixels.

Today, the 72/96-ppi guideline is outdated because we have a much wider range of monitor sizes and therefore a broader range of default screen resolutions. For example, a 12-inch laptop screen typically leaves the factory set to 800 × 600 resolution, which indeed gives you an effective screen resolution of about 72 ppi. But a 19-inch desktop monitor also heads into the world set to 800 × 600, and that gives you a screen resolution of about 45 pixels per inch. (These are rough values based on actual screen area, which is slightly less than the actual monitor size.)

On a practical note, FrontPage and other Web design programs don’t allow you to size elements in terms of pixels per inch—only in actual pixels or percentage of the total window area. So if you’re building a table, for example, and want to create a graphic that fits perfectly inside a table cell, you won’t find any measurement that gives you the cell size in inches. Cell dimensions are measured in pixels across by pixels down, and you simply set the pixel dimensions of your graphic to match.

To sum up: When people tell you to make your Web graphics 72 or 96 ppi, nod politely, but ignore them. Better yet, tell ‘em what I just told you and make their lives a little easier.

Choose "Safe" Colors

In the next few sections, I’ll explain how color works on the Web and how you can make sure that what you see is what your users get.

Making Color with Light

The amount of red, green, or blue light in a color is measured in values from 0 to 255, with 255 indicating full-intensity light and 0 indicating no light. So if the red, green, and blue values are each set to 0, you wind up with black—the absence of light, if you will. And if you crank up the light box and set all three values to 255, you get white, as you would if you aimed red, green, and blue spotlights at the same target. If you mix equal amounts of red, green, and blue light at any other value, you get a shade of gray.

Luckily for the math-haters in the audience (I consider myself your humble leader) you don’t have to memorize a bunch of R, G, and B values to assign colors in today’s graphics programs. You just click a color in the program’s color picker, and the software takes it from there. When you’re choosing colors for the Web, however, you may need to specify colors using hexadecimal values, which are based on RGB values, which is the whole reason I even bring up the subject. For details, see the upcoming section "Specifying colors with hexadecimal values."

Keeping Colors in Bounds

First, let’s consider the hardware side of the equation. Most systems enable you to set the monitor to display 16 colors, 256 colors, 65,536 colors, or 16.7 million colors. The more colors, the better things look on-screen. Figure 3-7 shows the same graphic captured at the three of these color settings. Although the image doesn’t suffer much when trimmed from 16.7 million to 65,536 colors, backing off all the way to 256 colors results in a very mottled image.

Click to view graphic

Figure 3-7 Here you see the same graphic as it appears when displayed using 16.7 million colors (top), 65,536 colors (middle), and 256 colors (bottom).

Given the impact on the screen display, you may be wondering why anyone would opt for fewer colors. In a word, speed. In another, memory. The computer needs more time and system memory for each additional color. So people working with less powerful systems can improve their computers’ performance by working at a lower color depth.

The question for you, then, is how to create graphics that will look great—or at least, won’t look too awful—no matter what the bit depth of the user’s system. For the answer, keep reading.

The dithering dilemma

If you display a graphic that contains more colors than the monitor’s chosen bit depth allows, the computer dithers the extra colors. That just means that it blends two available colors to create colors beyond the 256-color limit. Sometimes dithering works out fine, and other times, you get the kind of speckled appearance that you see in the bottom example in Figure 3-7.

How does the computer decide which 256 colors to keep and which to dither? On the Web, the browser software makes the call. If your page contains more colors than the user’s selected bit depth can display, the browser consults an internal color palette, which we geeks refer to as a CLUT (color look-up table). Then it dithers any colors that aren’t included in that palette.

Just to make things a little more difficult, the basic 256-color system palette varies depending on the hardware platform. The top two rows in Figure 3-8 show the Microsoft Windows system palette and the Apple Macintosh system palette, for example. Because the palettes don’t contain exactly the same colors, an image may look one way when viewed on a Windows-based system and another when displayed on a Macintosh. It’s enough to make you give up color altogether and stick to black-and-white pages!

If you’re working with photographs, you really can’t do much about this problem except hope that most of the people who view your site will be seeing it at a higher color depth. But for other page elements—text, borders, simple buttons, and so on—you can avoid the dithering uglies by choosing colors contained in a so-called Web-safe palette. This palette contains 216 colors that are included in all the major system and browser palettes, which means that a color should look the same on every computer. The bottom row in Figure 3-8 shows the Web-safe palette.

Click to view graphic

Figure 3-8 You get a different base palette of colors in Windows (top) than on the Macintosh operating system (middle). Staying with the 216-color Web-safe palette (bottom) improves the chances that site visitors will see your graphics as you design them.

The next section explains how you can select a Web-safe color in FrontPage 2000 and Microsoft PhotoDraw 2000. But before you move on, let me add a word of caution. Don’t expect perfect color consistency even from a Web-safe palette. The room lighting in which people view your site—as well as their eyes’ own sense of color—can create variations in perceived color. So if color accuracy is a vital part of your business—for example, you’re an interior designer selling slipcovers and draperies—you should add a disclaimer that explains that colors of actual products may not match those on-screen exactly. To make your customers even happier, offer to send actual samples or color swatches upon request.

Working with a Web-safe color palette

When you’re building your Web pages in FrontPage or some other design program, stick with Web-safe colors for text and simple page elements, such as borders and rules. Ditto for graphics that you create in PhotoDraw or any other program. Sure, you’re more limited in your color choices, but you don’t have to worry about a cool graphic getting the dithering measles either.

Some programs enable you to customize your color picker (the dialog box or panel where you choose your colors). In PhotoDraw, for example, you can tell the program that you want to see Web-safe colors only in the color picker. The steps on the next page show you how.

Loading a Web-safe palette in PhotoDraw

1. The key to loading a Web-safe palette is the PhotoDraw color picker, which appears in the workpane whenever you’re formatting an object using the solid-color Fill or Edge options or when you’re working with a tool that applies color. In Figure 3-9, I selected a text object and then clicked Fill in the Text workpane to display the color picker.


Click to view graphic

2. Figure 3-9 To specify a Web-safe palette as the active palette, choose More Colors from the color picker menu.
3. In the workpane, click the arrow button at the end of the row of color swatches to display the color picker menu, shown in the figure.
4. Choose More Colors to display the More Colors dialog box, which you can see in Figure 3-10.
5. Choose Web-Solid Colors from the Color Palette drop-down list.
6. Click OK.
7. Click the arrow button again, and point to Active Palette. PhotoDraw displays color swatches for the entire Web-safe palette. You can simply click a color to use it.

Figure 3-10 Choose Web-Solid Colors for the safest collection of colors.

If you’re working in FrontPage, Microsoft Word, or some other software that doesn’t allow you to load a Web-specific palette, you can specify colors in terms of hexadecimal values, as explained in the next section.

Specifying colors with hexadecimal values

As I mentioned a few sections ago, the color tags used in the HTML code that generates your Web page are based on RGB values. The color tags are designed around the hexadecimal number system, which I won’t even try to explain because it makes me nauseous just thinking about it and doesn’t matter anyway. All you need to know is that a color tag contains three pairs of letter or number combinations. The first pair indicates the amount of red light in the color, the second pair represents the amount of green light, and the third pair specifies the amount of blue light. Figure 3-11 highlights four color tags on a page of HTML code.

If your Web design or graphics software enables you to specify colors using hexadecimal values, you can ensure that your page contains only the 216 Web-safe colors by using only certain pairs of characters. These character pairs are: 00, 33, 66, 99, CC, and FF.

Click to view graphic

Figure 3-11 In HTML code, colors are specified using a six-character hexadecimal value.

The following steps show how to choose Web-safe colors using hexadecimal values in FrontPage.

Specifying Web-safe colors in FrontPage

1. From any color menu, choose More Colors. For example, to select a text color, click the down arrow to the right of the Font Color button on the Formatting toolbar, and then choose More Colors, as shown in Figure 3–12. Or choose Font from the Format menu to display the Font dialog box and then choose More Colors from the Color drop-down list.



Figure 3-12 Choose More Colors from the Font Color menu to display the More Colors dialog box and select a color by using hexadecimal values.

Either way, you get the More Colors dialog box, shown in Figure 3–13. The dialog box contains 127 color swatches. Most of these colors are Web-safe, but some are outside the 216-color palette.



Figure 3-13 If you click a color swatch, check the hexadecimal value to see whether it uses any unsafe character pairs.

2. Enter the hexadecimal values for the color you want to use in the Value box. You also can click a color swatch and then check the value to see whether it uses any character pairs other than the six I mentioned earlier. If not, the color’s safe.
3. Click OK to select the color.

After you select a color, it appears in the Document’s Colors section of the various FrontPage color menus. You can then just click the swatch in the menu to apply the same color to another page element.

Calculating Web-safe RGB values

Moving right along from nerdy to incredibly nerdy, you can also specify Web-safe colors in terms of RGB values, an option that comes in handy if your software doesn’t let you choose colors by hexadecimal values. Remember, hexadecimal values are based on the amount of red, green, and blue in the color. Almost every graphics program lets you pick colors by entering R, G, and B values. So all you need to know is how the six safe hexadecimal pairs translate to RGB values. Table 3-1 provides the secret decoder ring. As you can see, as long as you set the R, G, and B values to 0, 51, 102, 153, 204, or 255, you’re Web-safe.

Table 3-1 Web-safe color values

Hexadecimal value	RGB value
00	0
33	51
66	102
99	153
CC	204
FF	255

You can take advantage of this option in FrontPage, Word, and PhotoDraw. In FrontPage, click Custom in the More Colors dialog box, which opens the Windows color picker, shown in Figure 3-14. (If you don’t see the right half of the window as shown in the figure, click Define Custom Colors to display it.) Enter the RGB values in the Red, Green, and Blue boxes. In the figure, I selected a Web-safe teal by setting the Green and Blue values to 153 and leaving the Red value at 0. In hexadecimal numbers, the value for this color is 009999.

Figure 3-14 You can specify Web-safe colors in the Windows color picker by limiting the Red, Green, and Blue values to any of six numbers: 0, 51, 102, 153, 204, 255.

In PhotoDraw, you access the RGB options by clicking the True Color tab in the More Colors dialog box, shown back in Figure 3-10. In Word 2000, click the Color tab in the More Colors dialog box instead.

Matching an existing color

Suppose you want to match the color of some text on a page to color in an existing graphic. In many programs, including FrontPage and PhotoDraw, you can click the graphic with an eyedropper tool to "lift" the color and make it the active color. The eyedropper lives inside the More Colors dialog box in FrontPage; in PhotoDraw, the eyedropper appears with the color picker in the workpane. (See Figure 3-9.)

Another option is to match colors using hexadecimal values. You just look at the HTML code (you can do this in FrontPage by switching to HTML view), and jot down the hexadecimal number that’s assigned in the color attribute. Then just enter that same value—or its RGB equivalent—when you select colors in your graphics program.

This technique is a great way to ensure color consistency when several people are creating pages for the same Web site. Just give everyone a list of the hexadecimal or RGB values for the colors you want to use for different elements on the page.

Preview, Adjust, and Preview Again!

Also, remember that some browsers enable users to override the colors in your pages and use their own colors or the browser’s default colors. Of course, you can’t check for every possible combination of user-selected colors, but you should at least make sure that things look okay at the browser’s defaults. Also, preview your page with the background color set to plain white because that’s a popular option among people who customize their browser displays.

Top of Page

Last Updated: Saturday, July 7, 2001