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

CSS Sass Basics (retired) Variables, Mixins, and Extending Selectors Introducing Mixins

Posted by Unsubscribed User
Unsubscribed User
14,667 Points

Isn't Sass not only moving the DRY problem, since you ARE creating double code only don't see it?

A lot of double code is generated by using mixins, so I think this is not DRY at all. You only don't see the double code, but it is there. Shouldn't the output also be clean? Is there a way to prevent this? (Besides not using mixins)

5 Answers

Chris Shaw
Chris Shaw
26,676 Points
Chris Shaw
Chris Shaw
26,676 Points

Hi Sanne,

What you're saying is very true and I 100% agree with you, however after mixins you will learn about placeholders which are similar but provide more powerful functionality in-which we can group selectors together that share common properties. The major downside to placeholders is that you can get into a situation known as selector junk which is what happens when you use a placeholder within a deeply nested selector.

See the below example code which is similar to what Hampton will show you.

%my-placeholder {
  background-color: blue;
  color: #222;
}

#my-selector {
  @extend %my-placeholder;
}

.my-selector {
  @extend %my-placeholder;
}

This results in the following:

#my-selector, .my-selector {
  background-color: blue;
  color: #222;
}

Hope that helps.

Jonathan Grieve
MOD
Jonathan Grieve
Treehouse Moderator 91,252 Points
Jonathan Grieve
Jonathan Grieve
Treehouse Moderator 91,252 Points

There is a lot of repetition in Sass, but that's why it exists. Sass takes as much repetition away from you as possible while you're developing the code and outputs the repetition as vanilla CSS.

I don't think it's possible to completely take away non DRY code in any workflow but it's a worthy goal to try and reduce it as much as possible. And Sass, if you can learn to master it is an awesome way to do it. :-)

Nicolas Hampton
Nicolas Hampton
44,638 Points
Nicolas Hampton
Nicolas Hampton
44,638 Points

I think the main concerns when dealing with this are readability, maintainability and scale. When you get 600 lines deep into a css file, keeping it organized and sectioned will make it workable... for the next week. Try coming back to it 2 months later and trying to track your thought process. Even with good comments and sections, it can be daunting, and a lot of hunting for the same colors and pixel sizes is involved. Sass makes it very easy to read and modify the code, so changing the entire color scheme of a website and all pages takes about 5 minutes instead of a very painful day or two. Too often, as some of us are new coders or just stuck in our ways, we right off readability as second to functionality, but readability IS functionality: the ability to work with the code, for others and in the long run. If anything we take away from this, a very important and obvious skill to anyone hiring and working with us is whether the projects you pass off to clients and co-workers is something others can work on. It's one thing to pass off a radio made of a jumble of wires no one can sort through, and another to pass of a clean, finished DIY radio kit a child could follow and build. Make it look good, but most importantly, a finished project should make it look easy.

Unsubscribed User
Unsubscribed User
14,667 Points

Thanks for your answer. I get your point and I agree to that. I am using Sass for a while and I really see the use of it now. Also I know more of the several solutions and when to use mixins and when not to use them.

I guess my main concern was that it is easy to use Sass in a wrong way, which creates messy output. Actually the problem then isn't Sass itself, but the person writing it and using it wrong.

Nicolas Hampton
Nicolas Hampton
44,638 Points

I see a lot of that possibility for misuse as well, Sanne. But these days, a lot of code is using jquery grabs for something that could easily be done with a few lines of css, or an ugly chunk of html that's meant to hide that someone doesn't understand display:inline. Let's not even talk about the mazes I've refactored my own code out of. So I agree, some people are going to use this screwdriver as a hammer, but in most cases, I think it's not the screwdriver's fault. Though I was reading a post I found in a Nick Pettit class about some common misdesign of our most base tools, and that has me thinking, and I have been enjoying Angular a lot. http://acko.net/blog/shadow-dom/

Unsubscribed User
Unsubscribed User
14,667 Points
Unsubscribed User
Unsubscribed User
14,667 Points

Thanks for your quick responses. :-)

I guess it's just a little restraint from my side, because I never really worked with pre-processors and it gives me the idea that I won't be writing 'real CSS' anymore and I will lose control of the output. However if you keep track of the output and check if your Sass code is compiled well it might be a nice solution.

Michael Plemmons
Michael Plemmons
9,393 Points
Michael Plemmons
Michael Plemmons
9,393 Points

for this simple example I would think it would be easier to just do this:

.box .button { border-radius: 4px 8px; // 4px top left bottom right, 8px top right bottom left }

.button { background: #345; }