Death of the Websafe Color Palette?
September 8, 2000 9:08 AM Subscribe
Death of the Websafe Color Palette? Bring some coffee, these people bring a lot of math to their idea.
I'm glad to have an explanation for this at last... I've been noticing the 16-bit problem for years. Nice to know it's a browser bug that's gone unfixed all this time! *FUME*
posted by wiremommy at 11:47 AM on September 8, 2000
posted by wiremommy at 11:47 AM on September 8, 2000
Thank goodness. A project that I'm working on that is extremely sensitive to the colors used has been driving me and my fellow designers up the wall for what seems like an eternity.
posted by hijinx at 12:25 PM on September 8, 2000
posted by hijinx at 12:25 PM on September 8, 2000
> A project that I'm working on that is extremely sensitive to the colors used
I believe you've mispronounced "a project almost, but not quite entirely, unsuited to the web." :-)
posted by baylink at 2:49 PM on September 8, 2000
I believe you've mispronounced "a project almost, but not quite entirely, unsuited to the web." :-)
posted by baylink at 2:49 PM on September 8, 2000
I truly hate to tell them this, but I'm on a 16 bit system, and I can't see "even just the least little bir" of the edges between the color swatches.
And I can sight read PMS. :-)
And they missed another thing: 8-bit VGA is typically an 8-bit index into an *18* bit palette -- 6 bits per color, not 8. That sort of trashes their entire theory right there, no?
posted by baylink at 2:56 PM on September 8, 2000
And I can sight read PMS. :-)
And they missed another thing: 8-bit VGA is typically an 8-bit index into an *18* bit palette -- 6 bits per color, not 8. That sort of trashes their entire theory right there, no?
posted by baylink at 2:56 PM on September 8, 2000
Well, black, white and red still work. Maybe Roger Black was right after all...
posted by Aaaugh! at 4:28 PM on September 8, 2000
posted by Aaaugh! at 4:28 PM on September 8, 2000
Hey Zeldman... I had the same problem with the transparent gifs and the hover tags on my home page... I have a workaround for it, but it's ugly....
I create a separate subclass of "a" tags called "text" in my stylesheet that handles anything I want to have the hover effect (the base "a" class doesn't have hover attributes) .. of course every time i do text links, i have to insert "class=text" in my "a" tag, but it does work.
I hope that made sense.
posted by PWA_BadBoy at 5:30 PM on September 8, 2000
I create a separate subclass of "a" tags called "text" in my stylesheet that handles anything I want to have the hover effect (the base "a" class doesn't have hover attributes) .. of course every time i do text links, i have to insert "class=text" in my "a" tag, but it does work.
I hope that made sense.
posted by PWA_BadBoy at 5:30 PM on September 8, 2000
why not just declare:
img a:hover, a:hover img, img a:hover:visited, a:hover:visited img
{background-color:yourbackgroundcolor}
won't that override hover for those that are hover-capable??
posted by greyscale at 7:01 PM on September 8, 2000
img a:hover, a:hover img, img a:hover:visited, a:hover:visited img
{background-color:yourbackgroundcolor}
won't that override hover for those that are hover-capable??
posted by greyscale at 7:01 PM on September 8, 2000
There are a couple things that I think they should've touched on in discussing color. One of them, web publishers have little control over: different devices have different color gamuts. This means that the range of reproduceable colors from two different video cards and two different monitors is vastly different. I've even seen huge differences in the way white looks on the same display device and same video card, but in two different bit depths.
The second problem has to do with the way the human eye perceives colors. Human eyes don't see blue as well as they see reds or greens. This means that in shades of blue, it's harder to see differences in shades of blue than in shades of green. This is why 16 bit color bit allocations usually go 5-6-5 for R-G-B. I would think that it might be better to instead go 6-6-4 instead. While it is typically easy to distinguish between 16 and 32 shades of blue (this is the difference between 4 and 5 bits), this reallocation gives more service to R and G since our eyes can see them better and it also allows a 100% overlap with blues on a 24 bit display and a partial overlap with red and green.
As a historical note, the arcade games Defender, Stargate, Robotron, Joust etc. faced a similar problem. Each pixel was 4 bits used to index a 16 entry palette of 8 bits of color: 3 to red, 3 to green, and 2 to blue.
posted by plinth at 7:29 PM on September 8, 2000
The second problem has to do with the way the human eye perceives colors. Human eyes don't see blue as well as they see reds or greens. This means that in shades of blue, it's harder to see differences in shades of blue than in shades of green. This is why 16 bit color bit allocations usually go 5-6-5 for R-G-B. I would think that it might be better to instead go 6-6-4 instead. While it is typically easy to distinguish between 16 and 32 shades of blue (this is the difference between 4 and 5 bits), this reallocation gives more service to R and G since our eyes can see them better and it also allows a 100% overlap with blues on a 24 bit display and a partial overlap with red and green.
As a historical note, the arcade games Defender, Stargate, Robotron, Joust etc. faced a similar problem. Each pixel was 4 bits used to index a 16 entry palette of 8 bits of color: 3 to red, 3 to green, and 2 to blue.
posted by plinth at 7:29 PM on September 8, 2000
Baylink... ;) Actually the project entailed selecting six main colors - all websafe, since this is a web project - and sticking to them religiously. The thing is, the "shifting" is sometimes apparent with the main color used throughout the site.
You don't know how many times I heard, "Hey, isn't that a different color?" At least now I know it's the shifting.
posted by hijinx at 9:34 PM on September 8, 2000
You don't know how many times I heard, "Hey, isn't that a different color?" At least now I know it's the shifting.
posted by hijinx at 9:34 PM on September 8, 2000
Hmmm... I thought the transparent image rollover backgrounds on ALA were intentional, in any case I thought it was a novel effect :). With a halftone transparent dither, maybe something cool could be made with it, like simulation of a tinted rollover image. For example: http://www.geocities.com/camerapictures/test.html. Not sure if that actually saved file size as opposed to just using a jpg (the image is 11k because of the dithering). Kind of an interesting idea though. Does anyone know if this has been used successfully anywhere?
posted by kidsplateusa at 10:40 PM on September 8, 2000
posted by kidsplateusa at 10:40 PM on September 8, 2000
kidsplateusa: it CAN be used as a special effect (nice example, btw).
greyscale: i think that would work. i'll have to try it. thanks! however, at this point i'm just NOT using transparency for images that will be active links. i know it will look bad in 16-bit. but hey, css looks bad in netscape 4. ya know? "take my web. please!"
plinth: i don't think they forgot about the gamut issue (or even the gamma issue), i think they just focused on one specific problem: the websafe color palette. gamma issues and hardware limitations change the way colors LOOK on a screen, but they don't change the fundamental issue. (#ffcc00 is web-safe in 8-bit and 24-bit displays, whether it looks kinda dark, kinda light, too red, or has a blueish cast it should not have at all, since no blue is specified; it's still web-safe.)
posted by Zeldman at 11:31 PM on September 8, 2000
greyscale: i think that would work. i'll have to try it. thanks! however, at this point i'm just NOT using transparency for images that will be active links. i know it will look bad in 16-bit. but hey, css looks bad in netscape 4. ya know? "take my web. please!"
plinth: i don't think they forgot about the gamut issue (or even the gamma issue), i think they just focused on one specific problem: the websafe color palette. gamma issues and hardware limitations change the way colors LOOK on a screen, but they don't change the fundamental issue. (#ffcc00 is web-safe in 8-bit and 24-bit displays, whether it looks kinda dark, kinda light, too red, or has a blueish cast it should not have at all, since no blue is specified; it's still web-safe.)
posted by Zeldman at 11:31 PM on September 8, 2000
greyscale: I'll have to try that. Thanks.
posted by PWA_BadBoy at 12:34 AM on September 9, 2000
posted by PWA_BadBoy at 12:34 AM on September 9, 2000
« Older The Democrats are trying to throw Ralph off the... | Got time for the jibber jabber? Newer »
This thread has been archived and is closed to new comments
Bottom-line: websafe color palette is not dead; using it is the only viable strategy since NO strategy works for folks with 16-bit color. Their display will ALWAYS be off. Was true five years ago, is true today. Nothing has really changed.
The "use transparency" strategy works ... unless you also use CSS hovers on your links. If you do, then the hover color will fill in the background in your div (or table cell) to ugly effect. Happens on the logo at my dear Prol's site (if your browser displays a: hover; that is, if you use IE). Used to happen on ALA.
To make it stop happening, I stopped using transparency on illustrations at ALA. Result: no hover problems. Secondary result: users of 16-bit color machines (over half the web population) will see the edges of the images, because the colors do not match precisely.
16-bit color and the web. They go together like peanut butter and bicycle chains.
The real solution: stick to the web-safe color palette, realize that 16-bit color users are f*cked from the get-go, and know that soon 24/32-bit color will be the norm.
Don't believe me? Three years ago, 8-bit color was the norm. Graphics cards keep getting smarter and less expensive, and niceties like this are one of the only ways PC vendors can differentiate themselves. (For $599 you get the computer, the monitor, the speakers, the printer, *AND* true color. Buy now!)
And as we all know, in a parity market, once on mfr "differentiates" themselves by offering any feature, all the competitors offer it too.
24/32-bit color will be the norm in our lifetime, friends.
Meanwhile, over half the audience sees ugliness and thinks that's the way the web really looks.
posted by Zeldman at 11:18 AM on September 8, 2000