How browsers handle rgb (in percent); for weird numbers

Question

This is due to CSS color codes:

For hexcode, we can display 16,777,216 colors from # 000000 to #FFFFFF

According to the W3C specifications, the actual RGB percentages range from (from 0.0% to 100.0%), giving you 1,003,003,001 color combinations. (1001 ^ 3)

According to specifications:

Values ​​outside the gamma of the device must be trimmed or displayed in the gamma when the gamma is known: the values ​​of red, green and blue must be changed to fall within the range supported by the Device. User agents can perform better color matching from one gamut to another. For a typical CRT monitor, whose gamma is the same as sRGB, the four rules below are equivalent:

I doubt that browsers can actually display all of these values. (but if they do, tell me and ignore the rest of this message)

Im assuming there is some mapping from rgb (in percent) to hex. (but again Im not quite sure how this works)

Ideally, I would like to know the rgb function (in percent) -> HEX

If I had to guess, this would probably be one of these 3.

1) Round to the nearest HEX

2) CEIL to the nearest HEX

3) FLOOR to the nearest HEX

The problem is that I need to be precise regarding the display, and I have no idea where to look. There is no way that my eyes can distinguish color at this level, but maybe there is some clever way to test each of these 3.

It may also be browser dependent. Can this be verified?

EDIT:

Firefox seems to round from empirical testing. 

EDIT:

I am viewing Firefox source code right now,

 nsColor.h // A color is a 32 bit unsigned integer with four components: R, G, B // and A. typedef PRUint32 nscolor; 

It seems that Fiefox has only room for 255 values ​​for each R, G, and B. Assuming rounding might be the answer, but maybe something is happening with the alpha channel.

Answer 1

I think I found a solution for Firefox anyway, thought you might like the following:

Looking through the source code, I found the file:

nsCSSParser.cpp

For each rgb percent, it does the following:

• The percentage component is required to multiply it by 255.0f
• Keeps it in a float
• Passes it to the NSToIntRound function
• The result of NSToIntRound is stored in an 8-bit integer data type before it is combined with the other 2 components and the alpha channel

Look for more information about NSToIntRound:

 nsCoord.h inline PRInt32 NSToIntRound(float aValue) { return NS_lroundf(aValue); } 

NSToIntRound is a wrapper function for NS_lroundf

 nsMathUtils.h inline NS_HIDDEN_(PRInt32) NS_lroundf(float x) { return x >= 0.0f ? PRInt32(x + 0.5f) : PRInt32(x - 0.5f); } 

This function is actually very smart, it took me a while to decrypt (I actually don't have a good background in C ++).

Assuming x is positive

It adds 0.5f to x and then discards the integer

If the fractional part x was less than 0.5, adding 0.5 will not change the integer, and the fractional part will be truncated,

Otherwise, the integer value is pressed by 1, and the fractional part is truncated.

• Thus, each percent of the component is first multiplied by 255.0f
• Then rounding and adding to a 32-bit integer
• And then turn it back into an 8-bit integer

I agree with most of you who say that this is a problem with the browser, so I will continue to explore other browsers.

Thanks a bunch!