Bleh, it seems they forgot to proof this or have it read by someone who ... I don't know, maybe knows a bit more about how it really works.
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.
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.
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.
"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
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.
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?
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
// R G B
color = 255 << 16 | 128 << 8 | 96
Colors with an alpha channel shift all that over another 8 bits and then add an alpha channel. So RGBA(0,0,0,0.5) is equivalent to:
// R G B A
color = 0 << 24 | 0 << 16 | 0 << 8 | round(0.5 * 255)
In fact, this latter bit order is probably how the browser stores all the colors now that browsers allow for alpha channels in colors. Yeah, you can store this in a struct if you want (I remember Delphi let me encode a struct to/from a raw unsigned integer automatically by compiler optimization), but in the end this is how the raw color is encoded and sent to the the underlying renderer. Ask anyone that has dealt with OpenGL, DirectX, or anything close to the hardware.
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.
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 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.
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.
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. :-)
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.
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 ...