Re: [tlug] Re: Color Codes

[Brett Robson <b-robson@example.com>]

BABA Yoshihiko wrote:

>
> On 2005/01/24, at 23:05, Brett Robson wrote:
>
>> Tobias Diedrich wrote:
>>
>>> Lyle (Hiroshi) Saxon wrote:
>>>
>>>
>>>> "I've added an asterisk (*) to all the non-dithering, web-safe 
>>>> color codes, just so you know which ones they are.  These are the 
>>>> colors that show up the same on every computer no matter what (or 
>>>> so I've been told)."
>>>>
>>>
>>> I guess this means the colors from the "web-palette" for indexed
>>> 256 color mode.  Since nearly all users are using Hi- or Truecolor 
>>> these
>>> days, this is not an issue any more.
>>>
>>>
>>
>> That is dithering. I have already explained what web-safe means.
>
>
> Not really. What people say 'web-safe' colour is not as you explained. 
> Check this:
> http://en.wikipedia.org/wiki/Web_colors
>
> What web-safe means in some situation is, for example, it will display 
> precisely the same as what the printed one shows, especially for the 
> large cooporations. And as Stephen pointed out, it is technical not 
> feasible. It is not an issue in most cases, though.

http://webmonkey.wired.com/webmonkey/00/37/index2a.html
*Death of the Websafe Color Palette?*
As we just concluded, High Color systems share no colors with your 
standard Photoshop 24-bit color palette (except for black and white). 
Consequently, browsers running on High Color systems have to perform 
this request for a new color continually. Since High Color is still a 
good color depth, the colors that the system chooses are usually good 
(solid, true colors), but they're not exactly what you thought you were 
getting when you originally selected the colors for your site.
 :
 :

/STRATEGY 5 -- Keep the GIFs and code-generated color separated/.
Since the shifts in color performed by the browser on 16-bit systems are 
usually very subtle, they won't cause a drastic imbalance in your chosen 
palette for the most part. But if you place a GIF and code-generated 
color right next to each other, the browser's bad habit of shifting the 
two to different values gets highlighted, and the discontinuity suddenly 
gets thrown into relief. If you keep the two apart, however, users will 
be less likely to notice the problem. (Although you should still test 
your colors; some differences are too distinct to ignore, no matter how 
far apart they are).

/STRATEGY 6 -- Use transparent backgrounds./
If you do have to have a GIF and code-generated color next to each 
other, try this: When you export your GIF, select the color that's going 
to be in the code next to it and make that transparent. Then set the 
BGCOLOR of both the cell in which you've placed the GIF and the adjacent 
cell to the same value. That color will now bleed through the GIF, and 
regardless of which color the browser shifts it to, it will be the same 
for both the GIF and the code-generated color, since really it's not in 
the GIF at all. There is, however, at least one big limitation with this 
approach: You can only choose one color to be transparent in the GIF, 
which is a problem if the GIF has to be continuous with more than one 
color. To be sure, you can make more than one color in a GIF be 
transparent, but the color that will bleed through will have to be the 
BGCOLOR of an HTML container (such as a DIV, SPAN, or TD), and an image 
can't span these containers. Therefore, no matter how many colors you 
make transparent in your GIF, only one color can show through.