Hexadecimal colour notation (was: Re: Attach event/function to linkswithin span tag)

Jasen Betts wrote:

I think it was mor an issue of 6^3 < 256 and I'm sure win 3.1 let me define
more than 40 custom colours.

It is not about custom colors! Safe Palette takes into account that on
256 colors display *some* hex triplets lead to *different* display
colors depending on OS (Mac or Windows). There are in total 40 such
colors thus they are excluded from the Safe Palette.

216 Safe Palette colors are guaranteed to be able to display and to be
the same on 256 color display under Windows, Mac and Unix.

Safe Palette has no direct relation with #FFF color notation so the W3C
sentence about "removes any dependencies on the color depth of the
display" is simply a manifestation of ignorance of whoever wrote it.

Actually it is well due to make w3.org a Wiki. That would help greatly
to the community.
:-)
:-|

if a 12 bit palette #FFF was promoted to 24 bit by simply multiplying each
element by 16 (0x10) the dynamic range wopuld suffer #F0F0F0 (a kind of
dirty snow colour) would be the whitest available.

#FFF means #FFFFFF, not #F0F0F0 - on any display.

On 23/01/2006 17:21, Thomas 'PointedEars' Lahn wrote:

Michael Winter wrote:

[snip]

The representation of a particular colour value may differ between
devices, but #bad and #bbaadd, for example, /must/ be rendered as
the same colour on the same device.

You are missing the point. If the display device does not run with a
color depth of 24 bit (16'777'216 colors) or more, it _cannot_
display the color #bbaadd (12'298'973) the same way as if it was a
display device that ran with such a color depth using the same color
components.

I already acknowledged that, above.

[snip]

The reason is that #bbaadd depends on the color depth of the display
device, while #bad [(round(11/15*m), round(10/15*m), round(13/15*m));
m := max(2^color_depth - 1, 255)] does not.

For 'replicated digits' (0x00, 0x11, etc.), the result is the same if
the divisor is adjusted to 255. That is,

187 / 255 == 11 / 15 and,
170 / 255 == 10 / 15 and,
221 / 255 == 13 / 15

so the value of m is irrelevant. You previously asserted that these
colours would not be the same.

[snip]

Mike

--
Michael Winter
Prefix subject with [News] before replying by e-mail.

Michael Winter wrote:

On 23/01/2006 17:21, Thomas 'PointedEars' Lahn wrote:
Michael Winter wrote:
The representation of a particular colour value may differ between
devices, but #bad and #bbaadd, for example, /must/ be rendered as
the same colour on the same device.

You are missing the point. If the display device does not run with a
color depth of 24 bit (16'777'216 colors) or more, it _cannot_
display the color #bbaadd (12'298'973) the same way as if it was a
display device that ran with such a color depth using the same color
components.

I already acknowledged that, above.

No, you did not. The point is that we are trying to be as interoperable
as possible here, among different devices.

The reason is that #bbaadd depends on the color depth of the display
device, while #bad [(round(11/15*m), round(10/15*m), round(13/15*m));
m := max(2^color_depth - 1, 255)] does not.

For 'replicated digits' (0x00, 0x11, etc.), the result is the same if
the divisor is adjusted to 255.

news:2820787.IrJziKQuUd (AT) PointedEars (DOT) de corrects this misformulation.

Internal "digit replication" does not occur with insufficient color depth.

Forget about "digit replication" in the first place, this is not what
happens! It is but an example in the CSS Specification to explain that
the three-digit notation is independent of color depth.

What really happens is adjustment of the color value to the color depth
provided by and set for the display driver; the result is _as if_ the digit
of each component was replicated if, and only if, the color depth is 8 bit
or greater.

That is,

187 / 255 == 11 / 15 and,
170 / 255 == 10 / 15 and,
221 / 255 == 13 / 15

Correct, however you used the wrong equation I provided first instead of
the correct one I provided nine minutes later, long enough before your
followup. (And even common sense could have told you that this equation
cannot be correct...)

so the value of m is irrelevant.

Not at all.

You previously asserted that these colours would not be the same.

The color _components_ are the same _if_ m == 255. I did not debate that,
in fact that was exactly my point. If, and _only_ if, m == 255, that is, a
color depth of 8 bit or greater. (The displayed color with that minimum
color depth, however, is another thing.)

However, they are not the same if `m' is smaller than that. The value of
`m' is of course anything else than irrelevant to this equation as it
depends on the color depth of the display device, to be exact, that the
display driver allows for RGB color components. This is why the six-digit
notation is _not_ independent of the color depth of the display, in
contrast the three-digit notation is. That is why it is safer (read: more
interoperable) to use the latter instead of the former.

If you feed a display driver, say the VGA driver (64 possible values for
each color component, hence a color depth of 6 bit), a color component
value that is out of range, it could either scale it down into range,
inevitably with an _information loss_ (that does not happen with a
three-digit value), or it could not scale it down it into range. It would
therefore, very likely in the former case and certainly in the latter case,
display a different color than _another_ device with the same configuration
except of the color depth (not considering greyscale displays, of course),
given the same color value.


PointedEars

On 2006-02-02, Thomas 'PointedEars' Lahn <PointedEars (AT) web (DOT) de> wrote:

Michael Winter wrote:

On 23/01/2006 17:21, Thomas 'PointedEars' Lahn wrote:
Michael Winter wrote:
The representation of a particular colour value may differ between
devices, but #bad and #bbaadd, for example, /must/ be rendered as
the same colour on the same device.

You are missing the point. If the display device does not run with a
color depth of 24 bit (16'777'216 colors) or more, it _cannot_
display the color #bbaadd (12'298'973) the same way as if it was a
display device that ran with such a color depth using the same color
components.

I already acknowledged that, above.

No, you did not. The point is that we are trying to be as interoperable
as possible here, among different devices.

three or six digits makes no difference to interoperability.

The reason is that #bbaadd depends on the color depth of the display
device, while #bad [(round(11/15*m), round(10/15*m), round(13/15*m));
m := max(2^color_depth - 1, 255)] does not.

For 'replicated digits' (0x00, 0x11, etc.), the result is the same if
the divisor is adjusted to 255.

news:2820787.IrJziKQuUd (AT) PointedEars (DOT) de corrects this misformulation.

Internal "digit replication" does not occur with insufficient color depth.

It could happen and then be rounded down to match the depth.
do you have evidence that it does not happen?

Forget about "digit replication" in the first place, this is not what
happens! It is but an example in the CSS Specification to explain that
the three-digit notation is independent of color depth.

What really happens is adjustment of the color value to the color depth
provided by and set for the display driver; the result is _as if_ the digit
of each component was replicated if, and only if, the color depth is 8 bit
or greater.

Wrong.

If the depth is more than four bits per R,G,B channel the number must
be extended.

That is,

187 / 255 == 11 / 15 and,
170 / 255 == 10 / 15 and,
221 / 255 == 13 / 15

Correct, however you used the wrong equation I provided first instead of
the correct one I provided nine minutes later, long enough before your
followup. (And even common sense could have told you that this equation
cannot be correct...)

so the value of m is irrelevant.

Not at all.

You previously asserted that these colours would not be the same.

The color _components_ are the same _if_ m == 255. I did not debate that,
in fact that was exactly my point. If, and _only_ if, m == 255, that is, a
color depth of 8 bit or greater. (The displayed color with that minimum
color depth, however, is another thing.)


However, they are not the same if `m' is smaller than that.

give an example where #rgb will be a diffrenet display colour to #rrggbb

If you feed a display driver, say the VGA driver (64 possible values for
each color component, hence a color depth of 6 bit), a color component
value that is out of range, it could either scale it down into range,
inevitably with an _information loss_ (that does not happen with a
three-digit value), or it could not scale it down it into range. It would
therefore, very likely in the former case and certainly in the latter case,
display a different color than _another_ device with the same configuration
except of the color depth (not considering greyscale displays, of course),
given the same color value.

ther's no need for there to be differences in the way 12 bit and 24 bit
colour specifiers render.

#000 == #000000 == vga(0,0,0) \\ 0 == floor( 0 * 17 / 4 )
#111 == #111111 == vga(4,4,4) \\ 4 == floor( 1 * 17 / 4 )
#222 == #222222 == vga(8,8,8) \\ 8 == floor( 2 * 17 / 4 )
#333 == #333333 == vga(12,12,12) \\ 12 == floor( 3 * 17 / 4 )
#444 == #444444 == vga(17,17,17) \\ 17 == floor( 4 * 17 / 4 )
#555 == #555555 == vga(21,21,21) \\ 21 == floor( 5 * 17 / 4 )
#666 == #666666 == vga(25,25,25) \\ 25 == floor( 6 * 17 / 4 )
#777 == #777777 == vga(29,29,29) \\ 29 == floor( 7 * 17 / 4 )
#888 == #888888 == vga(34,34,34) \\ 34 == floor( 8 * 17 / 4 )
#999 == #999999 == vga(38,38,38) \\ 38 == floor( 9 * 17 / 4 )
#aaa == #aaaaaa == vga(42,42,42) \\ 42 == floor( 10 * 17 / 4 )
#bbb == #bbbbbb == vga(46,46,46) \\ 46 == floor( 11 * 17 / 4 )
#ccc == #cccccc == vga(51,51,51) \\ 51 == floor( 12 * 17 / 4 )
#ddd == #dddddd == vga(55,55,55) \\ 55 == floor( 13 * 17 / 4 )
#eee == #eeeeee == vga(59,59,59) \\ 59 == floor( 14 * 17 / 4 )
#fff == #ffffff == vga(63,63,63) \\ 63 == floor( 15 * 17 / 4 )

--

Bye.
Jasen

On 02/02/2006 05:41, Thomas 'PointedEars' Lahn wrote:

[snip]

The reason is that #bbaadd depends on the color depth of the display
device, while #bad [(round(11/15*m), round(10/15*m), round(13/15*m));
m := max(2^color_depth - 1, 255)] does not.

For 'replicated digits' (0x00, 0x11, etc.), the result is the same if
the divisor is adjusted to 255.

news:2820787.IrJziKQuUd (AT) PointedEars (DOT) de corrects this misformulation.

Yours, yes. It has nothing to do with my previous post.

Above, you present an operation that divides 4-bit values by 0x0F. My
point was that a similar operation with equivalent 8-bit values using
0xFF (chosen due to larger input values, not colour depth) produces
/exactly/ the same result. Your error with respect to the definition of
m, as well as the value of m itself, played no part in this aspect of
what I wrote.

[snip]

You previously asserted that these colours would not be the same.

The color _components_ are the same _if_ m == 255. I did not debate
that, [...]

You added that condition.

[snip]

If you feed a display driver, say the VGA driver (64 possible values
for each color component, hence a color depth of 6 bit),

6-bit? The definition of colour depth that I'm familiar with has it as a
synonym for bits-per-pixel, therefore with palettized devices, the
colour depth may not be related to range of component values.

a color component value that is out of range,

It would seem to me that a device driver would be used with a
well-specified interface which would clearly state the range of values
allowed for colour components. Therefore, any application that passed an
out-of-range value, either directly to the driver or to a library, would
be broken.

For example, Windows GDI uses a range of 0-255 for component values.
However, calling the SVGALib functions vga_setpalette or vga_setpalvec
with values outside the 0-63 range would be a stupid thing to do. It
would be up to the browser to scale the input for the latter.

it could either scale it down into range, inevitably with an
_information loss_ [...]

Yes, information loss is inevitable for some devices when given a colour
like #468b3a (a random choice), but you have still not convinced me that
if #bad would not result in a loss then #bbaadd would (broken
applications aside).

I hoped that cross-posting this debate to ciwas would invite a fresh
perspective from its regulars. Unfortunately that hasn't happened. I
feel that this is reaching yet another moment when we will just have to
agree to discontinue the discussion. You (or anyone else) are welcome
though to try to present your case one last time, but I can't guarantee
that I'll reply. I have no problem with being wrong, but you haven't
persuaded me and it doesn't seem like you will.

Incidentally, the WCAG 2.0 Guidelines recommend using the six-digit
notation to specify colour for reasons of compatibility.

Mike

--
Michael Winter
Prefix subject with [News] before replying by e-mail.

Oh my... are you still discussing it? It is a wrong statement in CSS2
specs I already reported. Hopefully someday it will be corrected.

Once again: taking a 8-bit color depth (256 colors) there are 216
colors which are guaranteed to display equally on Windows, Mac OS and
Unix clones. 40 colors will differ on different platforms despite their
hex triplets are the same.
It is happened that each or 216 colors has the form #XXYYZZ. At the
same time not any color in the form #XXYYZZ is palette-safe and may
produce different outcome on different platforms *if color depth is
8bit*.

If you want to rediscover America, you are welcome to repeat the
experiment which Lynda Weinman and Bruce Heavin conducted that summer
of 1996.
Prepare three machines with Windows, Mac OS and Linux. Drop color depth
on all to 256 colors. Test each and every color from the safe palette
<http://www.lynda.com/hex.asp>. Try any other colors outside of palette
(even having the #XXYYZZ form).

Again: the relevant statement in CSS2 is plain b.s. (non-academical but
exact term). Rather than vasting electrons in this thread one could
prepare a petition to W3C asking to edit the paragraph. In any case it
should not be a reason to have sleepless nights :-)

-------------------------------------------------------------------------
"VK" <schools_ring (AT) yahoo (DOT) com> wrote

Once again: taking a 8-bit color depth (256 colors) there are 216
colors which are guaranteed to display equally on Windows, Mac OS and
Unix clones. 40 colors will differ on different platforms despite their
hex triplets are the same.

The so-called Web Safe Colors have been obsolete since at least 2000. Nobody
uses 256 colors any more. Not sure why it is even mentioned at w3c.

Windsun wrote:

[...]
"VK" [...] wrote [...]:
Once again: taking a 8-bit color depth (256 colors) there are 216
colors which are guaranteed to display equally on Windows, Mac OS and
Unix clones. 40 colors will differ on different platforms despite their
hex triplets are the same.

The so-called Web Safe Colors have been obsolete since at least 2000.

How did you get that idea?

Nobody uses 256 colors any more.

Wrong. Besides, you have not understood the difference and the connection
between the Netscape Web-safe Colors palette, color-depth independent CSS
colors and True Web-Safe (CSS) colors.

Not sure why it is even mentioned at w3c.

Because the W3C people care about interoperable document resources, and are
therefore competent regarding Web authoring, in contrast to you.

Please learn to quote.


PointedEars

Thomas 'PointedEars' Lahn wrote:

Besides, you have not understood the difference and the connection
between the Netscape Web-safe Colors palette, color-depth independent CSS
colors and True Web-Safe (CSS) colors.

Do you have any idea what did you just typed in here? Or you just
copy'n'paste all terms you could find in quick search?

Netscape Palette is an obsolete name of Web-Safe Palette. This is the
same 216-colors palette mentioned many times in this thread.

Color-depth independent CSS is a misterious term used in the discussed
revelation of anonymous author on the W3C page. Presumably it supposes
to reflect (besides everything else) the 8 bits adapter with 256 (2^8)
color depth. It was clearly explained why this revelation is plain b.s.

True Web-Safe (CSS) colors is a new term coined in your own
revelations. Supposedly it has some sense unknown to the regular mortal
people.
I guess it means that there are 216 safe colors everyone knows about -
and independently of that 256 True Safe colors known only to the real
believers.

Because the W3C people care about interoperable document resources, and are
therefore competent regarding Web authoring, in contrast to you.

Because some (not all!) W3C volunteers do not care to learn the basics
but dare to codify the things way above their current knowledge.

P.S.
<http://www.library.georgetown.edu/dept/gelardin/guides/webcolor/websafe.htm>
Also choose any color in XXYYZZ format - but not listed in Lynda's
palette - and compare its appearance on different color depth.

If you discover that 216 colors rules doesn't apply anymore, then post
a link with screenshot as it would be a great discover of the new
century.

Otherwise just STFU please.

On Fri, 24 Feb 2006, VK wrote:

Thomas 'PointedEars' Lahn wrote:

[trolling, as usual....]

True Web-Safe (CSS) colors is a new term coined in your own
revelations.

I associate the term with an article that I read some time back on
webmonkey, in which they concluded there were less than a couple of
dozen colours which were truly safe.

Google suggests it must have been this one (or rather, this is the
starting point - it links to various segments):
http://hotwired.lycos.com/webmonkey/...html?tw=design

(If you care to try reading this, you might want to adjust your
browser beforehand against the hail of cookies and popups.)

No doubt it was all well-meant, in their own terms, but I'd have drawn
quite different conclusions from the same observations.