Sass Fundamentals

Default Argument Values

Sass Fundamentals

Check out a free preview of the full Sass Fundamentals course

The "Default Argument Values" Lesson is part of the full, Sass Fundamentals course featured in this preview video. Here's what you'd learn in this lesson:

Passing arguments through mixins, Mike demonstrates how to extend the power of writing CSS rules with Sass.


Transcript from the "Default Argument Values" Lesson

>> Mike North: We're going to build on what we've learned so far about Mixins. And start to layer on some more advanced Mixin topics. The first thing we're going to look at is the idea of default argument values. These would be the values that variables that are arguments to your Mixin would get the values the variables would have in the event that you didn't pass anything to the Mixin for that value.

And in this case, I'm also introducing this concept of passing arguments to Mixins in order, or passing them using the keyword style of argument passing, which is at the bottom here. Where you can see that I'm using the variable name color and assigning it equal to green, and so this is sort of using key value pairs.

On the bottom, right, using color green. If you pass arguments this way, there is no dependence on order, on argument order. And so, this is useful if you've got like three or four different things and for two of them you wanna fall back to a default value. You can provide default values for everything, and then customize the first argument or the second argument or the third argument.

It's pretty flexible, in fact there are things you can do here that are a little bit more flexible than what you can do with JavaScript functions. Where default values typically need to be the last arguments in a function, right? You can't like pick the third one to customize that also explicitly passing the first two.

So cool thing to know, especially if you're reading CSS you will encounter this and wonder what the heck is going on. This is what's going on. I'm just gonna switch by mirroring here real quick. Right, building on this topic of default values, something interesting happens if we pass null as a default value.

What ends up happening in the CSS output is, we will skip over the declaration with a null value entirely. It will not get built into the output at all. So in this case you can see opacity's default value is null for the btn style role here. You can see that opacity never makes its way into the CSS in any form.

So you don't have to worry about inherit or falling back to some reasonable default of 1, 1.0 being the default opacity. You can just skip over it entirely, and it will be like this role was never expressed. So really useful aspect of default values to use. Now up until now, Mixins have acted just sort of like functions that evaluate to something.

And you get a style rules and they're sort of merged into the selector, inside which the Mixin is used. Of building even one step on top of this, we have the equivalent of a callback, right, of the idea of passing something to a Mixin that it could then place where it wants to in the Mixins definition.

We can pass a declaration block when we include a Mixin. So here we've got a Mixin called foo that takes in a color value. And you can see that it uses the variable. And then it has this @content declaration there. Essentially, what's gonna happen is the block that's passed to this Mixin will be put in place of that content, right?

So over here on the right, you can see, we passed color red to the Mixin and that is applied to the inner selector as a rule here. And you can actually have the content rendered more than once, which is a really nice feature if you have to target vendor specific tags.

So if you've ever done something like styling pseudo elements of a number spinner, like an input number helper thing with the up arrow and the down arrow. And like you can style these things. But there's a WebKit specific thing to do, and there's a Mozilla specific thing to do.

And largely that's the same rule applied in two places, but It's a different pseudo selector for each. And you could just have the content in two places inside your Mixin, and it would end up being rendered twice, potentially, with the couple extra Mozilla or Safari customization in place, right?

So pretty nice. And I also like to use this passing a declaration block for media queries, right? I hate having to remember the syntax for a media query and exactly what those screen widths are. So I can create a Mixin that just called like phone, and its job is gonna be to have a media query and then content immediately in there.

And so it's a much more manageable and readable way of kind of wrapping some CSS in something, right? Something that's long and difficult to remember. Keeping my styles easy to manage and easy to read. And avoiding that tendency to like miss a media query by 1 pixel, cuz you can't remember like do I lead up to this width or do I fall just short of it before I toggle over to the next break point.

This would kind of let you skirt over that, and have a dry approach to writing really long selectors in general, right? Dry meaning, don't repeat yourself.
>> Mike North: So here we can pass in a block, and here we use content to place whatever was passed to the Mixin. In the correct spot, and it's the Mixins job to define exactly where that goes.

>> Speaker 2: So if we didn't pass in content, would that inner just not be output?
>> Mike North: Good question, so if no content block had been passed to foo, what you would end up with is your SASS would have an empty inner block. And then there is an optimization in the SASS compiler that would skip over that entirely, cuz there's no point in serializing the CSS equivalent out.

Now if we had another rule in the inner, like you would get that inner block, but it essentially turns into a no up, right? You didn't end up with like It turning into nothing. Good question. So we're going to put this to use right away, including all the stuff we've learned so far.

These exercise is a little bit more sizable than what we've been working on before, and it's a little bit more free form as well.

Learn Straight from the Experts Who Shape the Modern Web

  • In-depth Courses
  • Industry Leading Experts
  • Learning Paths
  • Live Interactive Workshops
Get Unlimited Access Now