The idea was to create a tool to sort the named CSS colors in a way that it shows related colors together. So, next time I can't decide between a few CSS colors, I can just check them here side by side.
I've created this tool last summer, but I hadn't shared it here back then. It's a PWA that I made with pure JS.
Normally I'd say "the feature request should still be made on GitHub even if it's not code" except for the fact that this is a Show HN which seems just as valid of a receiving area.
Is that really how people are perceiving smiley faces nowadays? I make rather extensive use of smiley faces and smiling emoji and I would hate for them to be received in that manner, rather than what I intend, which is an authentic smile.
> Is that really how people are perceiving smiley faces nowadays?
No. In this case there’s nothing earnest about the smiley face, which is why it makes the comment seem rude. Just like a genuine smile is different to Dolores Umbridge’s smile.
Some people will find malice whenever possible, even in smiling.
I read the comment as an attempt to redirect the person from begging to helping, in as nice a way as possible.
But if someone has a bone to pick with people who are rude about suggestions, they're going to read ill intent into the whole message, smiley or otherwise.
I'm not aware of an equivalent tool for Pantone colors. But it can be created using this very tool with a table of pantone colors instead of a table of named css colors that it uses now.
This is really cool. The whole experience is slick!
One thing I noticed is that some colors appear brighter, but are further down on the Saturation scale. For example, mediumturquoise and turquoise are shown as being less saturated than cyan, though cyan doesn't mix in any gray. Are these sorted by the sums of their RGB values? I'm also not too well versed in color theory, so I could be missing or misunderstanding something too.
I think there's a misunderstanding there. Mediumturquoise and turquoise are both located above cyan, which means they are brighter as the vertical axis is the lightness.
Also, to answer your question, colors are sorted by their hue, saturation and lightness values. So, it's actually a 3D color visualizer, where one dimension (hue) is reduced into just a slider at the top, and the other two dimensions are represented in a 2D grid.
"Sienna" is an extremely ambiguous color already. Image search for "sienna color" and you'll get a huge range of browns, reds and oranges.
"Burn sienna" seems even more varied. Here's are four different color-oriented websites, with a dark earthy orange from Colorlex [1], a light salmon from Canva [2], a light brown from Benjamin Moore [3] and a dark brown from Atelieracrylic [4].
Worth watching the Technology Connection video on the colour Brown [1]. It's a strange colour that only really exists when placed in the context of other colours, not something that can really be produced by a pure RGB light source, which explains why the CSS Brown colour looks red.
So they take a word "whitespace" which needs no hyphen and jam one in. Then they take two completely distinct words "no wrap" and jam them together with no separator. And then you have to remember both of these on the same rule.
As far as I can tell, both are common, but “white space” is more common as a synonym to negative space, and “whitespace” is more common to refer to the characters. If so, the “white-space” property controls whitespace, not white space.
Also, the entire semantics are a bit strange. When I'm deciding whether I want text to line wrap, I don't really think about whether the whitespace should wrap. Yes, whitespace is somewhat relevant to the topic, since that's one option of where to break lines in order to line wrap, but I still think of it as the entire text that is line wrapping.
Oh, and don't forget that there is in fact a word-wrap property, which is a much better name for the previous behavior, but in fact only customizes how the line-breaking algorithm determines which words can be broken apart.
The naming is far from great, but there is a method to the madness. Here's a talk I did a while back on how various line breaking things fit together: https://cssday.nl/2019/speakers#florian
This is at the top of the list in the Incomplete List of Mistakes in the Design of CSS[1]. Which has been discussed several times on HN (last 2 months ago)[2].
This just reminded me of the first bug of my career that took me hours trying to figure out. Colors weren't working correclty in IE 6 (pre IE Developer Tools) and I eventually learned that Firefox accepted both spellings "gray" and "grey", whereas IE only one of them.
Don't remember which one I used, but do remember that I went home early that day after that :/
Good point, thanks for pointing it out. I think I was trying to deal with it, but for some reason I just let it be this way. Also contributions are welcome! :)
After doing some digging, I found out that Peru is also a named color in the X11 color system[1]. Peru in particular seems to come from Peruvian Brown[2]. I don’t know what is peruvian about this shade of brown. But hopefully this is enough to get you started.
Yes, Peru used to export pottery with a distinct brown colour. Prior to cheap air travel travelling to Peru was rare but the pottery was common. So "Peru pottery brown" was just called "Peru" when talking about colours.
Note that their hue and lightness values are almost same. The only difference is saturation and that seems to be why they are on the same row, differentiated only by the saturation axis.
Yeah? Well … you know, that's just, like, your opinion, man. More specifically, HSL's opinion. HSL is a fine colour space for specifying CSS colours, but not so good for evaluating lightness.
If I use HSLuv instead, which is supposed to be like HSL, but more human-perceptually uniform and sane (basically a neat compromise between CIE Luv/Lab and standard HSL), I get a lightness of 61.2 for cadetblue and 91.1 for cyan.
My bog-standard image editor uses HSB (a.k.a. HSV) in the HSL-style mode of its colour picker (HSL isn't even an option); and if I measure cadetblue with that via the ‘eyedropper’ tool, I get a brightness of 63%, whereas cyan has 100%.
Those are obviously way closer to the truth when you just, like, look at the colours — it's totally plausible that cyan is about 50% brighter; “lightness values are almost same” is not plausible.
This discrepancy isn't a huge problem, because the main dimension by which this tool organises colours is hue, which HSL is OK at. Only the way in which colours with similar hue are laid out on the page is off. It would be nice to see a more appropriate colour space used for this purpose.
I was commenting based on the HSL values of the mentioned colors. At the time of creating this tool I really didn't care too much about using a more perception-aware color space. Doing it just based on HSL already seemed like a huge win. But I received similar feedback in the past, too. So thanks for pointing out. I'll maybe think about making it even better in this sense.
I had no idea there were this many named colors in CSS.
Turns out there are 16 HTML colors (upped to a whoppin' 17 colors in HTML4/CSS2.1) and around 124 named colors which originally came in due to X11. Since then, several colors have been added through various standards updates for a total of around 147 colors.
Most of the color names come from X11 rgb.txt which was not exactly "designed" to be anything and also many entries assume RGB color space of some particular Unix workstation which was decidedly non-sRGB (eg. using significantly different gamma curve).
Worth watching the Technology Connection video on the colour Brown [1]. It's a strange colour that only really exists when placed in the context of other colours, not something that can really be produced by a pure RGB light source, which explains why the CSS Brown colour looks red.
For speed's sake could a hover or tap bring out the hex code? I understand that was not the function of your site. It would be cool to just be able to quickly see/use the hex if one is searching for color combos.
Interesting point. Maybe the user could toggle the animations on and off. But back then, I hadn't designed this tool with the idea of creating a standard-ish colorpicker in mind.
The site is literally about CSS color names for 256-bit colors, it’s not a palette site with beautiful colors. This is a ridiculous feature request, but I can’t say I’m not used to this.
This may be a use case perspective. For your use case, knowing hex code is superfluous, and that is your mental model. I interface between researchers, designers and developers. If someone in my environment says "I want this cadet blue', the first thing others ask is "what is the hex code".
This is definitely a cool way of exploring CSS colors.
But, serious question: does anyone actually use CSS colors except for a handful of the basics ("red", "blue") for prototyping/debugging?
I mean, the idea of typing "background-color: lightsalmon;" just feels so bizarre to me.
Whenever I've needed to come up with colors from scratch, I'll just start with an intuitive best guess -- e.g. "hsl(30, 80%, 50%)" -- and then iterate a couple times till I get what I'm looking for.
It seems like even more effort to try to select colors from the CSS palette when it might turn out that there isn't even a satisfactory one. The CSS colors are still extremely limited. E.g. the distance between neighbors like "dark cyan" and "darkslategray" is huge.
I prefer to use named colors in my own CSS layouts. "lightsalmon" is more descriptive to me than "#FFA07A" or "rgb(255, 160, 122)" or "hsl(17, 100%, 73.9%)" at a glance.
Awesome if you're in your office on your usual work computer. Not great if you're in the field trying to make quick fixes on whatever terminal a client provides.
> "lightsalmon" is more descriptive to me than "#FFA07A" or "rgb(255, 160, 122)"
While I agree, I feel that learning to look at "#FFA07A" and immediately grok "pink" has been of general benefit to me as a frontend dev.
> or "hsl(17, 100%, 73.9%)" at a glance
I must admit though that I haven't mastered identifying hue by number just yet (though if I do, it will be even better as Saturation and Lightness/Luminosity are much easier to reason about).
I always found hex codes non-intuitive, but the hue values are easy once you just remember:
0 = red
120 = green
240 = blue
Then you just interpolate as desired, so yellow is 60, orange is 30, red-orange is 15.
And really all you need to remember is red = 0 (lowest energy wavelength) and the three RGB primaries are spread evenly around the 360° color wheel, therefore 0, 120, 240.
If you're good at knowing how colors mix, RGB values are also very intuitive, since they're literally in RGB order and the the closer to FF it is, the more of that color is in it.
But I hadn't spent the time to look at hue values, so your chart helped me get better at them.
This would be true if the CSS color names were actually reasonable, but many of them are not.
One would be better off using the results [1] of Heer & Stone (2012) [2] (or a similar analysis) to assign names to sRGB colors. You end up with 33 unique names instead of more than 100, and the number of unique names can be reduced further by merging synonyms.
It doesn't matter what the names are, the point is you can have a plugin that changes one color to another based on their names and what you can see. The names are a much smaller search space than "all possible hex codes".
I'd argue that the 147 named CSS colors are still too many (but definitely better than the ~16.8 million sRGB colors). Regardless, since hex codes are used in practice, they would still need to be dealt with.
Are you saying such a plugin exists that only works with named colors?
That would seem like a... usability disaster.
Any accessibility tool for vision should operate at an OS level to map colors across everything. And even if you wanted a web-only tool, it would need to similarly operate across all colors -- whether hex codes or in images or SVG's. Very few sites use any named CSS colors at all except for "white" or "black".
There are lots of areas where it's important to keep accessibility in mind... but named CSS colors would not seem to be one of them.
For contrast, css can be quite effective. A brute force background black, text white, link yellow has served me very well. For color blindness correction an OS level filter is the way to go.
I honestly don't know, it's just what I was told by someone who is visually impaired a long time ago. That it's easier if people use the names instead of the hex codes because then they can more easily convert that.
As others say, this sounds unlikely and unwieldy. It also doesn't quite make sense. How would it help to change "lightyellow" to "yellow", say, without knowing the contrast of the other colors next to it? Are you trying to darken it or lighten it?
It would make much more sense to do something check the lightness ratio between the foreground and background colors, and increase that ratio on the fly. Chrome can already tell you if the color ratio is too low to pass accessibility guidelines. There are a number of plugins that do this, like Color Enhancer [1] or High Contrast [2].
I feel pretty confident saying that is not a relevant use case.
I used to use a hand written user stylesheet for color accessibility and know various people using different tools to get the contrast they need. Named colors are not a factor.
> Whenever I've needed to come up with colors from scratch, I'll just start with an intuitive best guess -- e.g. "hsl(30, 80%, 50%)"
That's what I do too, but I find it leads me to get stuck in a rut with certain color areas. Looking at this site was a good reminder to me to give named colors a try just because it will help me break out of my usual color habits.
I've never used them or seen them used for large-scale production sites but I reach for them all the time when building out small proof of concept or isolated examples for debugging in places like Codepen. It's handy to have a few appealing colors memorized when you're sketching things out.
When I started web dev in the early 2000s, I remember it being recommended to use the named colors because of them being more consistent accross different monitors. Not sure if this was true at all and/or only for the original 16 basic colors.
Nonetheless, I kept using them for a while, because I think it makes the css easier to read, when having names (even suboptimal ones) over hex codes.
But with the introduction of css preprocessors in the late 2000s that allow defining variables, I have not used them since.
This might be a dumb question but how would named colors be more consistent across monitors? I thought they mapped to the same RGB value so there would be no difference between 'red' and #FF0000.
I remembered it wrongly. It wasn't about named colors, but "web-safe colors" that can be displayed by 256 color displays directly, without having to fallback to the closest color or by using dithering. Some of them happened to have a name attached to it. Don't know if the original 16 named colors are also all safe colors.
i believe it's not common to use css color names. i wish more colors were defined and people used them more though. it provides a very consistent color re-use.
Up until I started using SASS and working with designers who picked color palettes (or changed them FREQUENTLY!) I always used named colors. But with so many minute tweaks in the RGB hex values each UI review, the names lost meaning.
As a webdev who is used to have professional designers by my side at my day job, lacking the color touch of an expert, I usually just pick a random named color for my hobby projects:
I like the names ones due to lack of imagination: I just try a few names ones until it looks good. I have used light salmon before! In fact I used some names ones on a side project today.
Out of curiosity are you male? There are physical differences between men's and women's eyes where men's eyes are better at edge and motion detection and women's eyes are better at detecting the difference between blue and green.
Or at least adults are, possibly because of the environment they grew up in (the science is still murky on that one).
Color perceptiveness varies surprising widely across people.
I took a test a while back and discovered that I'm apparently the color equivalent of a super-taster. I have extremely fine color perception.
In the examples you list, lawngreen looks darker, bluer and a little more saturated than chartreuse. Palegreen is much lighter than lightgreen and somewhat more saturated. Mediumturquoise is bluer, darker, and duller than darkturquoise's greenish tint.
Note, of course, that your monitor and viewing environment will affect your perception too.
1. True. Maybe I could make it also disabled to restrict interacting with it altogether.
2. I didn't design the tool as a more serious colorpicker or color scheme generator, so I wasn't thinking about adding more advanced features.
3. I thought about adding a search box that would accept many possible color values as input, but I feel like, adding anything will make the design more cluttered at this point. So, for me, adding stuff is more of a design challenge than a technical one.
Interesting display how certain parts of the color space used for the web are clearly held in higher regard than others. Hue 135 has only one color, while hue 36 has whopping thirteen.
This is very nicely done, but I still prefer the simplicity of <http://davidbau.com/colors/>. Despite being only 2-dimentional, I find that layout strangely more intuitive. I think the author manually tweaked the color positions, so that may be the reason.
What do you mean? It's just a static HTML table and it looks fine on both my Android 11 phone with Opera and in Firefox's Responsive mode on the desktop. It may not be mobile-friendly, but that's not inherently bad, especially for something that's not meant to be used on a phone.
Black and white are probably used quite a lot, for obvious reasons. I use the other colours a lot for quick prototyping or debugging (particularly red), but I generally fine-tune the colours to something else later.
I love this! I am one of the rare people who use named colors all of the time, and this will definitely get a bookmark from me!
Especially during prototyping/design, it's soooo much easier to keep your designs consistent with a named look-alike color, then switch over to brand colors with a find/replace.
For personal projects, I almost exclusively use named colors.
166 comments
[ 2.5 ms ] story [ 179 ms ] threadI've created this tool last summer, but I hadn't shared it here back then. It's a PWA that I made with pure JS.
No. In this case there’s nothing earnest about the smiley face, which is why it makes the comment seem rude. Just like a genuine smile is different to Dolores Umbridge’s smile.
I read the comment as an attempt to redirect the person from begging to helping, in as nice a way as possible.
But if someone has a bone to pick with people who are rude about suggestions, they're going to read ill intent into the whole message, smiley or otherwise.
Edit: here you go https://pastebin.com/5Kypr4kh
Edit 2: I would, but I'm at work so personal GH is a no-go atm. I'll cycle back here EOD & make the PR if OP agrees w/ proposal
in other words: how can i just bunch more colors together?
I'm not aware of an equivalent tool for Pantone colors. But it can be created using this very tool with a table of pantone colors instead of a table of named css colors that it uses now.
There is a tool, but I've only seen it in a dead tree edition.
One thing I noticed is that some colors appear brighter, but are further down on the Saturation scale. For example, mediumturquoise and turquoise are shown as being less saturated than cyan, though cyan doesn't mix in any gray. Are these sorted by the sums of their RGB values? I'm also not too well versed in color theory, so I could be missing or misunderstanding something too.
I think there's a misunderstanding there. Mediumturquoise and turquoise are both located above cyan, which means they are brighter as the vertical axis is the lightness.
Also, to answer your question, colors are sorted by their hue, saturation and lightness values. So, it's actually a 3D color visualizer, where one dimension (hue) is reduced into just a slider at the top, and the other two dimensions are represented in a 2D grid.
Thanks for your comment!
"Burn sienna" seems even more varied. Here's are four different color-oriented websites, with a dark earthy orange from Colorlex [1], a light salmon from Canva [2], a light brown from Benjamin Moore [3] and a dark brown from Atelieracrylic [4].
1. https://colourlex.com/project/burnt-sienna/ 2. https://www.canva.com/colors/color-meanings/burnt-sienna/ 3. https://www.benjaminmoore.com/en-us/color-overview/find-your... 4. http://atelieracrylic.com/atelier-interactive/burnt-sienna/
[1]: https://www.youtube.com/watch?v=wh4aWZRtTwU
- The XML W3C Rec: https://www.w3.org/TR/xml/
- The HTTP 1.0 RFC: https://tools.ietf.org/html/rfc1945
However, there are exception. The Unicode character database has a property called "White_Space" which implies it is two words: http://www.unicode.org/reports/tr44/#White_Space
<tongue-in-cheek> Except that `_` is a "word" character by default. </tongue-in-cheek>
Oh, and don't forget that there is in fact a word-wrap property, which is a much better name for the previous behavior, but in fact only customizes how the line-breaking algorithm determines which words can be broken apart.
1: https://wiki.csswg.org/ideas/mistakes
2: https://news.ycombinator.com/item?id=25891435
[0]: https://stackoverflow.com/questions/8318911/why-does-html-th...
[0]: https://onivers.com/color.html
Know that CSS colors mostly came from X11: https://en.m.wikipedia.org/wiki/X11_color_names
The CSS team shares some blame, though: they adopted them (and they really didn't need to: they could have just supported rgb/hsb/lab triplets).
Don't remember which one I used, but do remember that I went home early that day after that :/
https://en.wikipedia.org/wiki/X11_color_names#Clashes_betwee...
The only "bug" I see, if at all, is that the hue value does not wrap around, i.e. the colors shown at 360 are not the same colors shown at 0.
1: https://drafts.csswg.org/css-color-3/#peru
2: https://en.wikipedia.org/wiki/Eric_A._Meyer#Personal_life
3: https://lists.w3.org/Archives/Public/www-style/2014Jun/0312....
1: https://en.wikipedia.org/wiki/X11_color_names
2: https://en.wikipedia.org/wiki/Shades_of_brown#Peru
Yeah? Well … you know, that's just, like, your opinion, man. More specifically, HSL's opinion. HSL is a fine colour space for specifying CSS colours, but not so good for evaluating lightness.
If I use HSLuv instead, which is supposed to be like HSL, but more human-perceptually uniform and sane (basically a neat compromise between CIE Luv/Lab and standard HSL), I get a lightness of 61.2 for cadetblue and 91.1 for cyan.
My bog-standard image editor uses HSB (a.k.a. HSV) in the HSL-style mode of its colour picker (HSL isn't even an option); and if I measure cadetblue with that via the ‘eyedropper’ tool, I get a brightness of 63%, whereas cyan has 100%.
Those are obviously way closer to the truth when you just, like, look at the colours — it's totally plausible that cyan is about 50% brighter; “lightness values are almost same” is not plausible.
This discrepancy isn't a huge problem, because the main dimension by which this tool organises colours is hue, which HSL is OK at. Only the way in which colours with similar hue are laid out on the page is off. It would be nice to see a more appropriate colour space used for this purpose.
Turns out there are 16 HTML colors (upped to a whoppin' 17 colors in HTML4/CSS2.1) and around 124 named colors which originally came in due to X11. Since then, several colors have been added through various standards updates for a total of around 147 colors.
[1]: https://www.youtube.com/watch?v=wh4aWZRtTwU
But, serious question: does anyone actually use CSS colors except for a handful of the basics ("red", "blue") for prototyping/debugging?
I mean, the idea of typing "background-color: lightsalmon;" just feels so bizarre to me.
Whenever I've needed to come up with colors from scratch, I'll just start with an intuitive best guess -- e.g. "hsl(30, 80%, 50%)" -- and then iterate a couple times till I get what I'm looking for.
It seems like even more effort to try to select colors from the CSS palette when it might turn out that there isn't even a satisfactory one. The CSS colors are still extremely limited. E.g. the distance between neighbors like "dark cyan" and "darkslategray" is huge.
While I agree, I feel that learning to look at "#FFA07A" and immediately grok "pink" has been of general benefit to me as a frontend dev.
> or "hsl(17, 100%, 73.9%)" at a glance
I must admit though that I haven't mastered identifying hue by number just yet (though if I do, it will be even better as Saturation and Lightness/Luminosity are much easier to reason about).
0 = red
120 = green
240 = blue
Then you just interpolate as desired, so yellow is 60, orange is 30, red-orange is 15.
And really all you need to remember is red = 0 (lowest energy wavelength) and the three RGB primaries are spread evenly around the 360° color wheel, therefore 0, 120, 240.
But I hadn't spent the time to look at hue values, so your chart helped me get better at them.
This thread is about developers writing CSS...
[0]: https://duckduckgo.com/?q=%23004cff
People with vision disabilities can have a custom plugin that changes the colors based on their name, instead of trying to convert all the hex codes.
One would be better off using the results [1] of Heer & Stone (2012) [2] (or a similar analysis) to assign names to sRGB colors. You end up with 33 unique names instead of more than 100, and the number of unique names can be reduced further by merging synonyms.
[1] http://vis.stanford.edu/color-names/analyzer/ [2] https://doi.org/10.1145/2207676.2208547
That would seem like a... usability disaster.
Any accessibility tool for vision should operate at an OS level to map colors across everything. And even if you wanted a web-only tool, it would need to similarly operate across all colors -- whether hex codes or in images or SVG's. Very few sites use any named CSS colors at all except for "white" or "black".
There are lots of areas where it's important to keep accessibility in mind... but named CSS colors would not seem to be one of them.
Does this exist, or is this hypothetical? If it exists, it's something I would add to my toolkit.
It would make much more sense to do something check the lightness ratio between the foreground and background colors, and increase that ratio on the fly. Chrome can already tell you if the color ratio is too low to pass accessibility guidelines. There are a number of plugins that do this, like Color Enhancer [1] or High Contrast [2].
1. https://chrome.google.com/webstore/detail/color-enhancer/ipk...? 2. https://chrome.google.com/webstore/detail/high-contrast/djcf...
That's what I do too, but I find it leads me to get stuck in a rut with certain color areas. Looking at this site was a good reminder to me to give named colors a try just because it will help me break out of my usual color habits.
Nonetheless, I kept using them for a while, because I think it makes the css easier to read, when having names (even suboptimal ones) over hex codes.
But with the introduction of css preprocessors in the late 2000s that allow defining variables, I have not used them since.
https://en.wikipedia.org/wiki/Web_colors#Web-safe_colors
That said where is my UV value?
the best example i can think of is this fire demo on codepen, which i bookmarked because i really liked the color names: https://codepen.io/jscottsmith/pen/dwZjWK
Words in stead of numbers add a nice touch
Those who treat it as craft and an art
May find that named colors are a good start.
Or red or lightsalmon or yew
Remember that if life is rough
Just add in a little more peachpuff!
that you could use something like LESS,
to substitute code arbitrarily,
for the readable name that's there really.
Someone else's code munge my code
Decreasing its readability for others
And possibly introducing unforeseeen issues
Only to save a few bytes here and there
https://github.com/runarberg/random-go-stone-placements/blob...
Are you using CIE* colorspace to match?
Interestingly the difference between some of these colours is (to my eyes / monitor) ... very little?
E.g. chartreuse and lawngreen, palegreen and lightgreen, mediumturquoise and darkturquoise, etc.
Or at least adults are, possibly because of the environment they grew up in (the science is still murky on that one).
I took a test a while back and discovered that I'm apparently the color equivalent of a super-taster. I have extremely fine color perception.
In the examples you list, lawngreen looks darker, bluer and a little more saturated than chartreuse. Palegreen is much lighter than lightgreen and somewhat more saturated. Mediumturquoise is bluer, darker, and duller than darkturquoise's greenish tint.
Note, of course, that your monitor and viewing environment will affect your perception too.
Some thoughts:
1. In grayscale mode the slider doesn't appear to do anything
2. Have you considered adding a way to compare colors or find complimentary?
3. A simple search box that accepted any css color format would be useful
My answers to your points:
1. True. Maybe I could make it also disabled to restrict interacting with it altogether.
2. I didn't design the tool as a more serious colorpicker or color scheme generator, so I wasn't thinking about adding more advanced features.
3. I thought about adding a search box that would accept many possible color values as input, but I feel like, adding anything will make the design more cluttered at this point. So, for me, adding stuff is more of a design challenge than a technical one.
Are named CSS colors seeing any practical use?
Also, nice project :)
Especially during prototyping/design, it's soooo much easier to keep your designs consistent with a named look-alike color, then switch over to brand colors with a find/replace.
For personal projects, I almost exclusively use named colors.