Talk:X11 color names

Duplicated colors

Some of these are the same color but the names are not. Whose problem is this?? 66.245.78.149 20:23, 29 Sep 2004 (UTC)

I've just checked the rgb.txt file on my PC (running XOrg 6.7.0) and it's that way in the original file. (The original file is in numerical order of colour triplets, so it's really obvious.) I'll add a note to the article - David Gerard 12:21, 2 Oct 2004 (UTC)

Visibility?

Some of the colour names are also links to wiki nodes. Names for some of the darker colours are difficult to read, because wiki links are coloured blue. Blue on darkness == bad visibility.

Any idea what could be done to remedy this? What if we duplicate the name, first as plain text and second as a wiki link?

Tricky one ... they may be blue but aren't necessarily - David Gerard 16:41, 11 Dec 2004 (UTC)

To me, the obvious solution is to separate the text from the displayed colors, like this:

Name	= Color	Hex	= Color	RGB	= Color
AliceBlue		#F0F8FF		240, 248, 255
AntiqueWhite		#FAEBD7		250, 235, 215
Aqua		#00FFFF		0, 255, 255
Aquamarine		#7FFFD4		127, 255, 212
...		...		...

That way it doesn't matter which colors get linked. - dcljr 06:55, 27 Jan 2005 (UTC)

Indigo? and Other Added Colors

The copies of rgb.txt I have access to (XFree86 4.3.0, Xorg 6.8.1, the X server shipped with Solaris) don't contain an entry for indigo. What is the source of the indigo entry?

Same for copies of rgb.txt I have access to: Xorg 6.8.2, XFree86 4.2.1, XFree86 4.1.0, and also Emacs 21.4 and 21.2 (for Cygwin). http://vancouver-webpages.com/DIY/color.html mentions that Netscape and WebTV, but not rgb.txt, have indigo; but that's all the info I could find online about it (other than pages including it in a list of X11 color names). --Mairi 06:29, 7 September 2005 (UTC)

Comparing this list to my actual rgb.txt ($Xorg: rgb.txt,v 1.3 2000/08/17 19:54:00 cpqbld Exp $), these eight colors are in the wikipedia article but not in the file: aqua, crimson, fuchsia, indigo, lime, olive, silver, and teal. Furthermore, some colors listed in rgb.txt aren't listed in the article, not including the numbered colors (ie "gray99"). Also, the list doesn't stay consistent with its naming of the grays, while rgb.txt lists both the American English spelling (gray) and the British English spelling (grey) every time that name is used. Clearly, the list presented in the article isn't from an actual copy of rgb.txt. --Jaybeeunix 02:17, 3 October 2005 (UTC)

This authorative page [1] lists 140, the WP article has seven more, all of which are gray/grey variants. I am therefore removing the disputed tag, which in any case should have been inserted in the article only after failure to reach a concensus here. Viajero | Talk 17:49, 18 February 2006 (UTC)

[2] is not an authoritative page for this article. As the article states, that is “a list of the X11 colors [X11COLORS] supported by popular browsers” (my emphasis added). Thus, that page only purports to be a subset of the X11 colors. The subset nature is more obvious if one follows the link to which the w3c page refers to as the authority of that list. --Jaybeeunix 17:07, 19 February 2006 (UTC)

Gamma Correction

Are these gamma corrected? Do they assume they will be displayed on a standard 2.5 gamma CRT or LCD? Otherwise, the values need to go through gamma correction to see the real result (see http://xona.com/colorlist for an example of how FAR off the mark colors can be without proper gamma correction). Also, you can't assume the browser programmers to have thought of this. The standard 6x6x6 = 216 colors 'web safe colors' are an example of where they just don't 'get' gamma correction: Web_colors.137.186.22.189 20:44, 18 November 2005 (UTC)

Since this article is about X11 I think it should be noted that the individual X servers (basically the display) have an option to specify one’s gamma correction for his/her hardware. For example, see the -gamma, -rgamma, -ggamma, and -bgamma options in XFree86-like servers. --Jaybeeunix 18:44, 21 February 2006 (UTC)

If the orginal list was given in sRGB and the user has calibrated his monitor properly, then using the original RGB values should yield the result we want. Shinobu 03:12, 25 March 2006 (UTC)

I belive list is just list of RGB triples, thus it assumes sRGB. However, before performing real manipulations (like combining multiple colors, doing gradients, introducing alpha channel, or making color darker/brighter) one should convert to linear space for correct math operations. I do not know what CSS spec says about this. --91.213.255.7 (talk) 20:16, 27 December 2011 (UTC)

Table simplification

I've made the following changes to the table:

1. Removed background color from all text cells so everyone can read the text, regardless of gamma/monitor settings, etc.; only Sample column now shows the colors.
2. Used hex to specify color in "style" attribute (figured this would be the most widely supported, although any browser that knows "style" should be able to handle all three ways of specifying color — another reason I removed color from the other 2 columns). If you know that some browsers/OSs will show different colors depending on how they are specified (name/hex/rgb), please discuss here.
3. Removed a lot of the formatting (font size, text alignment); made color-name cells regular cells rather than header cells; changed "monospace" style to <tt> tags (better browser support, I assume).
4. Linked "Hex" and "RGB" in header (oh, and removed "#" from hex values in that column).

I hope there aren't any major objections; this article has just bugged me for a long time, so I decided to finally do something about it. - dcljr (talk) 00:19, 2 April 2006 (UTC)

I changed the table format to match List of colors. I think the table looks much nicer with RGB values in seperate columns. However, I also reintroduced bold names, #-prefixes, and some right-aligned text. I did this mostly for consistency, rather than personal preference. If you strongly disagree with these changes, the #-prefixes and bold names are easily removed with find-and-replace. But please consider keeping the RGB values right-aligned. They're prettier that way. —Ryanrs 13:03, 22 April 2006 (UTC)

Not sure why that would be, but whatever. That's fine. Still looks a lot better than before my last edit. - dcljr (talk) 06:39, 23 April 2006 (UTC)

Wonderful work all the way around, but the list was more useful to me when the groupings were by color; e.g., I want to look through the reds, or the greens, or whatever. The Turkish translation still has this arrangement, and I hope it gets kept. For the English language, I think it's fine to leave what's here as-is, and add another table that's grouped by appearance. Marc W. Abel 22:25, 8 October 2006 (UTC)

I completely agree - wonderful work on the simplified table format - thanks dclrj! Marc - maybe the table grouping by color could be made into it's own page. I would also find that useful. Then you could link that article to this page. --Unixguy 11:37, 10 October 2006 (UTC)

Marc - for the table grouped by color, see the Web Colors article. --Unixguy

I would recommend moving hex into a single column: the only reason to have hex there is for copy/paste into contexts where a hex designation is needed; otherwise it’s completely redundant with the decimal representation. Hex should either be scrapped as redundant, or else it should be put into one column where it can be usefully copy/pasted. –jacobolus (t) 23:11, 31 May 2010 (UTC)

Khaki

According to Khaki_(color)#Web_color_light_khaki, web kaki is #C3B091 and X11 khaki is #F0E68C. Quote>

This is the color called khaki in X11. This is one of the cases where the X11 color names differs from the HTML/CSS names.

--burga (talk) 21:13, 15 March 2009 (UTC)

That article was wrong, I corrected it. — Christoph Päper 17:27, 12 September 2010 (UTC)

HTML Gray and others are mistaken

Shouldn't the hex (and by extension the numeric value) of gray be listed as 0x808080 for the HTML comparison? Same goes for green, etc. 7F should be 80, right?--61.194.119.130 (talk) 05:30, 7 May 2010 (UTC)

table gone out of control

Hi Crissov. I’m pretty unconvinced that the color names table here needs 21 columns, the first 9 of which are basically 3 numbers redundantly repeated 3 times each. Almost no readers of this article are going to care about most of the subsequent columns, either. I would suggest instead using columns:

• "8-bit hex" (here meaning 8-bit per component). This is the 6-hex-digit code which will produce the color in HTML or similar. This column need not be broken into 3 parts or sortable, since the ordering is redundantly stored in the next columns.

• R, G, and B components, as 3-digit decimals, on the range [0, 1]. These are much more intuitively obvious than integers in the range [0, 255], and more precise than integer percentages in the range [0, 100]. The decimal point makes it immediately clear what the number represents, so readers need not scroll up to the top of the table to see the "(%)" in the column header. Another possibility would be to use percentages with one digit of precision after the decimal. In that case I would recommend putting the % explicitly after each number: it doesn’t take that much space.

• H, S, and L components, the first in degrees [0, 360) with one place after the decimal point, and the latter two as 3-digit decimals in range [0, 1] (or possibly percentages, as w/ RGB). The reason to include H, S, L is that SVG and HTML now support the use of these directly. There's no reason to include HSV, luma, component average, etc., since users need not input these directly, and they are not especially relevant to human vision anyway. They’re included in the example color table in the HSL/HSV article because in that context they are the quantities under discussion, but here they’re just noise.

• Possibly L*, a*, b* (or even just L*), since these are quantities which *are* (somewhat) relevant to human vision, and would potentially be useful to sort by. L* in particular is a pretty decent proxy for perceived lightness. The CIELAB components here could be computed either relative to D65, as in sRGB, or relative to D50, to match the CIELAB mode used by Photoshop and ICC profiles.

In other words, I would recommend using either 7 columns, or 8, or 10, but 21 is way out of hand.

Also, if columns need to be broken into sections, using narrow empty columns is a bad way to do it, since that breaks up the horizontal lines which allow tracking across rows, and in general looks very busy. If this is really necessary, it should perhaps be done using slight background color differences. I’m not convinced it matters though if the number of columns is kept in check.

Finally, the seemingly randomly bolded entries in the table seem like a bad idea to me.

Cheers, jacobolus (t) 19:04, 11 September 2010 (UTC)

I’m fine with combining the hexadecimal RGB representation into one column.

How are numbers in [0, 1] inherently more precise than numbers in [0, 100]? Percentages are established here, e.g. in CSS. Sadly, the decimal 8bit values are a standard way to enter, display or store colors, too, so we should probably keep them, but I agree that of all the RGB representations they are the ones to scrap (if any) – they could be moved to the title attribute. Percentages are used pretty much everywhere, except for hue. I don’t know whether you’ve seen it, but until yesterday I had the ‘%’ (and ‘°’) signs inside each cell. I don’t see the point in adding a decimal point and a digit to the percentages.

CSS’s inclusion of HSL was my reason to edit the table in the first place. I also added HSV/HSB (where hue is the same), because elsewhere it seems more popular, e.g. in {{infobox color}}. HSI (with its differing chroma) is mostly here for completeness (and I don’t remember why I put ℙs in there), also because it differs from HSL stronger than HSV. Y′₆₀₁ can safely go. As far as I know, HVC and HLC are sometimes used, but the HSI chroma may go.

I actually only accidentally saved the bold highlights for multiples of 30° and 25%.

Empty cells spanning the whole column are the easiest and most reliable way to simulate colgroup in Mediawiki. They may break sorting, though, but colspan does too. But I probably don’t notice drawbacks as much, because my user stylesheets include CSS row highlighting.

L*a*b* (lightness) might be useful, but I didn’t have a simple formula at hand the other day.

I wish columns were collapsible, but no admin implemented that. — Christoph Päper 11:53, 12 September 2010 (UTC)

Color name	Sample	RGB16		R10	G10	B10		R (%)	G (%)	B (%)		C (%)		H (°)	S (%)	L (%)		H (°)	S (%)	B, V (%)		C (%)	H (°)	S (%)	I (%)
Alice Blue		#F0F8FF		240	248	255		94	97	100		6		208	3	97		208	6	100		5	208	3	97

Color name	Sample	RGB16	R (%)	G (%)	B (%)	C (%)	H (°)	SL (%)	SB (%)	SI (%)	L, I (%)	B, V (%)
Alice Blue		#F0F8FF	94	97	100	6	208	3	6	3	97	100

Color name	Sample		RGB16	R	G	B		H	S	L / B	C		H	S	I	C
Alice Blue			#F0F8FF	240 94%	248 97%	255 100%		208°	3% 6%	97% 100%	6%		208°	3%	97%	5%

Color name	Sample	RGB16	R	G	B	H	S	L	C
Alice Blue		#F0F8FF	94%	97%	100%	208°	3%	97%	6%

Okay, I really dislike your idea of showing multiple different quantities in a single column, just hidden away in a title attribute. However, showing alternate forms of the same quantity in a title view seems reasonable enough. Notice how your first few suggested tables here are really long and complicated but without any extra information likely to be useful to readers. We should chop those bits out. My suggestion would be something like the following:

	Name	8-bit hex	R	G	B	H	S	L
	Alice Blue	#F0F8FF	.941	.973	1.000	208.0°	100.0%	97.1%

Or perhaps (with some space to reduce the claustrophobic clutter):

	Name	8-bit hex	R	G	B	H	S	L
	Alice Blue	#F0F8FF	.941	.973	1.000	208.0°	100.0%	97.1%
	Antique White	#FAEBD7	.980	.922	.843	34.3°	77.8%	91.2%
	Cornflower	#6495ED	.392	.584	.929	218.5°	79.2%	66.1%

It’s just as well they don’t have collapsible columns. Sounds like a usability nightmare.

The goal here should be to (1) cut out as much redundant information as possible, while keeping those bits which are likely to be useful to many users (“completeness” as an abstract concept is decidedly not the goal, or we could include 100 extra columns for each of these), (2) present the whole thing in as clean and uncluttered a fashion as possible.

–jacobolus (t) 14:29, 12 September 2010 (UTC)

Like I said, there’s no reason to use floats for RGB (or anything else). They’re even wider than the percentages, at least once you add the missing leading zero.

Three significant digits suggest more precision than there is and will probably reveal (more) rounding oddities that are not helpful.

title="248/255" is probably better than just title="248".

I don’t care about “Color name”/“Name” or “Sample”/“Color” (nor their order), but the caption for hex triplets should say that it is RGB. It indeed doesn’t have to be sortable.

Never use <tt> but <code>. Specifying column width would be the last thing to take care of.

“sRGB” in the title attributes is unnecessary, and so is “HSL” (if there’s only RGB and HSL).

I’m leaning towards preferring my second table layout above, with the first two colums of your first layout and explanatory text. How about leaving out ‘%’ completely and only adding ‘°’ to hues?

Anyhow, I just found the bug in my script that resulted in wrong saturation values for HSL, often equal or similar to those of HSI (like 3% for Alice Blue instead of 100%). — Christoph Päper 17:17, 12 September 2010 (UTC)

	Color	RGB16	R	G	B	C	H	SL	SV	SI	L	V
	Alice Blue	#F0F8FF	94	97	100	6	208°	100	6	3	97	100

Okay. There are no floats anywhere here. This is all decimals at some definite precision. I just prefer 3 digits of precision to 2, and prefer using a '.' at the front to a '%' at the end. Since most elementary school students are extensively trained in the decimal system, Wikipedia’s readership should be perfectly capable of reading decimal numbers in a table. A list of further comments:

• The symbols S_L, S_V, and C are not typical, and using them without further explanation (no, a link isn’t good enough) is a bad idea. The quantity C is used in the HSL and HSV article because it explains the derivation and helps relate the various quantities to each-other, but the use of words “chroma” and “saturation” is so variable among sources that it’s a bad idea to adopt that article’s naming conventions in places where they aren’t explicitly described (e.g. here). S_I is such a rarely seen quantity (and usually in conjunction with a different definition of hue than the one used in HSL/HSV) that it’s a bad idea to list it here: it just leads to confusion.
• There’s no need to include HSV in the table. Both HSL and HSV are terrible models which should be avoided to the extent possible (I say this having mostly written HSL and HSV), but HSL might as well be included since it is used by the web browsers themselves. But one of the two is more than enough. If we want other color descriptions we should use Munsell, CIELAB, CIECAM02, or similar.
• There’s no reason to make the hex value column sortable. The sorting of that column is redundant to sorting on R, G, B columns, and trying to sort by it will in practice only sort by R, which is confusing for users.
• Using both a link in the heading and a title attribute on the cell is self-defeating, because the wiki-link’s mouseover text will clobber the cell’s.
• I don’t care whether the color names are in TH elements or TD elements, but there’s no good reason to make the text bold (it's just a distraction), and it should be left-aligned.
• Any values which are percentages should have the percent sign explicitly written in the cells. To leave it out or put it at the top adds mental overhead for little gain.
• There are a couple reasons for using an 3 digits of precision. (1) There are about 2½ digits worth of precision in the original data range log₁₀(256) = 2.4, so only using 2 digits of precision is leaving off data. But anyway, these colors are defined to be these precise values, and so even in higher-precision output systems (>8 bits/channel) they are exactly reproducible. (2) There are on average about 2 and a half 8-bit numbers per integral percentage. To make these sort properly, 2 digits of precision are insufficient. In the case of HSL “lightness” (or other similarly motivated quantities) this is especially important in my opinion, since all of the components’ values contribute to this, making it effectively more finely tuned than individual RGB components. (3) It really isn’t any harder to read the table with an extra digit on these, since users should understand the decimal system pretty well, and can read from left to right (which means they should easily understand that ".358" is "about 36%").
• I don’t think it’s helpful to include a “hide” link to collapse the table. That’s just a distraction.
• RGB₁₆ is not a meaningful label. "Hex triplet" would be an okay label, but I personally think 8-bit hex is clearer. As for the “RGB” part. All of these quantities (R, G, B, hex, H, S, L) are just as dependent on “RGB” – or in this case specifically sRGB. Users will either recognize the #FFFFFF form, or click the link and figure out what a hex triplet is, or else ignore that column.
• All the numeric columns should be right-aligned.

–jacobolus (t) 20:06, 12 September 2010 (UTC)

I’ve changed the table to use {{Colort}} like List of colors does. — Christoph Päper 00:15, 13 September 2010 (UTC)

I like some of your improvements to the Colort template quite a bit. I wonder whether changing that template will tick off editors on other pages where it appears though. I’d edit the Colort template some myself, but changing templates which are used multiple places is always a bit of a touchy subject. –jacobolus (t) 01:34, 13 September 2010 (UTC)

┏━━━━━━━━━━━━┛
Since we’re apparently using fixed column widths here, we can probably actually get around the restriction on using colspan within a sortable table, by just stacking another table on top with a row of labels for multiple-column combined headings. Then we can put RGB (or perhaps sRGB), HSL, HSV column-spanning headings, and then simplify the column labels themselves to R, G, B, H, etc., and put the sorter widgets in-line next to those (and also get rid of the redundant links on every one of them). –jacobolus (t) 01:48, 13 September 2010 (UTC)

No nested tables please. — Christoph Päper 13:57, 19 September 2010 (UTC)

Also, it’s IMO a bad idea to get rid of the border around the color sample itself (by making it the border), because (1) the color seen by the human eye is dramatically affected by nearby and especially adjoining colors, and providing the little gray gap between each color reduces this effect a fair bit, and (2) not having the horizontal lines go all the way across reduces the visual coherence of the table. –jacobolus (t) 01:55, 13 September 2010 (UTC)

It’s a drawback, yes, but a minor one in my opinion. If you sort the table you get different adjoining colors. — Christoph Päper 13:57, 19 September 2010 (UTC)

Can you explain the benefit of making the color the border color instead of putting it in its own cell? I think the latter would be substantially better. –jacobolus (t) 17:54, 19 September 2010 (UTC)

Also, I’d get rid of the bold on the color names, though they could certainly remain TH elements. –jacobolus (t) 01:58, 13 September 2010 (UTC)

Let row headers be handled by sitewide or user stylesheets. — Christoph Päper 13:57, 19 September 2010 (UTC)

That's nonsense. 99.9% of users will get a worse design that way, and anyway most people probably want bold THs in most cases (i.e. for column headings) so the site-wide settings will be forced to be wrong for these color names. Basically, reasonable alternatives for this table are (1) use TD elements for the color names, or (2) use TH elements but make sure the text is left aligned and regular weight. I'm starting to favor (1) but I think (2) would be acceptable. Leaving the cells bold and horizontally centered is not acceptable. –jacobolus (t) 17:56, 19 September 2010 (UTC)

We should be able to calculate R, G, and B from the provided hex, and cut down on the things users need to enter for a color. For example, if we have the color #74DAF4, then its hex is 74DAF4, and we can do:

• red = {{hex2dec|{{padleft:|2|74DAF4}}}} → 116 ,
• green = {{#expr: {{hex2dec|{{padleft:|4|74DAF4}}}} mod {{hex2dec|100}} }} → 218,
• blue = {{#expr: {{hex2dec|74DAF4}} mod {{hex2dec|100}} }} → 244,
• etc.

And in fact, those would probably work best if we just made a templates for them, hexcolor2red, hexcolor2blue, hexcolor2green, etc. –jacobolus (t) 02:40, 13 September 2010 (UTC)

Okay, I’ve added these, {{hexcolor2red}}, {{hexcolor2green}}, {{hexcolor2blue}}, and so you do {{hexcolor2red|74DAF4}} and you get 116, etc. –jacobolus (t) 19:15, 13 September 2010 (UTC)

Using the intransparent “hex triplet” as base seems awful. I’d prefer percentages or floats, but even 8bit decimal integers are better than hex triplet. — Christoph Päper 13:57, 19 September 2010 (UTC)

Seems awful why? The point is to simplify writing: the colors are generally defined in terms of the hex triplet, and it's not like people are going to be reading the raw source to find out what the R, G, and B components are. –jacobolus (t) 17:59, 19 September 2010 (UTC)

I just noticed, there’s actually quite a problem with using the result of using the RGB2HSL templates, and then rounding the results from those. Because those are numbers rounded to 3 digits, rounding a second time leads to incorrect rounding in some cases (e.g., 0.0045… rounds to 0.005 which rounds to 0.01, instead of the proper 0.00) We should either use the 3-digit rounding provided by the template, or else make a new template that rounds to 2 digits of precision. –jacobolus (t) 02:50, 13 September 2010 (UTC)

I wouldn’t call that “quite a problem”. The templates could be improved, though. (New ones are not needed.) — Christoph Päper 13:57, 19 September 2010 (UTC)

How would the templates be improved then? By adding a "precision" input or so? –jacobolus (t) 18:01, 19 September 2010 (UTC)

Why is here the CSS3 color table? The X11 table in wiki code can be found here (since 2004).--Perhelion (talk) 20:38, 29 November 2010 (UTC)

Coloring of color values

The numeric values for colors mentioned in the text of the article are currently displayed in the color they describe. Should they be? This doesn't strike me as something that should occur in the main text of an encyclopedia article, and it certainly doesn't help readability. —71.196.83.53 (talk) 08:24, 2 November 2011 (UTC)

The article now uses {{color sample}} instead of {{color}} in prose. — Christoph Päper 12:09, 2 November 2011 (UTC)