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.
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.
> 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.
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.
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.
> 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.
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.
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:
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.
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.
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.
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.
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.
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].
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.
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].
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.
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 :/
"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.
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.
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.
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.
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.
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! :)
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.
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.
Some of them are special (they can be displayed on devices with very low colour depth), some of them are just there for sentimental value (e.g., rebeccapurple), but most of them descend from X11's colour list - which itself descends from a mishmash of Crayola colours, Sinclair Paints samples, and whatever Jim Gettys thought was important in this 1985 commit: https://cgit.freedesktop.org/~alanc/xc-historical/commit/xc/...
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.
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).
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.
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.
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.
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.
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.
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".
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.
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.