Welcome to the Treehouse Community
Want to collaborate on code errors? Have bugs you need feedback on? Looking for an extra set of eyes on your latest project? Get support with fellow developers, designers, and programmers of all backgrounds and skill levels here with the Treehouse Community! While you're at it, check out some resources Treehouse students have shared here.
Looking to learn something new?
Treehouse offers a seven day free trial for new students. Get access to thousands of hours of content and join thousands of Treehouse students and alumni in the community today.
Start your free trial
Daniel Suthalong
Courses Plus Student 2,854 PointsThe 4th stage of the Challenge - why using Body P {} doesn't work and P {} works?
Ok, Ive checked some other questions and apparently this answer below works:
p {
a {
color: red;
}
> a {
color:blue;
&:hover {
opacity: 0.5;
}
div.footer & {
color: purple;
}
}
}
Where as I was using:
body p {
a {
color: red;
}
> a {
color: blue;
&:hover {
opacity: 0.5;
}
div.footer & {
color: purple;
}
}
}
Which worked fine up to this point of the challenge, that is Ive been answering all the questions / challenge with:
Step 1: Correct
body p {
a {
color: red;
}
}
Step 2: Correct
body p {
a {
color: red;
}
> a {
color: blue;
}
}
Step 3: Correct
body p {
a {
color: red;
}
> a {
color: blue;
&:hover {
opacity: 0.5;
}
}
Step 4: Incorrect <---
body p {
a {
color: red;
}
> a {
color: blue;
&:hover {
opacity: 0.5;
}
div.footer & {
color: purple;
}
}
}
Taking out the "body" and it says correct...
My question is, why? How come it was correct all this time till the last step? And were all the steps coded right?
3 Answers
Dustin Matlock
33,856 PointsThere may be a bug in the challenge. Please see this post, and the information below.
Selector Intent
It is important when writing CSS that we scope our selectors correctly, and that we’re selecting the right things for the right reasons. Selector Intent is the process of deciding and defining what you want to style and how you will go about selecting it. For example, if you are wanting to style your website’s main navigation menu, a selector like this would be incredibly unwise:
header ul {}This selector’s intent is to style any
ulinside anyheaderelement, whereas our intent was to style the site’s main navigation. This is poor Selector Intent: you can have any number ofheaderelements on a page, and they in turn can house any number ofuls, so a selector like this runs the risk of applying very specific styling to a very wide number of elements. This will result in having to write more CSS to undo the greedy nature of such a selector.A better approach would be a selector like:
.site-nav {}An unambiguous, explicit selector with good Selector Intent. We are explicitly selecting the right thing for exactly the right reason.
Poor Selector Intent is one of the biggest reasons for headaches on CSS projects. Writing rules that are far too greedy—and that apply very specific treatments via very far reaching selectors—causes unexpected side effects and leads to very tangled stylesheets, with selectors overstepping their intentions and impacting and interfering with otherwise unrelated rulesets.
CSS cannot be encapsulated, it is inherently leaky, but we can mitigate some of these effects by not writing such globally-operating selectors: your selectors should be as explicit and well reasoned as your reason for wanting to select something. —CSS Guidelines
Also: CSS Specificity: Things You Should Know by Smashing Magazine.
Sean T. Unwin
28,690 PointsIt's because, in the last challenge, your nesting is incorrect for one - you are are nesting the Edit: either worksdiv.footer & inside the direct children of a in p (i.e. within > a), this part should be in the general child selector of a.
Furthermore, if you leave body p instead of just p the result will be:
div.footer body p a { color: purple; }
since the & is not only adding the a, but also what that is nested within.
This is why you have to be careful when nesting that you don't get unintended results. :)
This is how I performed the challenge which passed:
p {
a { color: red;
div.footer & {
color: purple;
}
}
> a {
color: blue;
&:hover {
opacity: 0.5;
}
}
}
This way works as well:
p {
a { color: red;
}
> a {
color: blue;
&:hover {
opacity: 0.5;
}
div.footer & {
color: purple;
}
}
}
Shawn Flanigan
Courses Plus Student 15,815 PointsAhh...yep. Good catch. I was reading it as
body div.footer p a { color: purple; }
So much nesting.
Sean T. Unwin
28,690 PointsShawn Flanigan said,
So much nesting.
Indeed. ;-p
I caught another error in the nesting (edit: which I see you addressed in your last paragraph) and have edited my op to reflect that as well. Edit: this is not an error in the challenge.
Shawn Flanigan
Courses Plus Student 15,815 PointsSean,
The nesting issue that you talk about at the top of your response (under a instead of >a) isn't responsible for this failing. While a definitely seems like the right place for the rule, it'll pass either way for this challenge. They must just be compiling the css and running it to see if the link in the footer turns purple...which it does, since it happens to be a direct child of the p tag anyway.
The second bit of your answer seems to be the culprit.
Dustin Matlock
33,856 PointsSelectors and nesting in Sass can get confusing. Sometimes CSS feels like an experiment gone awry. Hopefully CSS4 and beyond has better plans, maybe even implementing bits of Sass.
Sean T. Unwin
28,690 PointsShawn Flanigan, fair enough. I didn't test with the direct children in the challenge, although it does make sense, provided p is not within a div in the footer or similar. I've edited the post to state that either method works, although the challenge didn't specify.
Dustin Matlock, it would be great if some concepts of Sass were implemented in vanilla CSS provided the overhead to the browser isn't overly affected.
Dustin Matlock
33,856 PointsSean T. Unwin, check out A Vision for Our Sass.
Sean T. Unwin
28,690 PointsDustin,
That's a really good article. I've read similar ones that touch on some of those principles stated, but it's nice to see them listed together the way they are there.
Jonathan Lo
6,797 PointsHow come I needed to declare the element selector with the footer class in order to compile the code, whereas it worked fine without declaring the elements for blog and entry classes from the video?
p {
a {
color: red;
div.footer & {
color: purple;
}
}
> a {
color: blue;
&:hover {
opacity: 0.5;
}
}
}
I may be answering my own question here, but is this due to sass version differences between the one used here and the one used on my computer?
Sean T. Unwin
28,690 PointsJonathan Lo, I believe it is simply due to a very specific request within the challenge, and not directly related to the Sass compiler.
Shawn Flanigan
Courses Plus Student 15,815 PointsDaniel,
I edited your original post to display the css a bit more clearly. Please see the Markdown Cheatsheet link below the text input to read about posting code in the future.
As for your question...I'm a little stumped by this, too. Dustin's information above is useful in general, but I'm not sure that it explains why a body p selector would be considered appropriate for the first 3 tasks, but not for the last. As far as I can tell, leaving the body tag in your code (while unnecessary) shouldn't change its functionality.
Another thing I'm a bit puzzled by...the answer that you posted above has the div.footer & selector nested within the >a selector, meaning that the link would have to be a direct child of a p tag inside of the .footer div in order for this to work. While this happens to be the case with the html in the example, it doesn't seem to be exactly what the question is asking you to do. I think it makes more sense to nest this within the a rule, just below color: red;. This way if you had a ul element with multiple links in the footer, they would still be purple. I double-checked, and both pass...just not sure why.
Shawn Flanigan
Courses Plus Student 15,815 PointsI'm wrong. Sean's got it above.
Daniel Suthalong
Courses Plus Student 2,854 Pointsthanks for the edit..!
Sean T. Unwin
28,690 PointsSean T. Unwin
28,690 PointsGood information and references from Dustin, but I don't think there is a bug with the challenge, in my opinion.