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  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:


 * 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 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)


 * 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)


 * The original X11 colors were based on whatever gamma correction and primary colors were provided on the particular workstation. These varied dramatically from one machine to another. CSS colors are now specified to be sRGB. -jacobolus (t) 22:51, 27 December 2011 (UTC)

Table simplification
I've made the following changes to the table: 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)
 * 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 &mdash; 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 &lt;tt> tags (better browser support, I assume).
 * 4) Linked "Hex" and "RGB" in header (oh, and removed "#" from hex values in that column).


 * 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.  &mdash;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 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 &primes;s in there), also because it differs from HSL stronger than HSV. Y&prime;601 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  in Mediawiki. They may break sorting, though, but   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)
 * {| class="wikitable sortable" style="margin-left:3em"

! Color name !class="unsortable"| Sample ! RGB16 !title="red"| R10 !!title="green"|G10 !!title="blue"|B10 !title="red"| R (%) !!title="green"|G (%) !!title="blue"| B (%) !title="chroma"| C (%) !title="hue"| H (°) !!title="saturation"| S (%) !!title="lightness"| L (%) !title="hue"| H (°) !!title="saturation"| S (%) !!title="brightness or value"| B, V (%) !title="chroma"| C (%) !title="hue"| H (°) !!title="saturation"| S (%) !!title="intensity"| I (%) ! Alice Blue
 * rowspan="2" class="unsortable"|
 * rowspan="2" class="unsortable"|
 * rowspan="2" class="unsortable"|
 * rowspan="2" class="unsortable"|
 * rowspan="2" class="unsortable"|
 * rowspan="2" class="unsortable"|
 * bgcolor="#F0F8FF"|
 * #F0F8FF
 * 240 || 248 || 255
 * 94 || 97 || 100
 * 6
 * 208|| 3 || 97
 * 208|| 6 || 100
 * 5
 * 208|| 3 || 97
 * }
 * {| class="wikitable sortable" style="margin-left:3em"

! Color name !class="unsortable"| Sample ! RGB16 !title="red"| R (%) !!title="green"|G (%) !!title="blue"| B (%) !title="chroma, hover for differing chroma for HSI"| C (%) !title="hue, hover for differing hue in HSI"| H (°) !!title="saturation"| SL (%) !! SB (%) !! SI (%) !!title="lightness, hover for differing intensity in HSI"| L, I (%) !!title="brightness or value"| B, V (%) ! Alice Blue
 * bgcolor="#F0F8FF"|
 * #F0F8FF
 * title="240"| 94 ||title="248"| 97 ||title="255"| 100
 * title="5"| 6
 * title="="| 208|| 3 || 6 || 3 ||title="="| 97 || 100
 * }
 * {| class="wikitable sortable" style="margin-left:3em"

! Color name !class="unsortable"| Sample ! RGB16 !title="red"| R !!title="green"| G !!title="blue"| B !title="hue"| H !!title="saturation"| S !!title="lightness"| L / B !title="chroma"| C !title="hue"| H !!title="saturation"| S !!title="intensity"| I !title="chroma"| C ! Alice Blue
 * rowspan="2" class="unsortable"|
 * rowspan="2" class="unsortable"|
 * rowspan="2" class="unsortable"|
 * bgcolor="#F0F8FF"|
 * #F0F8FF
 * 240 94% || 248 97% || 255 100%
 * 208°|| 3% 6% || 97% 100%
 * 6%
 * 208°|| 3% || 97%
 * 5%
 * }
 * {| class="wikitable sortable" style="margin-left:3em"

! Color name !class="unsortable"| Sample ! RGB16 !title="red"| R !!title="green"| G !!title="blue"| B !title="hue"| H !!title="saturation"| S !!title="lightness"| L !title="chroma"| C ! Alice Blue
 * bgcolor="#F0F8FF"|
 * #F0F8FF
 * title="240"| 94% ||title="248"| 97% ||title="255"| 100%
 * title="HSI: 208°"| 208°||title="HSV: 6%, HSI: 3%"| 3% ||title="B/V: 100%, I: 97%"| 97%
 * title="HSI: 5%"| 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:
 * {| class="wikitable sortable"

! class="unsortable" style="width:4em"| ! Name ! class="unsortable" | 8-bit hex !title="sRGB red"|R !!title="sRGB green"| G !!title="sRGB blue"| B !title="HSL hue"| H !! title="HSL saturation"| S !! title="HSL lightness"| L
 * bgcolor="#F0F8FF"|
 * Alice Blue
 * #F0F8FF
 * title="240/255"| .941 ||title="248/255"| .973 ||title="255/255"| 1.000
 * 208.0° || 100.0% || 97.1%
 * }
 * Or perhaps (with some space to reduce the claustrophobic clutter):
 * {| class="wikitable sortable" style="text-align:right;"
 * {| class="wikitable sortable" style="text-align:right;"

! class="unsortable" style="width:4em; text-align:center;" title="color sample"| ! style="text-align:center" | Name ! class="unsortable" style="width:5em; text-align:center" | 8-bit hex !title="sRGB red" style="width:3em; text-align:center"|R !title="sRGB green" style="width:3em; text-align:center"| G !title="sRGB blue" style="width:3em; text-align:center"| B !title="HSL hue" style="width:3.5em; text-align:center"| H ! title="HSL saturation" style="width:3.5em; text-align:center"| S ! title="HSL lightness" style="width:3.5em; text-align:center"| L
 * bgcolor="#F0F8FF"|
 * style="text-align:left"| Alice Blue
 * style="text-align:center" | #F0F8FF
 * title="240/255"| .941 ||title="248/255"| .973 ||title="255/255"| 1.000
 * 208.0° || 100.0% || 97.1%
 * bgcolor="#FAEBD7"|
 * style="text-align:left"| Antique White
 * style="text-align:center" | #FAEBD7
 * title="250/255"| .980 ||title="235/255"| .922 ||title="215/255"| .843
 * 34.3° || 77.8% || 91.2%
 * bgcolor="#6495ED"|
 * style="text-align:left"| Cornflower
 * style="text-align:center" | #6495ED
 * title="100/255"| .392 ||title="149/255"| .584 ||title="237/255"| .929
 * 218.5° || 79.2% || 66.1%
 * }
 * title="100/255"| .392 ||title="149/255"| .584 ||title="237/255"| .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.
 * is probably better than just.
 * 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  but  . 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)
 * {| class="wikitable sortable collapsible"

!class="unsortable nocollapse"| !class="nocollapse"| Color ! RGB16 !title="red"| R !!title="green"|G !!title="blue"| B !title="chroma for HLC and HVC/HBC, hovering reveals chroma for HIC if different" class="collapsible"| C !title="hue, hovering reveals hue for HSI if different"| H !title="saturation for HSL"| SL !title="saturation for HSV/HSB" class="collapsible"| SV !title="saturation for HSI" class="collapsible"| SI !title="lightness for HSL and intensity (I) for HSI, hovering reveals intensity if different"| L !title="brightness (B) or value for HSB/HSV" class="collapsible"| V ! Alice Blue
 * bgcolor="#F0F8FF"|
 * bgcolor="#F0F8FF"|
 * #F0F8FF
 * title="240/255"| 94 ||title="248/255"| 97 ||title="255/255"| 100
 * title="5"| 6
 * title=""| 208° || 100 || 6 || 3 ||title="I=L"| 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 SL, SV, 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). SI 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 log10(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.
 * RGB16 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: 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)
 * red =  00  → 00 ,
 * green =   → ,
 * blue =   → ,
 * etc.
 * Okay, I’ve added these, hexcolor2red, hexcolor2green, hexcolor2blue, and so you do <tt><nowikI> </tt> and you get, 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)

LaserLemon vs LightGoldenrodYellow
Disregard my original comment. I see that "LightGoldenrodYellow" has been shortened to be "LightGoldenrod" in the table, and "LaserLemon" has been added to the table. Why? LaserLemon is not listed in the CSS level 3 spec. Sprokofiev (talk) 01:41, 11 May 2012 (UTC)

Removed the WhiteSmoke redirect
I removed the the following, as WhiteSmoke (Virus) is now a redlink. Tony Mach (talk) 21:36, 18 December 2013 (UTC)
 * You left it in a comment. I removed that, too. — Christoph Päper 11:54, 19 December 2013 (UTC)
 * Ah, OK! Tony Mach (talk) 12:54, 19 December 2013 (UTC)

Full Circle
The circle is almost complete X11 -> SVG + HTML colors -> CSS -> X11. Though the server no longer uses the rgb.txt file, but uses a builtin hardcoded database instead which hasn't yet been updated. Sounds like this will happen after 1.16. PaleAqua (talk) 03:39, 8 July 2014 (UTC)

abridged and rationalized
So who is abridging and rationalising? And hence isn't that self publishing and a POV? The article is X11 not W3C, so shouldn't the list BE THE LIST, THE X11 list. W3C references should be in w3C articles. If someone want a list of X11 colours supported by browsers, put that list in an article re browser colour support. — Preceding unsigned comment added by Mimarx (talk • contribs) 06:18, 20 August 2014 (UTC)
 * ✅ — Christoph Päper 10:40, 25 August 2014 (UTC)

Numbered variants

 * }

I wanted to include a sample table for the numbered variants (and did), when I discovered that with colort/color you can clearly see that they are the result of value or brightness variation in HSV/HSB notation in a constant manner. Hues are sometimes slightly off, though. I didn’t want to include another colort table, though, because these templates are expensive and the page is already loading slowly.

Has this been documented somewhere so we could reference that and rewrite the section? — Christoph Päper 10:17, 22 August 2014 (UTC)


 * See my links in the full circle section above which has links to the source definition files. The current version of X11 has them in rgb.txt at, though these days they are built into the server as seen at . PaleAqua (talk) 02:27, 24 August 2014 (UTC)
 * I was asking for a reference (i.e. reliable source) for the brightness values of color variants. The source code is quiet on that. — Christoph Päper 10:11, 25 August 2014 (UTC)
 * The variants got added by Paul Raveling . See also the README which talks about the 4 variants and raveling.txt which got merged into RGB text. PaleAqua (talk) 21:29, 25 August 2014 (UTC)
 * Ah, I see, thanks. It seems, though, that not all of raveling.txt made it into rgb.txt. — Christoph Päper 15:22, 26 August 2014 (UTC)
 * Yeah, and the variants got removed ( for performance reasons ) and later readded at the end. Also, some of the base colors got changed ( often somewhere between thomas.txt and raveling.txt ) wthout the variants being updated. I believe variants follow a highest RGB coordinate being 255, 238, 205, and then 139 from 1 to 4 and the rest of the RGB coordinates scaled relatively to the highest. PaleAqua (talk) 19:53, 26 August 2014 (UTC)


 * }

External links modified
Hello fellow Wikipedians,

I have just modified 2 one external links on X11 color names. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:
 * Added archive http://web.archive.org/web/20080502201401/http://cvsweb.xfree86.org:80/cvsweb/*checkout*/xc/programs/rgb/rgb.txt?rev=1.1 to http://cvsweb.xfree86.org/cvsweb/*checkout*/xc/programs/rgb/rgb.txt?rev=1.1
 * Added archive http://web.archive.org/web/20070928030522/http://cvsweb.xfree86.org/cvsweb/xc/programs/rgb/rgb.txt.diff?r1=1.2&r2=1.1 to http://cvsweb.xfree86.org/cvsweb/xc/programs/rgb/rgb.txt.diff?r1=1.2&r2=1.1

When you have finished reviewing my changes, please set the checked parameter below to true or failed to let others know (documentation at ).

Cheers.— InternetArchiveBot  (Report bug) 13:33, 21 July 2016 (UTC)

"Gainsboro"? "BurlyWood"? What are these things?
Where do these names originate? Equinox ◑ 18:29, 16 September 2017 (UTC)


 * The two you list were referenced from Sinclair Paints swatches by Paul Raveling, as were several others.
 * The rest of the names were mostly either referenced from Crayola crayons by John Thomas, or present in Jim Gettys' original version of the file (not known what he was referencing).
 * I refer you to Alex Sexton's seminar on the origin of X11 and web colour names for further information.
 * (For reference: original version, with Raveling edits, with Thomas edits, current version.)
 * -- HarJIT (talk) 20:28, 16 September 2017 (UTC)
 * (For reference: original version, with Raveling edits, with Thomas edits, current version.)
 * -- HarJIT (talk) 20:28, 16 September 2017 (UTC)
 * -- HarJIT (talk) 20:28, 16 September 2017 (UTC)
 * -- HarJIT (talk) 20:28, 16 September 2017 (UTC)

And «hazelnut colour»?
Why isn't the hazelnut colour in this article?

https://color.adobe.com/hazelnut-latte-color-theme-688428/ — Preceding unsigned comment added by Krotzpyn (talk • contribs) 19:13, 23 October 2018 (UTC)


 * Because it's not in rgb.txt and hence not an X11 colour name. This article is about the X11 colour names, not colour names per se. -- HarJIT (talk) 08:25, 24 October 2018 (UTC)

"Dark Grey" listed at Redirects for discussion
An editor has identified a potential problem with the redirect Dark Grey and has thus listed it for discussion. This discussion will occur at Redirects for discussion/Log/2022 March 14 until a consensus is reached, and readers of this page are welcome to contribute to the discussion. Q28 (talk) 05:30, 14 March 2022 (UTC)

Link to Gitgub is dead
The link to modern rgb.txt is not valid. Freedesktop project has moved to Gitlab 2A01:112F:430C:E00:7035:808E:3F3E:24FB (talk) 13:28, 18 November 2023 (UTC)

Mistake: Orange and Orange Red RGB Values
Orange     #FFA500 Orange Red #FF4500

show the same RGB value so one must be wrong. Perhaps someone could check all of the displayed RGB values against an installed rgb.txt file. Thanks for your efforts :o). GeneThomas2 (talk) 21:34, 20 November 2023 (UTC)
 * Whilst the R and B components are the same, the G components are different - A5 and 45 respectively. In which section do you see the same values for the two? -- Red rose64 &#x1f339; (talk) 14:25, 21 November 2023 (UTC)
 * My mistake. GeneThomas2 (talk) 00:56, 23 November 2023 (UTC)