There are currently no frequently asked questions associated with this exercise – that’s where you come in! You can contribute to this section by offering your own questions, answers, or clarifications on this exercise. Ask or answer a question by clicking reply () below.
If you’ve had an “aha” moment about the concepts, formatting, syntax, or anything else with this exercise, consider sharing those insights! Teaching others and answering their questions is one of the best ways to learn and stay sharp.
Join the Discussion. Help a fellow learner on their journey.
Ask or answer a question about this exercise by clicking reply () below!
Agree with a comment or answer? Like () to up-vote the contribution!
I’ve ran the code, and looked at the webpage for each code that I ran - I can’t seem to find a single difference, it looked exactly the same as before.
The colors are indeed different, albeit only slightly to us non-designers. I suggest that you take a screenshot(snipping tool if you are on Windows) before you change the color, and you can compare the changes.
However, without resetting the lessons, I can’t recall whether darkSeaGreen was the color used for .green { }. If it was, then indeed there is a difference.
We used, #9EB599 when in fact it should be, #8FBC8F.
Can you recall the color name that was initially used?
I completely understand the concept of the lesson,
how these color code changes are intended to demonstrate different ways of expressing the same colors.
HOWEVER, THE COLORS ARE DEFINITELY DIFFERENT!!
especially going from RGB to Hex code, the shades are completely different, much cooler tones.
I think it’s time for some revision @Codecademy …lol When were these exercises made?
Please elaborate. RGB to HEX is very straight forward when we consider number base.
rgb(255, 255, 255) => #FFFFFF (#fff)
255 left shifted four bits gives,
0xFF0000
255 left shifted two bits gives,
0xFF00
255 with no shift gives,
0xFF
When we combine them (as in, add) we get,
0xFFFFFF
The only real challenge, programmatically speaking, is creating the correct representation. That’s not really a problem since at a script level we’re working with strings a lot of the time. We can use padding techniques afforded us for string representations.
Hello! Thank you for your response!
I completely understand what you’re saying. As I’ve mentioned above, I completely understand the concept of the exercise. Technically speaking, as you said, the colors should look the same even when translated between different methods of expression, whether it be in hex or rbg etc. But I attached a screen shot of how the “correct translation” of color codes resulted on my screen. As you can see, they are not the same colors to the plain eye.
I assume other users who’ve commented on the change in colors have seen similar results as i have. Very odd! This is why i was wondering if the color codes that the exercise provides haven’t been properly reviewed? Could just be a human error.
Very likely. This, like so many other reported glitches will likely remain unchecked unless it is in a Pro track. Might be something to open a ticket on… RGB not matching named colors.
Hi @mkkeems! I was curious about your comments, so I went there and took a look again. I think the colors are expected to be different.
As the exercise brings:
I’m curious as to why there are two types of decimal color syntax? Is there an advantage for one or the other in certain situations? Or was there just no clear winner which was going to be the internationally selected syntax for color?
Also, if I recall my art classes correctly, the primary colors are Red, Yellow and Blue. Why does this translate to Red, Green and Blue in CSS?
That relates to pigments, which are subtractive. When we mix blue and yellow pigments under white light (or sunlight) we get green. All the wavelengths of light are absorbed by the pigment except green, which is reflected.
RGB relates to light, which is additive. When we shine a red light and green light at the same spot we end up with yellow. If we place the light sources sufficiently close, and stand back far enough, our eye does not see the red or green light, but the combination, yellow. A color TV is built on the same principle. Pixels are sufficiently small so that when we sit back from the TV we don’t see the three RGB colors, but the combination of the three. When red, green and blue are combined with full intensity we get white. Take away the blue and we get yellow; take away the green we get magenta; and, take away the red we get cyan.
Interestingly enough, those three (yellow, magenta, cyan) (and black) are the principle colors used in printing. That takes us back to pigments and reflected light.
Don’t stop there! What about spectography and what it can teach us about matter, and about the universe as a whole? Color has a larger role than just our immediate, visible world around us. It is all the characteristics that inform us about the universe.
@mtf and @mkkeems actually, it’s not an error. In the lesson, it clearly states that we are actually changing the colors. In previous lessons, we did convert named colors to HEX to RGB. However, the point of this lesson was to introduce us to the fact that we aren’t limited to the named colors and that we have 16,777,216 choices
There really is no need to have more than 24-bit color. Our eye can barely discern even a fraction of that. HSL is 22-bit color, and even that spectrum is extensive enough. Only very sophisticated lasers and detectors can differentiate between the 400 000 hues of red.
Hello! I’ve noticed that the .rosting selector is set to background-color: #FFFFFFFFF. Why are there 9 characters? I know #FFFFFF is supposed to be white, so how do the last three Fs change that to the color we see on the page - a sort of beige, I guess?
Also, this color is only set to .rosting, but it appears to also be the color of the body, even though the body selector is set to background: #F7F7F7. When I change the value of this background to any color, hexadecimal or otherwise, nothing happens:
In fact, the background color in the body remains the same even if I delete the code for it. However, when I alter the background color in the .roasting selector to white (#FFFFFF), the color in the .roasting div changes accordingly, and the beige color, that apparently comes from nowhere, remains on the body:
Sometimes changes don’t take effect unless we refresh.
As for, #FFFFFFFFF, I suspect the browser is ignoring this property and going with whatever is inherited.
Restore the BODY color schema, and tweak the .roasting color to 8 digit hex which is the equivalent of RGBA.
background-color: #FFFFFF7F;
Now what does it look like?
RRGGBBAA
The browser computes a normalized percentage from the last hex pair.
x = 0x7F
100 * x / 0xFF => 49.80 -> 50%
What the AA stands for… Alpha Transparency is a measure of saturation of the background color, in a sense. The more transparency, the more saturation by way of visibility of the actual background color. I use saturation as a parallel, not an exact unless we consider that 0 saturation gives us gray, or simply, no color.
So when AA is set to 0x00 there is no color from underneath that can show through. Opacity is 1.
You’re right, I was able to changed the body color after refreshing. But besides that, I realize it wasn’t working before because I assumed that the code bellow /* Old browsers */ would only work, well, on old browsers, and since mine is up to date I only changed the line above it. But it seems that the color we see is actually #EAE0D5. This is the code:
My question now is: what is the purpose of the first background: #F7F7F7, if the color will be determined by the lines bellow it, even in new browsers? Wouldn’t have been simpler to just set the background to #EAE0D5? The result appears to be the same…
So, the browser is ignoring #FFFFFFFFF because it’s wrong - since it has nine characters when it should have eight?
) below.
) to up-vote the contribution!
