Talk:List of colors/Archive 4
This is an archive of past discussions about List of colors. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page. |
Archive 1 | Archive 2 | Archive 3 | Archive 4 | Archive 5 |
Alabaster
I made some changes to alabaster which are documented here--S Philbrick(Talk) 17:08, 12 September 2018 (UTC)
Baby blue eyes issues
I have some concerns, spelled out here: Talk:Baby_blue#Baby_blue_eyes_issues--S Philbrick(Talk) 21:12, 17 September 2018 (UTC)
Colors for consideration of removal Type 2
Colors removed Type 2
|
---|
(For an explanation of the meaning of Type 2 See Talk:List_of_colors/Archive_3#New_approach_to_review_of_entries)
This completes my type 2 review through the letter "M". S Philbrick(Talk) 17:57, 7 October 2018 (UTC)
I just noticed that the problem with Maximum red is that the entry was linked to the wrong page. I've now corrected the page link.--S Philbrick(Talk) 14:12, 1 October 2018 (UTC) |
ToC
First and foremost, congrats to Sphilbrick, PaleAqua, Mark viking, and others for the extensive work being done on these articles – I'm sure it's widely appreciated.
I noticed that some of the ToC letter links were broken in List of colors: N–Z and fixed them, adding the following comment at the top of it and the other two alpha lists:
<!-- ******************* NOTE ******************** For ToC to work, the row for the first color starting with each letter MUST give the "id" parameter to {{Colort/1row}}. e.g. the first color starting with "Q": {{Colort/1row |name=[[Royal blue#Queen blue|Queen blue]] ... |id=Q }} Please keep entries in alphabetical order to make this more manageable. ******************* OOOO ******************** -->
Unless someone has a better solution, of course?
(P.S. I can't remember how to show a warning in edit mode only, which might be better than, or supplementary to, the comment)
—[AlanM1(talk)]— 23:12, 30 September 2018 (UTC)
- AlanM1, Huh. I had never noticed that before. I suspect I am the guilty party, as I have removed quite a few entries and hadn't paid attention to the parameters used to identify the beginning of each letter.
- I notice that the N – Z page uses an ID parameter, while A- F and G – M use a link target parameter. Not to mention that the N – Z page Uses a different template. There must be some historical reason but it's kind of a pain to have very different formats for the different lists. That said, there are more removals in progress — I'll try to pay attention if any are the initial entry in a new letterS Philbrick(Talk) 00:52, 1 October 2018 (UTC)
- I guess we have to discuss how anal we need to be. I think the advice in the first two articles must refer to the link target parameter, rather than id. Do you agree? S Philbrick(Talk) 01:13, 1 October 2018 (UTC)
- My bad. I should have checked to verify that they all used the same template, as they did until this point. Pinging @Ahecht. Meanwhile, I corrected the param and template names in the comment I added to A–F and G–M. —[AlanM1(talk)]— 02:37, 1 October 2018 (UTC)
- AlanM1, Thanks for making that change. I considered making it myself, but I was tired and that's not a good time to be doing substantive editing. Thanks for noticing. S Philbrick(Talk) 14:07, 1 October 2018 (UTC)
- @AlanM1: My edit was a quick-and-dirty solution to the fact that the mediawiki limit for template text had been exceeded. If you want to revert that edit and go back to the old format, feel free, but you would need to further subdivide the page first (probably into N–R and S–Z, based on the current distribution of colors for each letter). Also, if you want a warning when editing, as a template editor, you can place the {{editnotice}} template at Template:Editnotices/Page/List of colors: N–Z. --Ahecht (TALK
PAGE) 15:18, 1 October 2018 (UTC) - @AlanM1 and Sphilbrick: I created drafts of split pages using the original templates at Draft:List of colors: N–R and Draft:List of colors: S–Z. --Ahecht (TALK
PAGE) 16:05, 1 October 2018 (UTC)- Ahecht, Wow, those look great. However, having the split will create some small problems (which I assume we can overcome), but I'd like to revisit whether there is a template text limit (which I'll confess I sort of understand but not fully) Did you run into that limit with the current version : List of colors: N–Z? The reason I ask is before I started removing some of the unreferenced items, the article was at 172K, and it is now down to 103K. I'm puzzled about a couple of things. Why did neither of those versions run into the limit? I note that the size of the N—R draft is 24k, and the S–Z draft is 23K. Because of some minor duplication I would think the combined would be slightly less than 47K. Is it really the case that a 47K page runs into a limit but the 170 K page did not? I'm not trying to be difficult but I hope you understand why am puzzled.S Philbrick(Talk) 16:21, 1 October 2018 (UTC)
- My bad. I should have checked to verify that they all used the same template, as they did until this point. Pinging @Ahecht. Meanwhile, I corrected the param and template names in the comment I added to A–F and G–M. —[AlanM1(talk)]— 02:37, 1 October 2018 (UTC)
- I guess we have to discuss how anal we need to be. I think the advice in the first two articles must refer to the link target parameter, rather than id. Do you agree? S Philbrick(Talk) 01:13, 1 October 2018 (UTC)
- By the way, I do understand that the size limit is not solely a function of the byte-size of the article but is more likely to be related to the number of templates within the article, but it looks to me like your drafts are smaller and have no greater number of incorporated templates so I'm puzzled if the truly is a problem.--S Philbrick(Talk) 16:24, 1 October 2018 (UTC)
- @Sphilbrick: The template limit is a function of the amount of text provided by the templates themselves. My edit greatly increased the page size, but because those extra bytes were hardcoded and not from a template, it actually made the template size go down. You can view the size by previewing any page, scrolling to the very bottom (under the edit box), clicking the triangle next to "Parser profiling data", and looking at "post-expand include size". When I made the change, the "post-expand include size" was over 2,097,152 bytes (I don't know by how much, as the parser essentially gives up at that point), and my change essentially cut that in half to 1,078,280 bytes. It looks like your trimming did reduce the template size enough so that the original template will work without further splitting (post-expand include size is 1,324,143 bytes), so we can postpone the splitting discussion until the next time that the page expands to the levels it did earlier in the year. --Ahecht (TALK
PAGE) 18:15, 1 October 2018 (UTC)
- @Sphilbrick: The template limit is a function of the amount of text provided by the templates themselves. My edit greatly increased the page size, but because those extra bytes were hardcoded and not from a template, it actually made the template size go down. You can view the size by previewing any page, scrolling to the very bottom (under the edit box), clicking the triangle next to "Parser profiling data", and looking at "post-expand include size". When I made the change, the "post-expand include size" was over 2,097,152 bytes (I don't know by how much, as the parser essentially gives up at that point), and my change essentially cut that in half to 1,078,280 bytes. It looks like your trimming did reduce the template size enough so that the original template will work without further splitting (post-expand include size is 1,324,143 bytes), so we can postpone the splitting discussion until the next time that the page expands to the levels it did earlier in the year. --Ahecht (TALK
- By the way, I do understand that the size limit is not solely a function of the byte-size of the article but is more likely to be related to the number of templates within the article, but it looks to me like your drafts are smaller and have no greater number of incorporated templates so I'm puzzled if the truly is a problem.--S Philbrick(Talk) 16:24, 1 October 2018 (UTC)
I always consider it a good day when I learned something new and so today qualifies.
Thanks for explaining how to figure out the "Post-expand include size"
Following are the values for the three existing articles, and the two drafts you've created.
- (existing) A–F 1,104,194/2,097,152 bytes
- (existing) G–M 944,721/2,097,152 bytes
- (existing) N–Z 1,324,143/2,097,152 bytes
- Draft N–R 715,396/2,097,152 bytes
- Draft S–Z 676,574/2,097,152 bytes
Each example has two entries. My guess is that the first value is the size of the article in question, and the second is the current limit. Is that correct? If I'm right, then combining your to draft into a single article would be about 1.3 million the same as the existing article and comfortably within the limit.
If so, is this something you are willing to do? And if that's the case what you think should be the protocol? Do we need to propose it here and let it sit for a few days to get feedback? Or can we just do it? I was interest did in the issue of attribution for a few seconds but if one page is introduced as a complete rewrite as a new edit, all the attribution is preserved so I'm now thinking that is no problem.
I'll also note that if you think 1.3 is kind of large relative to 2.0 and could potentially lead to problems, that I've been working through some removals, and haven't yet gotten to the N–Z page for type II removals, so I suspect it will be smaller than currently. It is likely to grow over time but I think there will be enough room for a few years of growth.--S Philbrick(Talk) 18:39, 1 October 2018 (UTC)
- Forgot to ping @Ahecht:--S Philbrick(Talk) 22:09, 1 October 2018 (UTC)
- @Sphilbrick: Yes, the first number is the current size, and the number after the slash is the limit. I already went ahead and updated the full N-Z article with the original template, since the pruning of the list brought it comfortably below the 2MB limit (and I was esentially reverting my original BOLD edit, albeit with the most recent version of the list). I wouldn't be too concerned with 1.3MB being a large number, there are many articles that are far worse (most due to a combination of {{cite web}} and {{navbox}} templates). --Ahecht (TALK
PAGE) 14:32, 2 October 2018 (UTC)- Ahecht, Wow, thanks. I suspect you know that being helpful will occasionally lead to thanks, but will often result in more requests for help, as will be true in this case. First, let me repeat my thanks. I've been working with the three list articles for some time, and it has been much more painful dealing with the N–Z article, because of the different format. Having it now in a common format will make my next steps much easier.
- Now for my question. I had been meaning to bring this up after I finished the first three passes of trimming but I will bring this up now because I suspect you will have some useful insights.
- The templates essentially have three or four types of attributes — hex, RGB and HSL/HSV. Those options are basically redundant. Some purists argue that there is not a perfect conversion from one to another but it appears there are generally accepted conversion rules. One major problem with redundant conventions is that you could enter one set of values for RGB and then a hex representation that doesn't correspond. I don't know how often this happens but I've seen it happen. My guess is editors don't deliberately try to introduce errors, but if they find some color that has the wrong hex value, they might correct the hex value and not correct anything else. Or change the RGB and not the hex. The template doesn't require that all fields be filled out. In fact if you just enter the RGB values, the other values will be calculated for you. One thought I have is that we should strip it down to just the RGB values and allow the other values to calculate.
- I tried a brief experiment with a small set of values. Not surprisingly, the case with only the RGB values is slightly smaller than the case with all values prior to expansion, but to my surprise it was slightly larger after expansion. I didn't expect that, and it's not a lot and it's not a big deal. My bigger concern is that it might take more time to generate. In my small example, I got virtually identical load times but I am very concerned that I might of been fooled by a caching issue.
- With this as background, you have any thoughts on whether it would be a good idea to convert all of the so that they have only the RGB values entered in the template and then fill out the rest when the page is loaded? Do you think that would negatively affect load times?
- If you think that it would not be a good idea because of load times you have thoughts on how to test whether editors have changed one set of attributes and made them inconsistent with another set? The thought that occurs to me is to create a separate table containing only the RGB values, and then do a test to see if they match the existing tables, but this doesn't sound like an easy thing to do, so again I'm hoping that your expertise might help identify some better options. S Philbrick(Talk) 15:18, 2 October 2018 (UTC)
- The templates will only be regenerated when the page is edited or purged, so most people viewing it won't be effected by the calculation time since they'll be seeing a cached version. The only thing that affects load time for most readers is the actual size of the HTML page (which, as far as I can tell, is not reported by the mediawiki software), and that should be the same regardless of how many parameters are in the template. --Ahecht (TALK
PAGE) 15:40, 2 October 2018 (UTC)- Ahecht, Thanks. (I'll put off this decision, but this sounds like support for inclusion of only the RGB parameters.) S Philbrick(Talk) 16:08, 2 October 2018 (UTC)
- @Sphilbrick and Ahecht: IIRC, when I did some work on the pages some time ago, there was some concern about using the conversion template(s) (at least some of which I worked on) vs. "hard-coding" the HSL/HSV values, and the result was the latter. I think I ran a comparison and fixed discrepancies where I found them, but there have been many (likely un-verified) edits since then. However, Ahecht's explanation sounds correct in that the calc time shouldn't really matter since it only comes into play when the page (or templates it includes) are changed. There may have been a small problem, though, with inconsistent/incorrect rounding, though I might be remembering wrong or about something else. I'll try to look back at the history.
- Has there been consideration of using Wikidata as a repository of the color info? It seems that "lower-quality" edits (i.e. that might make the RGB, HSL/HSV, and CMYK values inconsistent) are probably less common with Wikidata, and it could also keep the lists consistent with the compact list and the individual linked articles. —[AlanM1(talk)]— 23:25, 2 October 2018 (UTC)
- AlanM1, Thanks for weighing in. I have made some minor edits to these articles for quite a number of years it's only recently that I decided to take a harder look. One of the things I did or at least tried to do was read the entire history of the talk page. I won't pretend I remember everything but your reference to rounding issues rings a bell. Regarding wiki data, I don't believe that's been discussed. That's worth discussing. S Philbrick(Talk) 23:54, 2 October 2018 (UTC)
- I don't have much of a vested interest in this page, but I am always loath to push this sort of data to Wikidata, as vandalism there is more likely to go undetected (it won't show up on the watchlists of people watching this page, for example). --Ahecht (TALK
PAGE) 13:54, 3 October 2018 (UTC)- Ahecht, Fair point, let's hold that thought for now S Philbrick(Talk) 16:01, 3 October 2018 (UTC)
- Ahecht, Thanks. (I'll put off this decision, but this sounds like support for inclusion of only the RGB parameters.) S Philbrick(Talk) 16:08, 2 October 2018 (UTC)
- The templates will only be regenerated when the page is edited or purged, so most people viewing it won't be effected by the calculation time since they'll be seeing a cached version. The only thing that affects load time for most readers is the actual size of the HTML page (which, as far as I can tell, is not reported by the mediawiki software), and that should be the same regardless of how many parameters are in the template. --Ahecht (TALK
- @Sphilbrick: Yes, the first number is the current size, and the number after the slash is the limit. I already went ahead and updated the full N-Z article with the original template, since the pruning of the list brought it comfortably below the 2MB limit (and I was esentially reverting my original BOLD edit, albeit with the most recent version of the list). I wouldn't be too concerned with 1.3MB being a large number, there are many articles that are far worse (most due to a combination of {{cite web}} and {{navbox}} templates). --Ahecht (TALK
Colors for consideration of removal Type 2 (N—Z)
Color removals Type 2 (N—Z)
|
---|
(For an explanation of the meaning of Type 2 See Talk:List_of_colors/Archive_3#New_approach_to_review_of_entries)
|
Future initiatives
Thanks to anyone who has weighed in with helpful comments and suggestions. Special thanks to @AlanM1: and @Ahecht:, Alan who noticed the special way that the table of contents of these articles were constructed and cleaned up my mess, and Ahecht who did some massive edits relating to templates which were outside of my bailiwick.
The three main list articles are now considerably improved.
I initially started this by going after some low hanging fruit, identifying some entries which I felt justified removal from the list. I grouped these into three types, with type 1 being the easiest to address and type 3 being the most challenging. I've completed my personal review of types 1 and 2, and will finish the removal of type 2 entries after a week is passed since including in the list. That logically means I should start on type 3, and I may but I confess I'm a little burnt out so I am may address those much more slowly.
That said, I think there's much to do to improve these articles. I'm going to outline some of my thoughts. I'm hoping for input from others, because, despite my involvement, I've read enough of these articles to realize I'm far from a color expert. The second reason for looking for input is that the first initiative could be carried out independently of the following issues but some of the following issues are not independent so we may have to think through the right sequence to carry them out if in fact they should be carried out.
Redundant parameters
The main template used is {{Colort/Color}} This template accepts parameters for three color spaces, one of which has two representations:
Color Model | Representation |
sRGB | raw RGB values |
sRGB | Hex triplet |
HSL | raw parameters |
HSV | raw parameters |
There is redundancy among these parameters. Given an RGB triplet, there is a unique associated hex value, and a unique associated HSL triplet as well as an HSV triplet (I think some color experts might quibble with part of this point.) The way the template is constructed, it requires the RGB triplet. It will use those to display the color swatch and, if the others are not present, it will generate them. However, if all parameters are given the color swatch will be dependent on the RGB triplet only. If the other values are inconsistent, no error message will occur. This leaves open the possibility, which has happened, that a good faith editor modifies some but not all of the parameters, leaving an inconsistency.
I see two broad options (although there may be others). One option is to ensure that the template is only populated with the RGB triplet, which would require that the template generate the other parameters. This would always ensure consistency. I have some concerns about whether this would create a performance hit. I did some very crude tests which did not uncover a performance hit but I'm not sure they were rigorously carried out. An argument in favor of this option is that the parameters would always be consistent. One problem with this approach is that the template does accept the other parameters so if we wanted to go this route we might look into modifying the template. Second option is to make no change to the way we fill out the template but create some (ideally automated) process that would check on a regular basis (maybe quarterly) to determine whether editors have input inconsistent parameters. Such a process might generate a report on the talk page which could be manually fixed.
Output convention
The input to the template is the raw RGB parameters. However, the output is a conversion to percentages. I checked the history of this article and I can see that this change was made a number of years ago. It initially had the output as raw RGB values and someone converted over to percentages. I thought such a change would be accompanied by an extensive discussion, but I did not see such a discussion. My cursory review of the Internet suggests that both representations exists, but raw RGB parameters are far more pervasive. I'm open to arguments that the conversion to percentages produces some value but I'm not seeing it and would like to propose that we convert back to raw RGB parameters.
Range issue
The template requires precise values, and leaves the impression that, for any particular color name, there is an exact set of parameters describing that color. There are several problems with this assumption. In some cases, there may be an intention of a precise color (think Crayola crayons), but the manufacturer did not specify the exact parameters, so someone has estimated the parameters. There are also situations (think "red") where there may be a set of exact parameters agreed upon by everyone for the canonical representation, but the term is used for a variety of hues. If someone says this ball is red and that tomato is red they aren't necessarily saying that those two items have exactly the same color. There are other issues related to these but I'll stop here and simply note that the nature of these lists are to give a misleading representation that a particular color name has an exact set of parameters. I struggled with how to address this. My current thoughts are to add a parameter to the template which might indicate whether the parameters should be considered:
- exact and known
- exact but estimated
- exact but ranges of value are also associated with the same name
- representative of a narrow range of colors
- representative of a broad range of colors
We would have to do some work to refine this list, but I'm thinking that we might assign a letter or number or symbol to each of these concepts. Fully fleshing out details on everything but the first should be carried out in the linked article not in the list article (I think)
Associated articles
I have focused my attention on the three main list articles:
but I noticed there are other articles, e.g.:
Which I believe contain the same information as the three main list articles, but organized in a different way. I haven't done any research on how those articles are kept up-to-date when changes to the three main list articles occur. This seems like a job for an automated or semi automated process, but that's getting out of my areas of expertise.
Cleanup
I note these articles have some cleanup templates at the top. I haven't address these but this ought to be something we work on at some time--S Philbrick(Talk) 16:10, 10 October 2018 (UTC)
Flavescent
- Flavescent Whether or not it's a formal rule, our practice is to include items on the list that already exist as a section or a standalone article. We don't add items to this list that are not discussed elsewhere in Wikipedia. This color is an exception and probably can be deleted for that reason alone. I do note that it has a reference, but note that this color was added in 2009 and the link site did not mention the color name until 4 Nov 2015. That strongly suggests that the site picked up the name from Wikipedia and thus would be circular referencing.Merriam-Webster defines it as a term that is color related but doesn't hint at a well enough defined color to provide color attributes.--S Philbrick(Talk) 15:18, 3 November 2018 (UTC)
Type 3 colors
(For an explanation of the types, see Talk:List_of_colors/Archive_3#New_approach_to_review_of_entries)
- Bright Pink - see Talk:Shades_of_pink#Bright_pink (Arguably, this is a type 2 because the link to the article contains no sources but it has had sources at various times in its history, so I'm calling it a type 3.)
- Cal Poly Pomona green See Talk:Shades_of_green#Cal_Poly_Pomona_green
- Dark medium gray See Talk:Shades_of_gray#Dark_medium_gray
- Deep fuchsia see Talk:Fuchsia_(color)#Deep_fuchsia
- Fashion fuchsia See Talk:Fuchsia_(color)#Fashion_fuchsia
--S Philbrick(Talk) 14:58, 3 November 2018 (UTC)
- All Removed.--S Philbrick(Talk) 18:00, 21 November 2018 (UTC)
Cyan gold silver Leo3472 (talk) 10:39, 9 April 2020 (UTC)
- Leo3472, I'm not following your point. Assuming you are identifying three potential problems, I looked at the first two, both of which are sourced to X11_color_names which seems adequately sourced. S Philbrick(Talk) 13:05, 22 April 2020 (UTC)
Silly Scents
The sixteen Crayola silly scents colors are present in this list despite the fact that they have corresponding normal color names which are also in this list. For example "Alien Armpit" is just a silly name Crayola used for the color "Yellow Green", which also exists in this list. Is it appropriate to remove all of the silly scent colors from this list, since they appear to exist only as ridiculous names for standard colors? Altay8 (talk) 20:38, 29 March 2019 (UTC)
- Altay8, I have mixed feelings about this. On the one hand, it is arguably a name for a scent not a color and doesn't belong. on the other hand, I can imagine someone running across a reference to one of these names, and wanting to check Wikipedia to see what it is. We provide a service to the world (admittedly, an extremely minor service) by helping to answer their question. I just checked one and it appears to have been removed. I slightly lead toward leaving
the menthem in but not strongly enough to actually restore them. I'm also concerned that my argument could be used in other situations where I might feel differently, so I'm waiting in with an usually wishy-washy response. S Philbrick(Talk) 23:53, 18 January 2020 (UTC) - Sphilbrick, I think it would be ideal (although unrealistic) to have a one-to-one mapping between color codes and color names. That's my expectation from an authoritative list of colors; it should answer both "what does this color name look like" and "what's the most appropriate name for this color". Most people I've talked to scoff at the idea that "Sasquatch Socks" is the name of a color but would grant that "Isabelline" is a color even if they don't know what it looks like. I've been annoyed about the fact that "Magenta" and "Fuchsia" both refer to #FF00FF and are both well-established names of colors, but I think we can still strive for authoritative color names even if there are a few exceptional cases. As I continue to slowly clean up this page I intend to remove the Silly Scents (unless there's strong opposition) as I come across them in their respective sections. Altay8 (talk) 15:28, 22 January 2020 (UTC)
- Altay8, I understand the desire of having a one to one relationship. However, as you so aptly pointed out, there are real-world examples where two different names are used for the exact same color. While you might wish to construct the world differently, I am sure you accept that our function is to describe the world that is, not the world that we might design (where there is an exact one to one relationship between the name of a color and the color itself).
- I fully accept that "Sasquatch Socks" is not the name of the color, but it is the name of a scent that is associated with a crayon with a specific color. I have argued that we provide a service to our reader, who might be searching on the Internet for "Sasquatch Socks", because it came up in some place, and they didn't know what it meant. Directing them to the article explaining that there is a Crayola crayon with a particular color and that crayon happens to have a scent described as "Sasquatch Socks", might give the reader exactly the information they were searching to find.
- However, there are hills to die on and this is not one I choose to die on. I think our articles on colors provide a tremendous service for readers, and I've been discouraged to see how few editors I willing to help keep them cleaned up. You apparently are willing to help, and I'd like to encourage that, so if you feel strongly about removing the scents as part of working on overall improvement of these articles, I won't stand in your way. S Philbrick(Talk) 16:03, 22 January 2020 (UTC)
Since there's a pending revision attempting to add back the Silly Scents, it seems worth bringing up the point here that I mentioned over on the other talk page. None of these Crayola colors are properly sourced. They all cite this page as their source, which provides no hex codes directly and uses speckles and gradients to convey shimmering. It does not appear to be making authoritative claims that the hex codes that were used for the swatches are exact, but rather providing a visual approximation for the colors their markers will produce. As such, I don't think any of the colors using that webpage as their sole source deserve to be in this list, especially not the Silly Scents which are duplicates of other Crayola colors. And to address the remark in the pending revision directly, Big Foot Feet is a duplicate of Tan as shown in this table. Altay8 (talk) 03:25, 3 April 2020 (UTC)
Some errors?
Why do middle blue and middle yellow red have HSV saturation and value over 100%? And why do they link to the nonexistent https://wiki.riteme.site/wiki/Shades_of_red#Munsell_Crayola,_1926%E2%80%931944? Was https://wiki.riteme.site/wiki/History_of_Crayola_crayons#Munsell_Crayola,_1926%E2%80%931944 intended? Also, I think white, silver and silver chalice shouldn't have hues. Oscar Cunningham (talk) 11:12, 6 November 2019 (UTC)
- Oscar Cunningham, It looks like you fixed this yourself, thanks. S Philbrick(Talk) 13:10, 22 April 2020 (UTC)
Source column
This page seems like it would benefit from a source column. There's already a source field in the color infobox template, and it would be incredibly useful to be able to sort these colors by their source. An added benefit would be that it would make the color names more consistent, since we're already placing the source name in parentheses next to duplicate color names in an effort to disambiguate them. Altay8 (talk) 22:26, 14 April 2020 (UTC)
- Altay8, Interesting thought, though a bit of work. I naively thought I could just add a column, so I created User:Sphilbrick/List_of_colors:_A–F_with_sources to see how this might work, but I see that it isn't a simple table, it is created with a template. I've done some very light template editing,not sure this is in my bailiwick. S Philbrick(Talk) 13:39, 22 April 2020 (UTC)
- Update Help talk:Template#Adding a source column to a template--S Philbrick(Talk) 18:23, 27 April 2020 (UTC)
Nomination of List of colors: N–R for deletion
The article will be discussed at Wikipedia:Articles for deletion/List of colors: N–R until a consensus is reached, and anyone, including you, is welcome to contribute to the discussion. The nomination will explain the policies and guidelines which are of concern. The discussion focuses on high-quality evidence and our policies and guidelines.
Users may edit the article during the discussion, including to improve the article to address concerns raised in the discussion. However, do not remove the article-for-deletion notice from the top of the article.
-DePiep (talk) 20:42, 12 January 2021 (UTC)
Kombu green
List of colors: G–M has kombu green. Originally the Chartreuse page sourced the color's name to the Pantone website; the ref told the reader to type the phrase in the search bar. Using the search bar at the Pantone site directs one to a retail purchase, as does replacing the name with the hex code #354230. Also part of the (now removed) Chartreuse entry included the Pantone code "#19-0417 TPX". Searching for this via Google finds a Pantone page titled "PANTONE 19-0417 TPG: Kombu Green"[1]. This Pantone page gives the hex code as 434D40, and the colors as RBG 67 77 64. I would change this information in the list, leaving the ref attached to the color name, but the Pantone page lacks all the other information listed: hue, saturation/light, and saturation/value. I found no other reliable sources for this color's name. Should it be removed from the list as it has been removed from chartreuse? 76.119.40.77 (talk) 04:07, 29 March 2021 (UTC)
References
- ^ "PANTONE 19-0417 TPG: Kombu Green". Pantone. Retrieved March 29, 2021.
A-F and N-Z are broken
Lists A-F and N-Z appear to be broken. I'd fix it, but I have no idea how to. Could someone here make the lists viewable again? IlSoupylI (talk) 12:08, 6 May 2021 (UTC)
- I have fixed it by reverting a series of edits by PK2. They passed too much through Template:Colort, e.g. around 45 kB of template calls after [1]. At the time it placed the lists in Category:Pages where template include size is exceeded, stopping tranclusions without rendering any part of the color tables. PrimeHunter (talk) 13:27, 6 May 2021 (UTC)
- For reference, that category has been renamed to Category:Pages where post-expand include size is exceeded. – Fayenatic London 20:41, 23 May 2021 (UTC)
Eigengrau and the general process for removing entries
A brand-new editor attempted to remove the entry for Eigengrau. This was a good faith edit, and ultimately, the editor may have a decent case on its merits, but our established process was not followed. For those of you not familiar with the history of this article, a brief bit of background. Over the years, there has been some discussion and back-and-forth about the appropriate inclusion criteria for this article. There was a time when it attracted a lot of cruft, some of it well-meaning, some as jokes, and some as pure vandalism. Oddly, despite the fact that it is labeled as a list article and has been for years, it took some time for a consensus to develop that it ought to be treated, well, as a list article. Generally speaking, list articles are like any other article in terms of application of guidelines but there is special treatment for a list article. The entries do not have to be referenced in the list article (although that does happen in some list articles), but each entry should be a blue link to another article, which itself needs to be adequately referenced. If an entry is not linked or is a red link it can be summarily removed from the list article. If it is a blue link, the linked article can be reviewed. If that article appears to be inadequately referenced, the first step is to cure that problem, either identifying adequate references or if that becomes impossible, propose that article for deletion. In the same way that Wikipedia is not a primary or even secondary document, it is a tertiary document relying on published reliable sources, a list article in Wikipedia "follows" information presented in other articles.
In this specific case, it means that if an editor has issues with the referencing for Eigengrau, the first step is to address the referencing at that article, and once that is resolved, the list article can follow suit. In this particular case, the editor reviewed the linked article and its talk page, and reach the personal opinion that the referencing was inadequate but rather than engaging in a discussion at that article, decided to remove the entry from the list. That's not the way the consensus for removal has developed.
I think the editor has some legitimate concerns, and I invite anyone reading this to weigh-in at Talk:Eigengrau, to determine how that article should be written.
As an important aside, this article highlights an issue that's arisen in the past and hasn't been, as far as I know, satisfactorily resolved. What if there is sufficient sourcing and publish reliable sources to justify that a particular word does constitute the name of a color, but the sourcing for the color attributes is not sufficient to tie down the exact attributes of the color. Conceptually, one might argue that this means the name of the color deserves to be in the list not the color attributes. We don't really have a process for doing that, so we might debate that separately. That's a discussion that deserves to be on this page.--S Philbrick(Talk) 14:06, 7 May 2021 (UTC)
- It's as simple as this: there are no reliable sources for the colour value of eigengrau. I reviewed the article in question, found no reliable sources for the colour value, made mention of this on the article's talk page (and determined who came up with the colour value — a random user who is not a reliable source), and then later sought to purge this colour value from being claimed as legitimate on Wikipedia, since there are no, I repeat, there are no reliable sources for the colour value of eigengrau. All of this you confirmed you read, User:Sphilbrick. Are you claiming that there is a reliable source for the colour value? If so, please specify it. Otherwise, what is the point of this dispute? SchizoidNightmares (talk) 18:49, 7 May 2021 (UTC)
- SchizoidNightmares, I thought I laid out the point of this dispute fairly clearly. I'll try again. There is a process for removing entries from this list. An entry can be removed if it is a red link or not linked to any article about a color. If it links to a discussion about a color, and there is question about whether that article or section of article should be retained, that's a discussion for the underlying article and should be resolved first. There is an interesting question worth discussing here — what happens if there are reliable sources for the name of a color but not for the color attributes? I don't believe that's been definitively resolved and is worth discussing. Feel free to discuss. If you don't feel that the sources for eigengrau support the existence of the name of the color, please take it up at that article's talk page. If you think the name of the color is adequately supported, but the color attributes units are not, get a consensus at that article and then contribute to a discussion here about what we should do in such situations. Finally, there appears to be an open question about the best name for the color that should be resolved at the talk page of the underlying article. Any further questions? Anything still not clear? S Philbrick(Talk) 14:47, 8 May 2021 (UTC)
- User:Sphilbrick. The thing is, the only user objecting to the removal of the fictitious colour value, which I have already brought it up on the respective talk page, is you. This entire thing seems to be more about religiously adhering to the "process" than actually ensuring the colour values listed are not just made up by users. Even taking "process" into account, you cited an optional guideline, which you yourself violated by reverting my removal twice before trying to reach a "consensus" on the issue. I had only reverted your contribution once, which is a far cry from the "3RR," of which is not optional. This whole thing is unnecessarily protracted and could easily be solved by the question: are there any reliable sources for the colour value? No? Then it shouldn't be included on Wikipedia. I have exhausted all reasonable attempts to reason with you (taking into account the triviality of this whole dispute), you circularly go back to the need for "consensus," and refuse to provide any reliable sources for the colour value. I'll leave this problem up to others as frankly it is not worth the effort. As for whether colours that have no values should be listed in the list... Well ask yourself this: are impossible colours that are cited on Wikipedia included in the list? No? Why? Because they have no colour values. You can't see them or visualize them, or use them in any practical way. Well, I think that answers your question already. It's just all so very tiresome. SchizoidNightmares (talk) 18:48, 8 May 2021 (UTC)
- SchizoidNightmares, Sorry I missed this, it was not my intent to ignore it I just didn't notice it until now. I am more sympathetic than you might realize. I think the arguments for inclusion are weak and I would not be surprised if a well-thought-out discussion at that page might conclude that the article about the "color" should survive but given there are no solid references for the exact shading, it doesn't deserve an entry in this list.
- I did encourage you to bring this up at Talk:Eigengrau, but I see that rather than opening a discussion, you unilaterally removed the content. I'm sorry you find the process so tiresome, but hundreds of thousands of contributors to Wikipedia have developed some processes that on balance work pretty well. I gave you a suggestion, you chose to ignore it, so let's just let it go. S Philbrick(Talk) 00:06, 2 July 2021 (UTC)
- I am pleased Eigengrau was included in this list, it was an interesting discovery. If the colour value is removed, please at least keep the entry! 2.108.159.8 (talk) 23:41, 29 December 2021 (UTC)
- User:Sphilbrick. The thing is, the only user objecting to the removal of the fictitious colour value, which I have already brought it up on the respective talk page, is you. This entire thing seems to be more about religiously adhering to the "process" than actually ensuring the colour values listed are not just made up by users. Even taking "process" into account, you cited an optional guideline, which you yourself violated by reverting my removal twice before trying to reach a "consensus" on the issue. I had only reverted your contribution once, which is a far cry from the "3RR," of which is not optional. This whole thing is unnecessarily protracted and could easily be solved by the question: are there any reliable sources for the colour value? No? Then it shouldn't be included on Wikipedia. I have exhausted all reasonable attempts to reason with you (taking into account the triviality of this whole dispute), you circularly go back to the need for "consensus," and refuse to provide any reliable sources for the colour value. I'll leave this problem up to others as frankly it is not worth the effort. As for whether colours that have no values should be listed in the list... Well ask yourself this: are impossible colours that are cited on Wikipedia included in the list? No? Why? Because they have no colour values. You can't see them or visualize them, or use them in any practical way. Well, I think that answers your question already. It's just all so very tiresome. SchizoidNightmares (talk) 18:48, 8 May 2021 (UTC)
- SchizoidNightmares, I thought I laid out the point of this dispute fairly clearly. I'll try again. There is a process for removing entries from this list. An entry can be removed if it is a red link or not linked to any article about a color. If it links to a discussion about a color, and there is question about whether that article or section of article should be retained, that's a discussion for the underlying article and should be resolved first. There is an interesting question worth discussing here — what happens if there are reliable sources for the name of a color but not for the color attributes? I don't believe that's been definitively resolved and is worth discussing. Feel free to discuss. If you don't feel that the sources for eigengrau support the existence of the name of the color, please take it up at that article's talk page. If you think the name of the color is adequately supported, but the color attributes units are not, get a consensus at that article and then contribute to a discussion here about what we should do in such situations. Finally, there appears to be an open question about the best name for the color that should be resolved at the talk page of the underlying article. Any further questions? Anything still not clear? S Philbrick(Talk) 14:47, 8 May 2021 (UTC)
Zomp
This wiki article has Zomp listed as a shade of spring green, however this contradicts this article https://wiki.riteme.site/wiki/Shades_of_cyan#Zomp whereby Zomp is actually a shade of Cyan. Wondering if it's possible to get this confirmed? Amurphy79 (talk) 11:52, 17 May 2021 (UTC)
Incomplete
I am new. I counted the number of colors in the lists using ctrl + F, # and °. There are 337, 237 and 399 colors in A-F, G-M and N-Z and there are 1268 colors in the compact list (counted by searching for colort and colorshort in the source). If I am wrong please correct me. I found that there should be 295 colors that are in the compact list but not in the 3 lists. I do not know how to get those colors but it seems that they exist. Existent human being (talk) 11:39, 27 June 2021 (UTC)
- Existent human being, Unfortunately, there are fewer editors active in this area than the subject deserves. I worked on trying to ensure some consistency between the list of articles and the linked articles, but I haven't had the bandwidth to see whether the lists and a compact list are in sync. If you have any interest in putting together a comparison it would be appreciated. That said, I'll emphasize that my involvement in these articles goes in cycles I am in an off cycle at the moment, other than reverting drive-by vandalism. S Philbrick(Talk) 00:10, 2 July 2021 (UTC)
- Strawberry Blonde's hex was not capitalized. Gunmetal's hex is not capitalized. International Klein Blue's hex is not capitalized (I found these minor errors accidentally while trying to compare the lists). Here is the full comparison (of names only). Though, it has some errors, for example it detected "Ash grey" and "Ash gray" as two distinct colors while they aren't really different. Existent human being (talk) 11:55, 2 July 2021 (UTC)
Strawberry blond
I think we have a rough consensus that entries in this list need to have a link to an article or section of an article discussing the color. What is less settled is what to do in the case an article exists, but does not have reliable sources supporting the hex codes.
Wikipedia links strawberry blond to a section in blond which simply consists of an entry in a list of hair colors. That entry has a reference, but it is not a reliable source, it is a link to a Wiktionary entry. That entry has a hex code, but the code is not sourced, and doesn’t match the code used in the list article.
Of course, when a color is inadequately sourced, the ideal solution is to fix the sourcing. However, when I search for the color name, I find a fair bit of variation. While I didn’t complete an exhaustive search, I didn’t find two sources citing the same hex code.
The table below identifies the color in the Wikipedia list, the color in the Wiktionary entry, and examples of the color in various sites, each different.
How should we proceed?--S Philbrick(Talk) 19:15, 5 July 2021 (UTC)
Location | Hex code | Name | |
---|---|---|---|
Wikipedia list | #FF9361 | Strawberry blond | |
Wiktionary[1] | #F1BA8D | Strawberry blond | |
encycolorpedia[2] | #F7E8D4 | Devoe Paint Strawberry Blonde | |
colourlovers[3] | #EDB94B | strawberry blonde | |
colourlovers[4] | #EEA185 | Strawberry Blonde | |
encycolorpedia[5] | #FFDADC | California Paints DE 5107 - Strawberry Blonde | |
Dunn-Edwards Strawberry Blonde / 2893 |
References
- ^ "strawberry blonde - Wiktionary". en.wiktionary.org. Retrieved 2021-07-05.
- ^ "Devoe Paint Strawberry Blonde / 00YY 83/069 / #f7e8d4 Hex Color Code". encycolorpedia.com. Retrieved 2021-07-05.
- ^ "Color / EDB94B / strawberry blonde :: COLOURlovers". www.colourlovers.com. Retrieved 2021-07-05.
- ^ "Color / EEA185 / Strawberry Blonde :: COLOURlovers". www.colourlovers.com. Retrieved 2021-07-05.
- ^ "#ffdadc Hex Color Code". encycolorpedia.com. Retrieved 2021-07-05.
Source column
Most of the colors in this table come from just a few sources, such as Crayola, X11/Web, Maerz and Paul, color wheel. These sources frequently conflict in their definitions, such that it's necessary to disambiguate with a parenthetical note next to the color name. There are seven different definitions for blue, one from each source. Instead of using the messy system of parenthetical notes I propose we add a column to the table for the source of the color. This will allow us to clean up some of the color names, allow users to sort by source, and make it much more obvious when an unsourced color is added to the table.
I'm thinking something like this:
Name | Hex (RGB) |
Red (RGB) |
Green (RGB) |
Blue (RGB) |
Hue (HSL/HSV) |
Satur. (HSL) |
Light (HSL) |
Satur. (HSV) |
Value (HSV) |
Source |
---|---|---|---|---|---|---|---|---|---|---|
Blue | #0000FF | 0% | 0% | 100% | 240° | 100% | 50% | 100% | 100% | RGB color model |
Blue | #1F75FE | 12% | 46% | 100% | 217° | 99% | 56% | 88% | 100% | Crayola |
Blue | #0093AF | 0% | 58% | 69% | 190° | 100% | 34% | 100% | 69% | Munsell color system |
Blue | #0087BD | 0% | 53% | 74% | 197° | 100% | 37% | 100% | 74% | Natural Color System |
Blue | #0018A8 | 0% | 9% | 66% | 231° | 100% | 33% | 100% | 66% | Pantone |
Blue | #333399 | 20% | 20% | 60% | 240° | 50% | 40% | 67% | 60% | CMYK color model |
Blue | #0247FE | 1% | 28% | 100% | 224° | 99% | 50% | 99% | 100% | RYB color model |
Altay8 (talk) 22:53, 19 July 2022 (UTC)
- But you never updated the G-M and N-Z articles, so could you do that? 24.14.193.228 (talk) 18:34, 6 July 2023 (UTC)
- Hi Altay8! I just want to let you know that Blue in the RYB color model would be the same volume of blue as it is in the RGB color model. In this case, it is pure Blue and is Hex Code #0000FF (Not #0247FE as you have it), especially if the Hexadecimal System is going by the RYB color model.
- If you want me to compare between the RYB and RGB color systems using the Hexadecimal Codes, then I can do so! Craig Lungren (talk) 21:54, 26 April 2024 (UTC)