Web-Safe Color Palette Discussion

In: Articles

By Makiko Itoh

By Nick Finck

Published on May 17, 2001

Back in September 2000, Hadley Stern and David Lehn of Razorfish wrote an article for WebMonkey provocatively titled “Death of the Web-Safe Color Palette.” This has caused more than a few discussions and confusion in the web developer community since.

To get an idea of what some battle-seasoned web designers and developers thought when this article first came out, the following is a sampling of the conversation that took place in some interesting email conversations. The exchange is presented here to illustrate the frustrations and insights that came through. Above all, it’s a small snapshot of the type of exchange of ideas and information that stimulate our brains and enrich our lives as web creators.

The participants in the conversation are as follows, in alphabetical order:

Wanda Cummings, Creative Solutions
Nick Finck, Editor in Chief of Digital Web
Melissa Gruenhagen, Web Designer’s Forum
Makiko Itoh, PRODOK Engineering
David Lehn of Razorfish, co-author of the article
Bob Stein, VisiBone
Hadley Stern of Razorfish, co-author of the article
Jeffrey Zeldman, A List Apart

So what were some of the conclusions (if not consensus) reached?

• The 16-bit color space is a lost cause because it is physically impossible to calculate colors accurately.
• Windows has a lot of display issues which web designers must contend with, one of which is that 16-bit “true color” is the default setting on new PCs.
• Some errors are due to incorrect color shifting by programs such as Adobe Photoshop 5.5 (the most current version at the time this conversation took place.) Therefore, it’s a bad idea to create portions of an area of the page are supposed to be continuous in color with different programs, (such as creating one table slice in Photoshop, and another just by specifying a table background color in hex code.)
• The web-safe palette is still a viable convention to follow, especially for major areas of flat color, and it’s not necessarily a good idea to simply say “aw heck with it” and throw it out….
• …the VisiBone web-safe color-wheel tools (we still like those cool mouse pads) and other web-safe color palette selection aids.
• It’s harder and harder to educate clients with half-baked ideas, but we struggle on nevertheless.
• We will soon be designing for refrigerator displays. Or something close. So color display problems aren’t likely to go away fast.
• Separation of content and presentation is good, and will help when we have to start designing for the refrigerator (or gas pump).
• We are confused yet cheerful.

For the gory details, read on…

---

September 8, 2000
From Nick Finck
Subject: Is the Web-safe palette ‘really’ Web-safe?

Some interesting issues have cropped up today with web-safe colors. Is the 216 Web-safe color palette ‘really’ Web-safe? A enlightening article at Webmonkey by David Lehn and Hadley Stern show us the “death of the Web-safe color palette“?

Interestingly enough, we ran into a similar dilemma on one of our MSN projects when a Microsoft usability test engineer reported that a graphic showed up blue instead of a off-yellow (which was web-safe, or so we thought).

Proof? Try out these two test pages at different bit-depths; the web safe test page and the Really-safe color palette.

Special thanks goes to Nick Johnson of White Horse Interactive for bringing this to our attention. Extra special thanks to David Lehn and Hadley Stern and WebMonkey for bringing it to the attention of the public.

---

From: Bob Stein, VisiBone

Nick, thanks very much for the heads up on the article. Of course, the death of the web-safe palette making my entire product line fundamentally moot has no bearing on my technical perspective on the matter. (Excuse me, I have to write fast. I have barricaded the door with 16,777,216 hexagon mouse pads, and the SWAT team has just deployed.)

It’s a great article, and sure helps pursue and attack the color beast, which although it’s tied up only seems to get meaner.

I have heard of this problem with GIF color and <td bgcolor> having the same numbers but looking different. But they didn’t touch on why as far as I can see. Did I miss that? Perhaps it’s not helpful to know, but it strikes me as strange that a computer with limited color choices would choose one compromise for a color in a GIF and choose another for the same color in a table background. Come to think of it, perhaps vastly different rendering software is at work (i.e. different developers using different brands of pizza). Anyway, it seems *that* is the main sub-beast the article is chasing, as opposed to the mathematical wackiness of 8/15/16/24 bit color depth. Why aren’t colors compromised consistently?

I suspect the reason the Reallysafe Palette is biased toward green is because green is so bright (to human eyes) it washes out subtle distinctions in levels of the other phosphors. (That is to say, cheerily, many of the 22 colors are unsafe too.) It jibes eerily with this test I did a while back, where the greens seem more consistent than other colors (consistently in-your-face, full-contact, bright-beyond-aesthetic-usefulness green, that is):

http://www.visibone.com/colorlab/colortest.html

P.S. Since the article ends with an honorable call for help, I’d like to offer the meager, humble contribution of free sample mouse pads to the authors, David Lehn and Hadley Stern. But I have to go, I see the SWAT guys are stuffing them into their flak jackets…

---

From: Hadley Stern

Bob, thank you very much for your response. I am sure I speak for David as well when I say the last thing we had in mind was making your mouse pads “fundamentally moot”. Anyway, we didn’t do it, the web did! As far as why the browser shifts the hex value and the gif differently it appears to be a flaw in the OS and/or the browser application. Our best guess is it is a flaw in the browser and in the case of Win IE 4/5 running at 8-bit screwing up 4 of the “web safe” colors, this indeed appears to be the case. At 16 bit things get, as I am sure you can tell from the article, a little more confusing. Since some browsers deal with things fine (IE 5 on the mac was the only browser on any platform to have no problems with any of this nonsense) then it appears to be the browsers fault. Microsoft, as we said in the article was responsive. Netscape, unfortunately not so. Either way, particularly when it comes to the 16bit environment is hard to know how much they can do!

Not to go on and on but while the mathematics of the os and browsers is important unfortunately 16-bit is its own beast. You cannot select a 16 bit color in photoshop! Why? Because there is no such thing. 16 bit is mathematically calculated by the video card and os and interprets the 24 bit (or 8 bit) colors. Hence, its a pain in the butt and not mathematically clean.

Anyhow, hope that helps and the more discussion the better.

hadley stern

P.S. maybe you could start selling your mouse pads with the pallette crossed-out. I’m not being ficticious, its going to be a nightmare to re-educate people on color on the web.

---

From: Jeffrey Zeldman

one of the best articles webmonkey has ever run, imo.

nor does it, imo, make the VisiBone mouse pad (beneath my mouse as i write this) moot.

the careful research behind this article confirms what a lot of us already know:

16-bit color is #$%, and we cannot control the visual experience for people who use it.

i’ve said for a while, when it comes to the web, 8-bit color users are somewhat better off than their seemingly more fortunate 16-bit color-using friends.

using the web-safe color palette helps the low-end folks. does nothing to solve the unsolvable problems of 16-bit color users, but does them no harm.

three years ago, who would have thought that a majority of web users would have 16-bit color?

in another year or two, i suspect they’ll have 24-bit/32-bit color. cards keep getting cheaper, and the PC market is a parity market. which means vendors must constantly throw in bonuses and extras to differentiate their otherwise identical offerings.

once dell starts throwing in 24-bit color on a $599 PC, their competitors will do likewise.

maybe by that point in time, the web safe color issue will be as moot as the web standards issue.

meanwhile, i’m hanging on to my VisiBone mouse pad. and sticking to the web-safe color palette for all my main color areas. 🙂

---

From: David Lehn

thanks, jeffrey.

one thing i’m concerned about, though, is that the rise of small devices, such as color palms, suggests that less-than-true-color displays won’t go away too quickly. and making separate designs for the different user agents will be a huge pain.

---

From: Jeffrey Zeldman

David Lehn wrote:
one thing i’m concerned about, though, is that the rise of small devices, such as color palms, suggests that less-than-true-color displays won’t go away too quickly. and making separate designs for the different user agents will be a huge pain.

agreed. unless we put most of our color info into the style sheet.

when we can really do layouts in CSS instead of tables (when Navigator 4 is a bitter memory), we can put all our color info into those layouts, serving one style sheet for palm pilots, and another for conventional desktop browsers.

so hopefully it won’t be nearly as bad as we imagine.

---

From: Jeffrey Zeldman

David Lehn wrote:
there’s also servers-side XSL transformations, which, i think, holds a lot of power for us. however, xsl and css only handle code color, not GIFs. so you’d still need separate sets of all your gifs to handle the different user agents/environments.

oh dear god.

okay, at this point i’m just going to focus on today.

in fact, i’m just going to focus on getting through the next hour.

😉

you’re right. by the time we’re rid of one nightmare, we’ll have others to contend with.

jeffrey

---

From: David Lehn

there’s also servers-side xsl transformations, which, i think, holds a lot of power for us. however, xsl and css only handle code color, not gifs. so you’d still need separate sets of all your gifs to handle the different user agents/environments.

??

---

From: Nick Finck

Jeffrey Zeldman wrote:
you’re right. by the time we’re rid of one nightmare, we’ll have others to contend with.

I hate to break it to everyone, but we are going to have to “design for the gas-pump” …ya, sad isn’t it?… my feeling is that designers (as in true designers as we know them) will become less valuable and the demand will shift for “information designers” …the type of people who can find ways to code a single page and have the information conveyed properly regardless of what client your using (yes, you can now browse the web on your local gas-pump thanks to BP, or on your washing machine thanks to Whirlpool).

Reminds me of the scene in one of the Back To The Future movies.. you know the one.. where there is a fax in every room… heck, even the toilet paper worked as fax paper.. all, of course, printing in large words “You’re Fired!” Convergence killed the cat.

– Nick

---

From: Makiko Itoh

Nick Finck wrote:
I hate to break it to everyone, but we are going to have to “design for the gas-pump” …ya, sad isn’t it?… my feeling is that designers (as in true designers as we know them) will become less valuable and the demand will shift for “information designers”

Well, that’s not a bad thing really. I mean..the primary advantage of CSS+XML for example that I can see, is the ability to totally separate *content* from *presentation*. Right now, when we have to splice together pages using tables and “shims” (those infamous clear GIFS, which are like the wooden shims you use to level out gimpy window frames and stuff) it’s kind of hard to do….but once (heh) all browsers actually either support CSS properly, or ignore it properly, and once(heh) XML support also becomes universal…then there will be a nice divergence, rather than convergence; designers who have to do the presentation, will be able to concentrate on the visual, and the – whatever job title fits here – can concentrate on the content and the structure. Well..I’m an Idealist.

In any new pages/sites we’ve done in the last few months or so, we’ve tried to quietly follow this way of thinking, of separating content from structure/visual presentation…even if we do have to still use tables for layout and presentation, at least the main content stays font-tag free and formatted by CSS. Ideally, presentation and navigation gets assembled on the server side…but that’s another subject.

I regard Flash, and PDF (don’t forget PDF!) as alternative ways of presenting information though…not something necessarily to supplant the *ML way, but to supplement it. Each has its advantages and disadvantages.

I realize this is getting off-topic…that was a great article though, and I’ll try to suppress my natural instinct to say something derogatory about Windows and color in general :)) (um, calibration, anyone?) Also Bob, I’m another fan too. (the way I use the VisiBone palettes is as a design aid as much as for picking web-safe colors; love that color wheel!)

---

From: Melissa Gruenhagen

Awe heck, let’s just design everything in .JPG files, including the background.

---

From: Nick Finck

M Gruenhagen wrote:
Awe heck, let’s just design everything in .jpg files, including the background.

Have you ever seen a JPG on a system set for 16 or 256 colors? GAH!!!! 😛

– Nick

---

From: David Lehn

aw, this whole thing is such a mess.

personally, i’m inclined toward 2 extremes: w3.org style on the one hand, and full on, indulgent, all-out design on the other. neither seems too gratifying, though.

but it may just require a different style of design, not different colors. the way we use flat colors, the way we create layouts, etc–avoiding situations of gif and code next to each other.

i do believe, though, that the worst thing for designers is improving technology. the faster and farther it improves, the more standards fall by the wayside.

then again, there’s long been a strain of web designers out there who believe the style needs to change to accept its unpredictable nature (as with, say, tables etc that dont’ have fixed widths, to accommodate different screen resolutions). maybe we need to think along those lines more seriously.

---

From: Jeffrey Zeldman

David Lehn wrote:
personally, i’m inclined toward 2 extremes: w3.org style on the one hand, and full on, indulgent, all-out design on the other. neither seems too gratifying, though.

me too. but i find myself in the middle a lot. which can result in good work, though nobody will be knocked out by it visually.

you get more credit when you force the web to be like print – or like a CD-ROM.

i do believe, though, that the worst thing for designers is improving technology. the faster and farther it improves, the more standards fall by the wayside.

if you’re talking about jerry-rigging three languages to do more with a database, i agree with you. if you mean you can now do more stuff in flash, i agree with you.

both those technological improvements make it harder, in some ways, to increase the momentum toward XML or SVG – or to demand perfect CSS compliance (since we can use gifs, JPEGs, or flash when we want type to look right).

but support for some standards (HTML, CSS, javascript) /is/ getting better and i think the momentum where browsers are concerned is toward more and more standards compliance. it’s just not happening real fast.

then again, there’s long been a strain of web designers out there who believe the style needs to change to accept its unpredictable nature (as with, say, tables etc that dont’ have fixed widths, to accommodate different screen resolutions). maybe we need to think along those lines more seriously.

i always think along those lines. and i’m usually satisfied with the results.

it’s hard to sell clients on liquid design and adaptable type. most clients are used to exercising fascistic control over every element of their print work. telling them “i CAN give you that, but it would be BETTER not to” takes good selling and clients who are willing to listen.

and once you start educating clients, they become dangerous in a different way. 🙂

---

From: David Lehn

on the issue of standards compliance…i haven’t had much of a chance to look at IE5.5 yet, but “behaviors,” however useful, are not compliant. and i’ve heard stories of other features–in fact, i understand that IE5.5 represents a reversion to the days around the time of the v4 releases, when the two companies initiated the great divergence. in a way, i hope NS6 never releases. i hope Mozilla just goes away. then we have our standard: microsoft. it makes the w3c (at least regarding browser technologies) irrelevant, yes. but at least there’d be one, true standard at that point.

i find that increasingly clients have just the wrong amount of knowledge. they read Alertbox but don’t understand the underlying issues; they know not everyone has plug-ins, so they insist on DHTML instead of flash, even though that often seems an illogical choice to me (if your browser didn’t come with the plug-in, it almost certainly can’t handle dhtml). i guess i’m not optimistic that they can be shown that the web safe palette is not necessarily the way to go, etc etc.

---

From: Jeffrey Zeldman

on the issue of standards compliance…i haven’t had much of a chance to look at IE5.5 yet, but “behaviors,” however useful, are not compliant.

i obviously agree: http://www.webstandards.org/wfw/ieah.html

but IE5/mac is extremely css and HTML4 compliant, and i have to believe IE6/win will be too.

in a way, i hope ns6 never releases. i hope mozilla just goes away. then we have our standard: microsoft. it makes the w3c (at least regarding browser technologies) irrelevant, yes. but at least there’d be one, true standard at that point.

ouch.

i find that increasingly clients have just the wrong amount of knowledge.

agreed.

they read alertbox but don’t understand the underlying issues;

yes.

they know not everyone has plug-ins, so they insist on dhtml instead of flash, even though that often seems an illogical choice to me (if your browser didn’t come with the plug-in, it almost certainly can’t handle dhtml).

nailed.

actually i remember when clients first started reading david siegel’s book. suddenly some of them thought they “understood” and knew as much as we did.

“shouldn’t we have an entrance tunnel?” was pretty scary and it was the 1996 version of “what about a flash intro?”

i guess i’m not optimistic that they can be shown that the web safe palette is not necessarily the way to go, etc etc.

well, i don’t raise these issues with clients unless they give me a logo that won’t work. then i change it and explain why, using as few words as possible.

your article is the best i’ve seen on the subject. but the conclusion i draw is what i thought before: 16-bit users are screwed, and the web-safe palette STILL gives us an anchor that works in 8-bit and 24/32-bit. so we keep using it.

two minor things about the article:

1. several of the example links aren’t working, at least on my system. it appears that they’re supposed to be javascript popups. but they don’t pop up. there’s no javascript error alert; nothing happens when you click the link. for instance, this link:
http://hotwired.lycos.com/webmonkey/00/37/index2a_page5.html?tw=design#

on this page:
http://hotwired.lycos.com/webmonkey/00/37/index2a_page5.html?tw=design

(may be a browser bug of course.)

2. STRATEGY 6 — Use transparent backgrounds.

… works until you use a:hover on your links. if your images are links, and your hover involves a color change, that foreground color fills the background of the table cell (or div) and the illusion is shattered, as a new color leaps up to fill the transparent areas (and reveal the outline of the gif image and / or the table cell in which it sits).

for example, see [non-disclosed web site]

click on the logo at the top.

the hover color fills in, resulting in some weirdly funky ugliness.

i used to use transparency at http://www.alistapart.com/ to avoid this subtle color mismatch (in 16 bits) between my content background color and the background color of my GIF. but once i saw the hideous hover effect, i went back to using solid images (no transparency).

the backgrounds match in 8-bit and 24-bit color.

they don’t match in 16 bit color.

the large 16 bit audience sees the edges of the gif as a subtly mismatched color (destroying the illusion for them). but if you use transparency, the illusion is ruined for the ENTIRE audience (unless you avoid using the hover pseudo-property to change colors on active links).

whew.

lots to think about.

thanks again to you and hadley for this extraordinary piece of work.

---

From: Bob Stein

Hadley,

I’d certainly call it a flaw in the browser / OS. Of all your solutions, by the way, I like the transparent background the best.

I found IE5 on the Mac surprisingly advanced in another area, special character support (better than IE5.5 on Windows).

Most kind of you to reply. Appreciate your benevolence, in the article mention as well. I’ve wondered from the start how long these color references would be useful. They’re selling stronger than ever. (Sold a bunch of mouse pads this week, perhaps I have you to thank?) A very successful design firm wants an 8-foot Scotchprint wall mural, so I’ll probably be adding that to the product line. But, VisiBone being the forward thinking company it is, I know I can’t ride the web-safe wave forever. I’ve begun work on a 16,777,216-color reference poster, for when true 24-bit color is ubiquitous and you write about 16-bit color being dead. Just a few details to work out. It should be about 200′ by 150′ and most installations will use helicopters.

— Bob Stein, VisiBone, 1-954-217-2072, http://www.visibone.com

P.S. In other shameless product mentions, the HTML Card is done prepress and, if printing goes well Monday, will go on sale this coming week. The holy war between structure and presentation should keep this technology seething and tangled for some time to come.

---

From: Bob Stein

Jeffrey Zeldman wrote:
2. STRATEGY 6 — Use transparent backgrounds.

for example, see [non-disclosed web site]

click on the logo at the top.

the hover color fills in, resulting in some weirdly funky ugliness.

Oh, that is truly disgusting. Vince Flanders (webpagesthatsuck.com) has got to see that. (Or is that how you found it? :-D)

I see yet more ugliness when I try to swipe-select the text and image. Four different background colors and three fight the transparent edges.

Do you think it might work if you could turn off a:hover for that hyperlinked image? Lessee, how would that be done, a:hover.images { something } and then <a href=… class=”images”> <img …> </ a> Or even some very fancy CSS rule like a:hover img { something }. But the chances of anything like this working consistently are virtually nil.

Does anyone else get the impression that CSS is just asking to be incompatibly implemented in about 10,000 ways? As a spec it codes a staggering quantity of presentation but is only 90% precise about any part of it.

---

From: Makiko Itoh

Bob Stein wrote:
I see yet more ugliness when I try to swipe-select the text and image. Four different background colors and three fight the transparent edges.

Do you think it might work if you could turn off a:hover for that hyperlinked image? Lessee, how would that be done, a:hover.images { something } and then <a href=… class=”images”> <img …> </a> Or even some very fancy CSS rule like a:hover img { something }. But the chances of anything like this working consistently are virtually nil.

I’ve used something like this:

A.none:link{background:transparent;}
A.none:hover{background:transparent;}

then the A tags which shouldn’t have any hover color change get <a class=”none” yadayada

that does the trick…

I tried Jeffrey’s “hover” alternative – which is

img a:hover, a:hover img, img a:hover:visited, a:hover:visited img {background-color:yourbackgroundcolor} (in this case, I used background-color: transparent)

vs.
A.none:link{background:transparent;}
A.none:hover{background:transparent;}

In IE 5.5/Win Jeffrey’s method works fine. In IE5/Mac…the GIFS have white boxes behind them, with or without hovering. I tried “background: transparent” also…same result on IE5/Mac. (IE5.5/Win works either way.)

the second method (class/style for A) works fine in both.

Now…I’m guessing here that actually IE5 is more correct…since “transparent” should mean that the parent element’s background color (the body in this case, which has a white background) should show through..I think….but hell..yanoo…

I’m guessing..though I didn’t try it out…that *IF* I used the actual background color (blue or green) that it would work, but then I’d have to write a different IMG class for each IMG with a different background…which kind of defeats the purpose.

So I guess the a class– method is the workaround of the day for this situation.

I love browsers. 🙂

---

From: Wanda Cummings

It is quite an interesting article, but I don’t agree with all assertions here. Firstly, they’ve failed to mention that the difference between code-generated and program-generated colour can be caused by programs themselves (like Photoshop, depending on the choice of export — usually adaptive), will convert the colour to 15-bit before it exports it to 8-bit colour. It’s been a longstanding problem and quite annoying. That’s a really, really important factor here and I’m disappointed it wasn’t mentioned. It’s going to put the fear of non-web safe into newbies for the sake of trying to coin a new phrase for a new palette. I haven’t done any research to see if the conversion to 15-bit has been solved in PS6 (or even 5.5 — I’ve been told it hasn’t), but I’ll make a point of it. They didn’t say which version of Photoshop they were using, or if, in fact, they were. I make the assumption they were because they were talking about it so much.

Secondly, I argue that if we’re talking about “consistency,” there is no such thing as web safe anyway. It is absolutely impossible to maintain consistency across every computer and every platform. What the 216 (now 212 — which is one thing I didn’t know) offers us is a “compromise” between Netscape and IE. Heheheh. Um, I think that’s all we can expect, right? 😀 The shifting on 15- or 16-bit systems is inevitable — as inevitable as all monitors not being calibrated to the same tune. Even if the 15- or 16-bit palette didn’t shift, we’d still see different colours because we have to assume that no two monitors out there are calibrated in the same way, no ambient variables are alike, no resolution and memory allocations are alike, yada yada. Yes, okay, maybe two monitors are calibrated to the same tune (us weird print folks :D), but you get my point.

There’s also resolution to think about, and memory cards. And that resolution changes with the amount of memory available. My god, it’s endless. And then Unix systems very often are limited to a 5 cube — and sometimes 4!

It was a good article, but as they’ve said themselves, they hadn’t done extensive research on it. And it would be pointless anyway. There are just too damn many variables. Ever watch a wall of TVs at a department store made by the same manufacturer? Again, IMHO, if we’re referring to “web safe” as “consistency,” there’s no such thing. If we’re referring to “web safe” at a pretty good stab at consistency, well, then we’re talking. : )

---

From: Hadley Stern

Wanda, hello from a fellow Canadian (Ottawan now in Boston)

Thanks for some very good points. We used Photoshop 5.5 for all our tests and it didn’t occur to me that photoshop could be at fault. A good question and one that we will tackle in a follow-up article. As far as gow the images were exported gifs can hold up to 216 colors, any colors that is, web safe or not. The problem is there is no such thing as a 16-bit color, either in hex value or in a photoshop interpretation. There are 8-bit colors, and then 24-bit colors, and thats that.

As far as the wall of tv comments that is absolutely true but also doesn’t really pertain to what we are talking to here. Gamma calibration (and there are some products trying to deal with this, can’t rememeber their names off the top of my head) is a big issue but unrelated to gif and hex values shifting.

As you noted we noted we are just two guys, and the more feedback from the web community at large the better.

thanks!!

---

From: Wanda Cummings

Hey, Hadley! Thanx for your reply. Spent a number of years in Ottawa myself and really enjoyed the city. : )

Thanks for some very good points. We used photoshop 5.5 for all our tests and it didn’t occur to me that photoshop could be at fault. A good question and one that we will tackle in a follow-up article.

Great.

As far as gow the images were exported gifs can hold up to 216 colors, any colors that is, web safe or not. The problem is there is no such thing as a 16-bit color, either in hex value or in a photoshop interpretation. There are 8-bit colors, and then 24-bit colors, and thats that.

Yes, I agree.

As far as the wall of tv comments that is absolutely true but also doesn’t really pertain to what we are talking to here.

<smile> That was more directed at individual settings, etc., reasons for inconsistencies.

Gamma calibration (and there are some products trying to deal with this, can’t remember their names off the top of my head) is a big issue but unrelated to gif and hex values shifting.

Have you looked at the PNG technology, Hadley? We definitely need to do some work in getting browsers to fully support it, but it’s headed in the right direction, offering built-in gamma, etc.

As you noted we noted we are just two guys, and the more feedback from the web community at large the better.

Hey, well, I’m just one woman. <vbg> And to be quite honest, Hadley, I sometimes err on the side of familiarity just to let people know how darn human

I am. That sometimes doesn’t come across well in email. I hope I haven’t offended you in any way; that was certainly not my intent. I think you know that anyway. : ) Thanks so much for dropping a line. I appreciate it.

---

Still confused? Read Joe Gillespie’s article entitled “Is the Web Safe Palette really dead?” …this is probably the best explanation of the issues involving the Web-Safe Color Palette on the net today.

Related Topics: Color, Web Design