The Code Side Of Color(coding.smashingmagazine.com)
coding.smashingmagazine.com
The Code Side Of Color
http://coding.smashingmagazine.com/2012/10/04/the-code-side-of-color/
7 comments
I also have a real problem with them referring to the second digit from the right as the "tens place", considering it's actually base sixteen...
Only if you take 'ten' to be a number in base 10. /s
Every base is base 10. ;).
I understand you meant that in jest but base 1 is possible, albeit very cumbersome:
1 = 1
2 = 11
3 = 111
4 = 1111 ...etc.
1 = 1
2 = 11
3 = 111
4 = 1111 ...etc.
Sorry for the nitpick, but that's not really "base 1".
It is "unary", which is completely different encoding than the "positional notations" such as decimal, octal, binary, etc. The positional notation doesn't work with base 1, as in that notation there would be only 0, and 0, 00, 000, etc., which all mean the same number: zero.
It is "unary", which is completely different encoding than the "positional notations" such as decimal, octal, binary, etc. The positional notation doesn't work with base 1, as in that notation there would be only 0, and 0, 00, 000, etc., which all mean the same number: zero.
That I agree on, it is conceptually different (and more primitive); the whole conversation just reminded me of GEB.
Really? How do I write zero in your system? (as in the number of apples I have if I have none at all)
If octal uses the digits 0-7, and binary uses the digits 0-1, then shouldn't base one use only the digit 0?
If octal uses the digits 0-7, and binary uses the digits 0-1, then shouldn't base one use only the digit 0?
0 = 1
1 = 11
2 = 111
3 = 1111, etc. {1,2,3...} and {0,1,2...} are isomorphic.
1 = 11
2 = 111
3 = 1111, etc. {1,2,3...} and {0,1,2...} are isomorphic.
But surely that's not the way it works in any other base. In any other base there is a digit '0' such that:
0 = 00 = 000 = 0000 = the number of apples I have if I don't have any.
0 = 00 = 000 = 0000 = the number of apples I have if I don't have any.
To dig in a little further, when we say base N, we mean that we are expressing an integer as a sum of the values N^i (for i being every nonnegative integer), each multiplied by a weight that is an integer between 0 and N-1 inclusive.
Why do we do this? Because every integer has exactly one unique representation in this system. We could have picked any values we wanted for the places (rather than N^i) but unless we pick carefully, either some numbers aren't representable, or some numbers have multiple representations.
Base one has a problem right from the start, which is that 1^i = 1 for any value of i - when all places have the same place value, numbers aren't going to have a unique representation. The other problem is that the only number you can write in base one is zero, because the only possible weight (the only integer between 0 and N-1) is 0.
When you write 1111 = 4 you are sneakily using the length of the number on the page to encode the value. The length of the number on the page isn't supposed to matter. In base 10, 17 = 017 = 0017 = 00017.
Why do we do this? Because every integer has exactly one unique representation in this system. We could have picked any values we wanted for the places (rather than N^i) but unless we pick carefully, either some numbers aren't representable, or some numbers have multiple representations.
Base one has a problem right from the start, which is that 1^i = 1 for any value of i - when all places have the same place value, numbers aren't going to have a unique representation. The other problem is that the only number you can write in base one is zero, because the only possible weight (the only integer between 0 and N-1) is 0.
When you write 1111 = 4 you are sneakily using the length of the number on the page to encode the value. The length of the number on the page isn't supposed to matter. In base 10, 17 = 017 = 0017 = 00017.
"When you write 1111 = 4 you are sneakily using the length of the number on the page to encode the value. The length of the number on the page isn't supposed to matter. In base 10, 17 = 017 = 0017 = 00017."
I couldn't find a rigorous definition of a base system offhand. If you require that number N prepended with additive identity I, so IN = N, I agree with you. But every number in the system I described certainly has a unique representation. Also, this is incorrect: "The other problem is that the only number you can write in base one is zero, because the only possible weight (the only integer between 0 and N-1) is 0." Try taking a look at: http://en.wikipedia.org/wiki/Peano_arithmetic
I couldn't find a rigorous definition of a base system offhand. If you require that number N prepended with additive identity I, so IN = N, I agree with you. But every number in the system I described certainly has a unique representation. Also, this is incorrect: "The other problem is that the only number you can write in base one is zero, because the only possible weight (the only integer between 0 and N-1) is 0." Try taking a look at: http://en.wikipedia.org/wiki/Peano_arithmetic
They clearly have a different understanding of base 16 to us!
Not to mention that they equate A-F as 10-16, when in fact it is 10-15, and the whole "ones column" goes from 0-15, not 1-16.
Yeah, this bugs me in all kinds of ways (not least because I once wrote a library for converting between the common CSS color specifiers, and had to document this stuff, so there's a lot of "I can do this better and I'm just a guy who writes code").
This mistake was corrected 30 minutes after the article was published. The article went through two technical reviews but apparently such mistakes still happen. Thanks for bringing it to our attention — the wording was incorrect.
There needs to be a w3fools equivalent for Smashing Magazine.
I'm all for designers learning a bit of the technical background behind colors on the web, but this article is full of technical inaccuracies, misconceptions, and misleading comparisons.
"Tens place"? "24-bit color" ignores alpha and color palettes "# means 'This is a hex number'": No, it means a web color expressed as 3 hex numbers.
Plus, I know it looks better to make your colors less saturated, but when you are demonstrating starting from #ff0000 and adding other colors, why not actually display #ff0000 instead of #e93f32?
Finally, spellcheck.
"Tens place"? "24-bit color" ignores alpha and color palettes "# means 'This is a hex number'": No, it means a web color expressed as 3 hex numbers.
Plus, I know it looks better to make your colors less saturated, but when you are demonstrating starting from #ff0000 and adding other colors, why not actually display #ff0000 instead of #e93f32?
Finally, spellcheck.
I have to disagree with how critical you're being. Yes, proof-reading is highly important, but he's writing an article for rather untechnical people (that is the audience: people that don't understand hexadecimal representation of colors). There's no guarantee that these folks know base-16, that RGB means bytes representing each color in said order, or even how that maps to a monitor.
While the original article is somewhat misleading over why hexadecimal works the way it does, it's closer than you. The OP is trying to explain base-16 at the same time he's trying to describe basic RGB handling. Not everyone learns math in other bases at school (I didn't, I had to teach myself) so he had to cover it, and make use of familiar terms like "tens place".
On top of that, the explanation was presented in a highly visual way. There are a lot of visual learners who just don't get it when I try to explain just verbally, or just with the code.
The OP is right: the pound, or hash, sign is how the browser knows that the identifier is a hexadecimal sequence—just like compilers using 0xff00... to indicate hexadecimal numbers. #ff0000 is one hexadecimal number just like #ff000000 is. They aren't separate numbers, they just have different numbers of bits.
So what's going on here? Well, it's all about the bits, because 2 hexadecimal digits can express 0-255 or 1 byte. So this is actually a data structure of 3 bytes left-shifted into a single 32-bit integer.
#ff8060 (16744544) is the same as
So why are hexadecimals widely used in CSS? Because they represent the actual data structure in memory after all the fancy conversions, like HSL, are done.
Perhaps I misunderstood you, but I felt like writing up an explanation of this anyhow. Might be useful to someone that didn't understand the why.
While the original article is somewhat misleading over why hexadecimal works the way it does, it's closer than you. The OP is trying to explain base-16 at the same time he's trying to describe basic RGB handling. Not everyone learns math in other bases at school (I didn't, I had to teach myself) so he had to cover it, and make use of familiar terms like "tens place".
On top of that, the explanation was presented in a highly visual way. There are a lot of visual learners who just don't get it when I try to explain just verbally, or just with the code.
The OP is right: the pound, or hash, sign is how the browser knows that the identifier is a hexadecimal sequence—just like compilers using 0xff00... to indicate hexadecimal numbers. #ff0000 is one hexadecimal number just like #ff000000 is. They aren't separate numbers, they just have different numbers of bits.
So what's going on here? Well, it's all about the bits, because 2 hexadecimal digits can express 0-255 or 1 byte. So this is actually a data structure of 3 bytes left-shifted into a single 32-bit integer.
#ff8060 (16744544) is the same as
// R G B
color = 255 << 16 | 128 << 8 | 96
// R G B A
color = 0 << 24 | 0 << 16 | 0 << 8 | round(0.5 * 255)
So why are hexadecimals widely used in CSS? Because they represent the actual data structure in memory after all the fancy conversions, like HSL, are done.
Perhaps I misunderstood you, but I felt like writing up an explanation of this anyhow. Might be useful to someone that didn't understand the why.
As a programmer interested in design, I didn't mind the inaccuracies. To my shame, I didn't even noticed them.
But I found the article to be quite good and useful, and it's obvious that the guy had all the good intentions.
But I found the article to be quite good and useful, and it's obvious that the guy had all the good intentions.
I found this article useful despite its errors. However, this article only reinforces my belief that it is easier to work with the HSL color notation. Young(Yello-60degree) Guys (Green-120) Can (Cyan-180) Be (Blue-240) Messy (Magenta-210) Rascals (Red-0/360) gives the visualization for hue. Saturation is between 0-100, where 0 is grayed out and 100 is full-hue. Lightness varies from 0-100, where 0 is blacked out, 100 is whited-out and 50 would give the color as-is.
As someone who is colorblind, a lot of my design is based on the logic behind colors rather than looks. Of course, I always let an actual designer approve, tinker with, or redo my work. There are a lot of inaccuracies in this piece but I like the gist of it.
I'm color-sighted but my son is color blind. I find that the easiest way to remember what colors differentiate well is to remember the orange/blue colors that Valve chose for Portal specifically because they have the greatest visual distinction for the greatest number of people.
It's also an easy shorthand, because many developers/designers know the game, so you can just say "you know, Portal colors"
It's also an easy shorthand, because many developers/designers know the game, so you can just say "you know, Portal colors"
That's a great fact! I'm going to remember that.
It’s a good explanation of how hex colour codes work, but in this day and age it's so much simpler to use (and think in) rgb(n, n, n) notation. Not to mention the hsl(n, n%, n%) notation that is supported by modern browsers.
I exclusively use HSL notation because if you're using less functions like spin(), [de]saturate() and [lighten|darken]() it's what makes the most sense.
I've started using HSL too. Paul Irish is right, once you start using it, it's really easy to grasp and use on the fly.
See:
http://mothereffinghsl.com/
See:
http://mothereffinghsl.com/
Excellent read. I've been interested in developing some sort of tool to help me select, save, and organize colors for custom palettes.
This will definitely help -- thanks!
This will definitely help -- thanks!
Completely disagree - it was an awful read, but please try http://www.colourlovers.com/ for the selecting, saving and organising of colours.
Colour Lovers is great for picking palettes, but TERRIBLE for mixing colors together.
Thanks. Sorry you didn't find the article interesting.
I never thought I'd be down voted for havi g the opinion that something was great.
You are a SHINING example of why HN comments are such awful places these days.
Thanks. Sorry you didn't find the article interesting.
I never thought I'd be down voted for havi g the opinion that something was great.
You are a SHINING example of why HN comments are such awful places these days.
Not only does Colourlovers have tools for what you're complaining about (which is rarely something a computer can do to begin with outside of using equations to do so), but the other commenter was legitimately trying to point you towards a better solution. Ironically, instead of thanking him, you berate him and then called him the reason this place sucks. Yikes.
What's wrong with down voting to indicate disagreement? I wouldn't have commented unless I had something constructive to say.
Colour Lovers is great for picking palettes, but TERRIBLE for mixing colors together.
Thanks. Sorry you didn't find the article interesting.
Thanks. Sorry you didn't find the article interesting.
Trying to work with color in RGB triplets is like trying to assemble furniture with a plastic fork. Any discussion of color for programmers needs to be in terms of HSL, with a discussion of Lab for completeness and RGB for dealing with legacy systems.
Trying to work with color in RGB triplets is like trying to assemble furniture with a plastic fork.
Agreed, but while HSL is surely more intuitive than RGB, it is still a relatively crude tool because the numbers typically aren’t calibrated in any useful way.
After studying colour theory for a long time, I became convinced that the most interesting colour systems are often those based on actual human perception rather than “arbitrary” physics or mathematics. See for example Munsell’s work[1], which is built around perceptually uniform changes as the values representing colours vary, or the Opponent Process theory[2], where hues are represented in terms of red-green and blue-yellow axes rather than placing three primary colours at the vertices of an equilateral triangle and then interpolating into a circle.
Personally, I have found the perceptual systems more useful than RGB or a traditional colour wheel and something like HSL built on it, particularly for technical/mechanical tasks that require generating variations of colours starting from one or more known anchor points like colours lifted from a photograph or a client’s branding guidelines. I think you always need a human touch, though: all useful colour models have multiple dimensions, and there is definitely both skill and art in making choices like whether to vary each dimension by large amounts, subtle but visible differences, or not at all.
Sadly, I fear we’re still many years from calibrated/environmentally-aware display devices being the norm. That means for something like web design, the majority of visitors to most sites are going to see all those lovingly chosen colours on a poorly calibrated screen that may scarcely resemble the original designer’s choices anyway, so to some extent trying hard to refine a colour scheme at the above level is mostly wasted effort, at least for now. Such is life. :-)
[1] http://en.wikipedia.org/wiki/Munsell_color_system
[2] http://en.wikipedia.org/wiki/Opponent_process
Agreed, but while HSL is surely more intuitive than RGB, it is still a relatively crude tool because the numbers typically aren’t calibrated in any useful way.
After studying colour theory for a long time, I became convinced that the most interesting colour systems are often those based on actual human perception rather than “arbitrary” physics or mathematics. See for example Munsell’s work[1], which is built around perceptually uniform changes as the values representing colours vary, or the Opponent Process theory[2], where hues are represented in terms of red-green and blue-yellow axes rather than placing three primary colours at the vertices of an equilateral triangle and then interpolating into a circle.
Personally, I have found the perceptual systems more useful than RGB or a traditional colour wheel and something like HSL built on it, particularly for technical/mechanical tasks that require generating variations of colours starting from one or more known anchor points like colours lifted from a photograph or a client’s branding guidelines. I think you always need a human touch, though: all useful colour models have multiple dimensions, and there is definitely both skill and art in making choices like whether to vary each dimension by large amounts, subtle but visible differences, or not at all.
Sadly, I fear we’re still many years from calibrated/environmentally-aware display devices being the norm. That means for something like web design, the majority of visitors to most sites are going to see all those lovingly chosen colours on a poorly calibrated screen that may scarcely resemble the original designer’s choices anyway, so to some extent trying hard to refine a colour scheme at the above level is mostly wasted effort, at least for now. Such is life. :-)
[1] http://en.wikipedia.org/wiki/Munsell_color_system
[2] http://en.wikipedia.org/wiki/Opponent_process
Maybe I'm getting old, though I'm not even 30 yet, but I've never grasped HSL like I have RGB and RGBA. I come from a background of toying with OpenGL and game programming, so it became habitual as that was the required structure ~10 years ago.
With openGL, DirectX, and other real-time rendering I believe sRGB or linear gamma are preferred because there are library and possibly hardware primitives that can be taken advantage of.
Outside of that I feel we should be notating color in terms of the L* a* b* colors
Web browsers also seem to be using RGB for storing colors internally. You can specify colors in HSL, but retrieved values are only in RGB. E.g. if you write "hsl(100,0%,0%)" in your CSS file then the color will be represented as #000000 in DOM/CSSOM. This is especially annoying when you are trying to implement color picker because information about hue is lost if saturation or lightness are low.
Using LAB wouldn't be so bad. It'd take quite some adjustment though.
When computers name a color, they use a so-called hexidecimal code that most humans gloss over: 24-bit colors. That is, 16,777,216 unique combinations of exactly seven characters made from ten numerals and six letters — preceded by a hash mark.
I mean, "hexidecimal" is hopefully just a typo, but the "explanation" in the second sentence is off by one, it's not seven characters that make up the color, since the hash mark is constant and doesn't contribute. I would object to the "ten numerals and six letters" too, but I guess that's a suitable popular nomenclature.
And I don't even have a lawn ...