{"id":280768,"date":"2019-01-08T07:56:07","date_gmt":"2019-01-08T14:56:07","guid":{"rendered":"http:\/\/css-tricks.com\/?p=280768"},"modified":"2020-05-12T16:36:46","modified_gmt":"2020-05-12T23:36:46","slug":"sass-techniques-from-the-trenches","status":"publish","type":"post","link":"https:\/\/css-tricks.com\/sass-techniques-from-the-trenches\/","title":{"rendered":"Sass Techniques from the Trenches"},"content":{"rendered":"\n<p>Having been in the web development industry for more than 14 years, I\u2019ve seen and written my fair share of good and bad CSS. When I began at <a href=\"https:\/\/www.daveramsey.com\/\" rel=\"noopener\">Ramsey Solutions<\/a> five years ago, I was introduced to Sass. It blew my mind how useful it was! I dove right in and wanted to learn <em>everything<\/em> I could about it. Over the past five years, I\u2019ve utilized a number of different Sass techniques and patterns and fell in love with some that, to steal Apple\u2019s phrase, <em>just work<\/em>.<\/p>\n\n\n\n<!--more-->\n\n\n\n<p>In this article, I\u2019ll explore a wide range of topics:<\/p>\n\n\n\n<ul><li><a href=\"https:\/\/css-tricks.com\/sass-techniques-from-the-trenches#article-header-id-0\">The power of the ampersand<\/a><\/li><li><a href=\"https:\/\/css-tricks.com\/sass-techniques-from-the-trenches#article-header-id-1\">Variables and scoping<\/a><\/li><li><a href=\"https:\/\/css-tricks.com\/sass-techniques-from-the-trenches#article-header-id-2\">The importance of imports<\/a><\/li><li><a href=\"https:\/\/css-tricks.com\/sass-techniques-from-the-trenchese#article-header-id-3\">Mixin&#8217; it up<\/a><\/li><li><a href=\"https:\/\/css-tricks.com\/sass-techniques-from-the-trenches#article-header-id-4\">Getting functional<\/a><\/li><li><a href=\"https:\/\/css-tricks.com\/sass-techniques-from-the-trenchese#article-header-id-5\">The selector order that placeholders mess up<\/a><\/li><\/ul>\n\n\n\n<p>In my experience, finding the balance between simple and complex is the crucial component to making great software. Software should not only be easy for people to use, but for you and other developers to maintain in the future. I\u2019d consider these techniques to be advanced, but not necessarily clever or complex, on purpose!<\/p>\n\n\n\n<blockquote class=\"wp-block-quote is-layout-flow wp-block-quote-is-layout-flow\"><p>&#8220;Everyone knows that debugging is twice as hard as writing a program in the first place. So if you\u2019re as clever as you can be when you write it, how will you ever debug it?&#8221;<\/p><p><em>\u2014The Elements of Programming and Style (2nd Edition), Chapter 2<\/em><\/p><\/blockquote>\n\n\n\n<p>With that in mind, let\u2019s first look at Sass\u2019 ampersand.<\/p>\n\n\n\n<hr class=\"wp-block-separator\"\/>\n\n\n<h3 class=\"wp-block-heading\" id=\"the-power-of-the-ampersand\">The power of the ampersand<\/h3>\n\n\n<p>There are many different naming conventions you can use to organize your CSS. The one I enjoy using the most is <a href=\"https:\/\/github.com\/suitcss\/suit\/blob\/master\/doc\/naming-conventions.md\" rel=\"noopener\">SUIT<\/a>, a variation of <a href=\"http:\/\/getbem.com\/\" rel=\"noopener\">BEM<\/a> (which is short for <strong>B<\/strong>lock, <strong>E<\/strong>lement, <strong>M<\/strong>odifier). If you\u2019re unfamiliar with SUIT or BEM, I\u2019d recommend taking a peek at one or both of them before moving on. I\u2019ll be using the SUIT convention throughout the rest of this article.<\/p>\n\n\n\n<p class=\"explanation\">Whatever naming convention you choose, the base idea is that every styled element gets its own class name, prepended with the component name. This idea is important for how some of the following organization works. Also, this article is <strong>descriptive, not prescriptive<\/strong>. Every project is different. You need to do what works best for your project and your team.<\/p>\n\n\n\n<p>The <a href=\"https:\/\/css-tricks.com\/the-sass-ampersand\/\">ampersand<\/a> is the main reason I like to use SUIT, BEM, and conventions like them. It allows me to use nesting and scoping without either biting back with specificity. Here\u2019s an example. Without using the ampersand, I would need to create separate selectors to create <code>-title<\/code> and <code>-content<\/code> elements.<\/p>\n\n\n\n<pre rel=\"SCSS\" class=\"wp-block-csstricks-code-block language-scss\" data-line=\"\"><code markup=\"tt\">.MyComponent {\n  .MyComponent-title {}\n}\n\n.MyComponent-content {}\n\n\/\/ Compiles to\n.MyComponent .MyComponent-title {} \/\/ Not what we want. Unnecessary specificity!\n.MyComponent-content {} \/\/ Desired result<\/code><\/pre>\n\n\n\n<p>When using SUIT, I want the second result for <code>-content<\/code> to be how I write all my selectors. To do so, I would need to repeat the name of the component throughout. This increases my chance to mistype the name of the component as I write new styles. It\u2019s also very noisy as it ends up ignoring the beginning of many selectors which can lead to glossing over obvious errors.<\/p>\n\n\n\n<pre rel=\"CSS\" class=\"wp-block-csstricks-code-block language-css\" data-line=\"\"><code markup=\"tt\">.MyComponent {}\n.MyComponent-title {}\n.MyComponent-content {}\n.MyComponent-author {}\n\/\/ Etc.<\/code><\/pre>\n\n\n\n<p>If this were normal CSS, we\u2019d be stuck writing the above. Since we\u2019re using Sass, there\u2019s a much better approach using the ampersand. The ampersand is amazing because it contains a reference to the current selector along with any parents.<\/p>\n\n\n\n<pre rel=\"SCSS\" class=\"wp-block-csstricks-code-block language-scss\" data-line=\"\"><code markup=\"tt\">.A {\n  \/\/ &amp; = '.A'\n  .B {\n    \/\/ &amp; = '.A .B'\n    .C {\n      \/\/ &amp; = '.A .B .C'\n    }\n  }\n}<\/code><\/pre>\n\n\n\n<p>You can see in the above example how the ampersand references each selector in the chain as it goes deeper into the nested code. By utilizing this feature, we can create new selectors without having to rewrite the name of the component each and every time.<\/p>\n\n\n\n<pre rel=\"SCSS\" class=\"wp-block-csstricks-code-block language-scss\" data-line=\"\"><code markup=\"tt\">.MyComponent {\n  &amp;-title {}\n  \n  &amp;-content {}\n}\n\n\/\/ Compiles to\n.MyComponent {}\n.MyComponent-title {}\n.MyComponent-content {}<\/code><\/pre>\n\n\n\n<p>This is great because we can take advantage of the ampersand to write the name of the component one time and simply reference the component name throughout. This decreases the chance that the component name is mistyped. Plus, the document as a whole becomes easier to read without <code>.MyComponent<\/code> repeated all over the code.<\/p>\n\n\n\n<hr class=\"wp-block-separator\"\/>\n\n\n\n<p>There are times when the component needs a <strong>variant<\/strong> or <strong>modifier<\/strong>, as they\u2019re called in SUIT and BEM. Using the ampersand pattern makes it easier to create modifiers.<\/p>\n\n\n\n<pre rel=\"HTML\" class=\"wp-block-csstricks-code-block language-markup\" data-line=\"\"><code markup=\"tt\">&lt;div class=\"MyComponent MyComponent--xmasTheme\">&lt;\/div><\/code><\/pre>\n\n\n\n<pre rel=\"SCSS\" class=\"wp-block-csstricks-code-block language-scss\" data-line=\"\"><code markup=\"tt\">.MyComponent {\n  &amp;--xmasTheme {}\n}\n\n\/\/ Compiles to\n.MyComponent {}\n.MyComponent--xmasTheme {}<\/code><\/pre>\n\n\n\n<p>&#8220;But, what about modifying the child elements?&#8221; you might ask. &#8220;How are those selectors created? The modifier isn\u2019t needed on <em>every<\/em> element, right?&#8221;<\/p>\n\n\n\n<p>This is where variables can help!<\/p>\n\n\n<h3 class=\"wp-block-heading\" id=\"variables-and-scoping\">Variables and scoping<\/h3>\n\n\n<p>In the past, I\u2019ve created modifiers a few different ways. Most of the time, I\u2019d rewrite the special theme name I want to apply when modifying the element.<\/p>\n\n\n\n<pre rel=\"SCSS\" class=\"wp-block-csstricks-code-block language-scss\" data-line=\"\"><code markup=\"tt\">.MyComponent {\n  &amp;-title {\n    .MyComponent--xmasTheme &amp; {\n    }\n  }\n  \n  &amp;-content {\n    .MyComponent--xmasTheme &amp; {\n    }\n  }\n}\n\n\/\/ Compiles to\n.MyComponent-title {}\n.MyComponent--xmasTheme .MyComponent-title {}\n.MyComponent-content {}\n.MyComponent--xmasTheme .MyComponent-content {}<\/code><\/pre>\n\n\n\n<p>This gets the job done, but I\u2019m back to rewriting the component name in multiple places, not to mention the modifier name. There\u2019s definitely a better way to do this. Enter Sass variables.<\/p>\n\n\n\n<p>Before we explore Sass variables with selectors, we need to understand how they\u2019re scoped. Sass variables have scope, just like they would in JavaScript, Ruby, or any other programming language. If declared outside of a selector, the variable is available to every selector in the document after its declaration.<\/p>\n\n\n\n<pre rel=\"SCSS\" class=\"wp-block-csstricks-code-block language-scss\" data-line=\"\"><code markup=\"tt\">$fontSize: 1.4rem;\n\n.a { font-size: $fontSize; }\n.b { font-size: $fontSize; }<\/code><\/pre>\n\n\n\n<p>Variables declared inside a selector are scoped <em>only<\/em> to that selector and its children.<\/p>\n\n\n\n<pre rel=\"SCSS\" class=\"wp-block-csstricks-code-block language-scss\" data-line=\"\"><code markup=\"tt\">$fontSize: 1.4rem;\n\n.MyComponent { \n  $fontWeight: 600;\n  font-size: $fontSize; \n  \n  &amp;-title {\n    font-weight: $fontWeight; \/\/ Works!\n  }\n}\n\n.MyComponent2 { \n  font-size: $fontSize; \n  \n  &amp;-title {\n    font-weight: $fontWeight; \/\/ produces an \"undefined variable\" error\n  }\n}<\/code><\/pre>\n\n\n\n<p>We know variables can store font names, integers, colors, etc. Did you know it can also store selectors? Using string interpolation, we can create new selectors with the variable.<\/p>\n\n\n\n<pre rel=\"SCSS\" class=\"wp-block-csstricks-code-block language-scss\" data-line=\"\"><code markup=\"tt\">\/\/ Sass string interpolation syntax is #{VARIABLE} \n$block: \".MyComponent\";\n\n#{$block} {\n  &amp;-title {\n    #{$block}--xmasTheme &amp; {\n    }\n  }\n}\n\n\/\/ Compiles to\n.MyComponent {}\n.MyComponent-title {}\n.MyComponent--xmasTheme .MyComponent-title {}<\/code><\/pre>\n\n\n\n<p>That\u2019s cool, but the variable is <a href=\"https:\/\/css-tricks.com\/regarding-csss-global-scope\/\">globally scoped<\/a>. We can fix that by creating the <code>$block<\/code> variable inside the component declaration, which would scope it to that component. Then we can re-use the <code>$block<\/code> variable in other components. This helps <abbr title=\"Do Not Repeat Yourself\">DRY<\/abbr> up the theme modifier.<\/p>\n\n\n\n<pre rel=\"SCSS\" class=\"wp-block-csstricks-code-block language-scss\" data-line=\"\"><code markup=\"tt\">.MyComponent {\n  $block: '.MyComponent';\n  \n  &amp;-title {\n    #{$block}--xmasTheme &amp; {\n    }\n  }\n  \n  &amp;-content {\n    #{$block}--xmasTheme &amp; {\n    }\n  }\n}\n\n\/\/ Compiles to\n.MyComponent {}\n.MyComponent-title {}\n.MyComponent--xmasTheme .MyComponent-title {}\n.MyComponent-content {}\n.MyComponent--xmasTheme .MyComponent-content {}<\/code><\/pre>\n\n\n\n<p>This is closer, but again, we have to write the theme name over and over. Let\u2019s store that in a variable too!<\/p>\n\n\n\n<pre rel=\"SCSS\" class=\"wp-block-csstricks-code-block language-scss\" data-line=\"\"><code markup=\"tt\">.MyComponent {\n  $block: '.MyComponent';\n  $xmasTheme: '.MyComponent--xmasTheme';\n  \n  &amp;-title {\n    #{$xmasTheme} &amp; {\n    }\n  }\n}<\/code><\/pre>\n\n\n\n<p>This is much better! However, we can improve this <em>even further<\/em>. Variables can also store the value of the ampersand!<\/p>\n\n\n\n<pre rel=\"SCSS\" class=\"wp-block-csstricks-code-block language-scss\" data-line=\"\"><code markup=\"tt\">.MyComponent {\n  $block: &amp;;\n  $xmasTheme: #{&amp;}--xmasTheme;\n  \n  &amp;-title {\n    #{$xmasTheme} &amp; {\n    }\n  }\n}\n\n\/\/ Still compiles to\n.MyComponent {}\n.MyComponent-title {}\n.MyComponent--xmasTheme .MyComponent-title {}<\/code><\/pre>\n\n\n\n<p>Now <em>that\u2019s<\/em> what I\u2019m talking about! &#8220;Caching&#8221; the selector with ampersand allows us to create our modifiers at the top and keep the theme modifications with the element it\u2019s modifying.<\/p>\n\n\n\n<p>&#8220;Sure, that works at the top level,&#8221; you say. &#8220;But what if you are nested really deep, like eight levels in?&#8221; You ask great questions.<\/p>\n\n\n\n<figure class=\"wp-block-image align-left media-280778\"><img decoding=\"async\" src=\"https:\/\/i0.wp.com\/css-tricks.com\/wp-content\/uploads\/2019\/01\/sass-trenches-01.jpg?ssl=1\" alt=\"\" data-recalc-dims=\"1\"\/><\/figure>\n\n\n\n<p>No matter how deep the nest, this pattern always works because the main component name is never attached to any of the children, thanks to the SUIT naming convention and ampersand combo.<\/p>\n\n\n\n<pre rel=\"SCSS\" class=\"wp-block-csstricks-code-block language-scss\" data-line=\"\"><code markup=\"tt\">.MyComponent { \n  $block: &amp;;\n  $xmasTheme: #{&amp;}--xmasTheme;\n  \n  &amp;-content {\n    font-size: 1.5rem;\n    color: blue;\n    \n    ul {\n      li {\n        strong {\n          span {\n            &amp;::before {\n              background-color: blue;\n              \n              #{$xmasTheme} &amp; {\n                background-color: red;\n              }\n            }\n          }\n        }\n      }\n    }\n  }\n}\n\n\/\/ Compiles to \n.MyComponent-content {\n  font-size: 1.5rem;\n  color: blue;\n}\n\n.MyComponent-content ul li strong span::before {\n  background-color: blue;\n}\n\n\/*\n* The theme is still appended to the beginning of the selector!\n* Now, we never need to write deeply nested Sass that's hard to maintain and \n* extremely brittle: https:\/\/css-tricks.com\/sass-selector-combining\/\n*\/\n.MyComponent--xmasTheme .MyComponent-content ul li strong span::before {\n  background-color: red;\n}<\/code><\/pre>\n\n\n\n<p>Code organization is the main reason I like to use this pattern.<\/p>\n\n\n\n<ul><li>It\u2019s relatively DRY<\/li><li>It supports the &#8220;opt-in&#8221; approach, which keeps modifiers with the elements they modify<\/li><li>Naming stuff is hard but this enables us to reuse common element names like &#8220;title&#8221; and &#8220;content&#8221;<\/li><li>It\u2019s low-lift to add a modifier to a component by placing the modifier class on the parent component<\/li><\/ul>\n\n\n\n<p>&#8220;Hhhmmmmm&#8230; doesn\u2019t that get hard to read though after you create a bunch of different components? How do you know where you\u2019re at when everything is named <code>&amp;-title<\/code> and <code>&amp;-content<\/code>?&#8221;<\/p>\n\n\n\n<p>You continue to ask great questions. Who said the <em>source<\/em> Sass had to be in one file? We can import those components, so let\u2019s turn to that topic!<\/p>\n\n\n<h3 class=\"wp-block-heading\" id=\"the-importance-of-imports\">The importance of imports<\/h3>\n\n\n<figure class=\"wp-block-image align-left media-280779\"><img decoding=\"async\" src=\"https:\/\/i0.wp.com\/css-tricks.com\/wp-content\/uploads\/2019\/01\/sass-trenches-02.jpg?ssl=1\" alt=\"\" data-recalc-dims=\"1\"\/><figcaption>Credit: <a href=\"https:\/\/twitter.com\/@Julien_He\" rel=\"noopener\">@Julien_He<\/a><\/figcaption><\/figure>\n\n\n\n<p>One of Sass\u2019 best features is <code>@import<\/code>. We can create separate Sass files (partials) and import them into other Sass files that compile together with the imported file located at the spot it\u2019s imported. This makes it easy to package up related styles for components, utilities, etc. and pull them into a single file. Without <code>@import<\/code>, we\u2019d need to link to separate CSS files (creating <em>numerous<\/em> network requests, which is <a href=\"https:\/\/www.youtube.com\/watch?v=9DW6Gz0N6Hs\" rel=\"noopener\">badong<\/a>) or write everything in a single stylesheet (which is tough to navigate and maintain).<\/p>\n\n\n\n<pre rel=\"SCSS\" class=\"wp-block-csstricks-code-block language-scss\" data-line=\"\"><code markup=\"tt\">.Component1 {\n  &amp;-title {}\n  &amp;-content {}\n  &amp;-author {}\n}\n\n.Component2 {\n  &amp;-title {}\n  &amp;-content {}\n  &amp;-author {}\n}\n\n.Component3 {\n  &amp;-title {}\n  &amp;-content {}\n  &amp;-author {}\n}\n\n.Component4 {\n  &amp;-title {}\n  &amp;-content {}\n  &amp;-author {}\n}\n\n.Component5 {\n  &amp;-title {}\n  &amp;-content {}\n  &amp;-author {}\n}\n\n\/\/ A couple of hundred lines later...\n\n.Component7384 {\n  &amp;-title {}\n  &amp;-content {}\n  &amp;-author {}\n}\n\n\/\/ WHERE AM I?<\/code><\/pre>\n\n\n\n<p>One of the more popular methodologies for organizing Sass files is the <a href=\"https:\/\/sass-guidelin.es\/#the-7-1-pattern\" rel=\"noopener\">7-1 Pattern<\/a>. That\u2019s seven distinct folders containing Sass files that are imported into a single Sass file.<\/p>\n\n\n\n<p>Those folders are:<\/p>\n\n\n\n<ul><li>abstracts<\/li><li>base<\/li><li>components<\/li><li>layout<\/li><li>pages<\/li><li>themes<\/li><li>vendor<\/li><\/ul>\n\n\n\n<p>Use <code>@import<\/code> to pull each Sass file in those folder into a main Sass file. We want to import them in the following order to maintain good scope and avoid conflicts during compilation:<\/p>\n\n\n\n<ol><li>abstracts<\/li><li>vendor<\/li><li>base<\/li><li>layout<\/li><li>components<\/li><li>pages<\/li><li>themes<\/li><\/ol>\n\n\n\n<pre rel=\"SCSS\" class=\"wp-block-csstricks-code-block language-scss\" data-line=\"\"><code markup=\"tt\">@import 'abstracts\/variables';\n@import 'abstracts\/functions';\n@import 'abstracts\/mixins';\n\n@import 'vendors\/some-third-party-component';\n\n@import 'base\/normalize';\n\n@import 'layout\/navigation';\n@import 'layout\/header';\n@import 'layout\/footer';\n@import 'layout\/sidebar';\n@import 'layout\/forms';\n\n@import 'components\/buttons';\n@import 'components\/hero';\n@import 'components\/pull-quote';\n\n@import 'pages\/home';\n@import 'pages\/contact';\n\n@import 'themes\/default';\n@import 'themes\/admin';<\/code><\/pre>\n\n\n\n<p>You may or may not want to use all of these folders (I personally don\u2019t use the theme folder since I keep themes with their components), but the idea of separating all of styles into distinct files makes it easier to maintain and find code.<\/p>\n\n\n\n<p>More of the benefits of using this approach:<\/p>\n\n\n\n<ul><li>Small components are easier to read and understand<\/li><li>Debugging becomes simpler<\/li><li>It\u2019s clearer to determine when a new component should be created \u2014 like when a single component file gets to be <em>too long<\/em>, or the selector chain is too complex<\/li><li>This emphasizes re-usage \u2014 for example, it might make sense to generalize three component files that essentially do the same thing into one component<\/li><\/ul>\n\n\n\n<p>Speaking of re-usage, there are eventually patterns that get used often. That\u2019s when we can reach for mixins.<\/p>\n\n\n<h3 class=\"wp-block-heading\" id=\"mixin-it-up\">Mixin\u2019 it up<\/h3>\n\n\n<p>Mixins are a great way to reuse styles throughout a project. Let\u2019s walk through creating a simple mixin and then give it a little bit of intelligence.<\/p>\n\n\n\n<p>The designer I work with on a regular basis always sets <code>font-size<\/code>, <code>font-weight<\/code>, and <code>line-height<\/code> to specific values. I found myself typing all three out every time I needed to adjust the fonts for a component or element, so I created a mixin to quickly set those values. It\u2019s like a little function I can use to define those properties without having to write them in full.<\/p>\n\n\n\n<pre rel=\"SCSS\" class=\"wp-block-csstricks-code-block language-scss\" data-line=\"\"><code markup=\"tt\">@mixin text($size, $lineHeight, $weight) {\n  font-size: $size;\n  line-height: $lineHeight;\n  font-weight: $weight;\n}<\/code><\/pre>\n\n\n\n<p>At this point, the mixin is pretty simple\u2014it resembles something like a function in JavaScript. There\u2019s the name of the mixin (<code>text<\/code>) and it takes in three arguments. Each argument is tied to a CSS property. When the mixin is called, Sass will copy the properties and the pass in the argument values.<\/p>\n\n\n\n<pre rel=\"SCSS\" class=\"wp-block-csstricks-code-block language-scss\" data-line=\"\"><code markup=\"tt\">.MyComponent {\n  @include text(18px, 27px, 500);\n}\n\n\/\/ Compiles to\n.MyComponent {\n  font-size: 18px;\n  line-height: 27px;\n  font-weight: 500;\n}<\/code><\/pre>\n\n\n\n<p>While it\u2019s a good demonstration, this particular mixin is a little limited. It assumes we always want to use the <code>font-size<\/code>, <code>line-height<\/code>, and <code>font-weight<\/code> properties when it\u2019s called. So let\u2019s use Sass\u2019 <code>if<\/code> statement to help control the output.<\/p>\n\n\n\n<pre rel=\"SCSS\" class=\"wp-block-csstricks-code-block language-scss\" data-line=\"\"><code markup=\"tt\">@mixin text($size, $lineHeight, $weight) {\n  \/\/ If the $size argument is not empty, then output the argument\n  @if $size != null {\n    font-size: $size;\n  }\n  \n  \/\/ If the $lineHeight argument is not empty, then output the argument\n  @if $lineHeight != null {\n    line-height: $lineHeight;\n  }\n  \n  \/\/ If the $weight argument is not empty, then output the argument\n  @if $weight != null {\n    font-weight: $weight;\n  }\n}\n\n.MyComponent {\n  @include text(12px, null, 300);\n}\n\n\/\/ Compiles to\n.MyComponent {\n  font-size: 12px;\n  font-weight: 300;\n}<\/code><\/pre>\n\n\n\n<p>That\u2019s better, but not quite there. If I try to use the mixin without using <code>null<\/code> as a parameter on the values I don\u2019t want to use or provide, Sass will generate an error:<\/p>\n\n\n\n<pre rel=\"SCSS\" class=\"wp-block-csstricks-code-block language-scss\" data-line=\"\"><code markup=\"tt\">.MyComponent {\n  @include text(12px, null); \/\/ left off $weight\n}\n\n\/\/ Compiles to an error:\n\/\/ \"Mixin text is missing argument $weight.\"<\/code><\/pre>\n\n\n\n<p>To get around this, we can add default values to the parameters, allowing us to leave them off the function call. All optional parameters have to be declared after any required parameters.<\/p>\n\n\n\n<pre rel=\"SCSS\" class=\"wp-block-csstricks-code-block language-scss\" data-line=\"\"><code markup=\"tt\">\/\/ We define `null` as the default value for each argument\n@mixin text($size: null, $lineHeight: null, $weight: null) {\n  @if $size != null {\n    font-size: $size;\n  }\n  \n  @if $lineHeight != null {\n    line-height: $lineHeight;\n  }\n  \n  @if $weight != null {\n    font-weight: $weight;\n  }\n}\n\n.MyComponent {\n  &amp;-title {\n    @include text(16px, 19px, 600);\n  }\n  \n  &amp;-author {\n    @include text($weight: 800, $size: 12px);\n  }\n}\n\n\/\/ Compiles to\n.MyComponent-title {\n  font-size: 16px;\n  line-height: 19px;\n  font-weight: 600;\n}\n\n.MyComponent-author {\n  font-size: 12px;\n  font-weight: 800;\n}<\/code><\/pre>\n\n\n\n<p>Not only do default argument values make the mixin easier to use, but we also gain the ability to name parameters and give them values that may be commonly used. On Line 21 above, the mixin is being called with the arguments out of order, but since the values are being called out as well, the mixin knows how to apply them.<\/p>\n\n\n\n<hr class=\"wp-block-separator\"\/>\n\n\n\n<p>There\u2019s a particular mixin that I use on a daily basis: <code>min-width<\/code>. I prefer to create all my sites mobile first, or basically with the smallest viewport in mind. As the viewport grows wider, I define breakpoints to adjust the layout and the code for it. This is where I reach for the <code>min-width<\/code> mixin.<\/p>\n\n\n\n<pre rel=\"SCSS\" class=\"wp-block-csstricks-code-block language-scss\" data-line=\"\"><code markup=\"tt\">\/\/ Let's name this \"min-width\" and take a single argument we can\n\/\/ use to define the viewport width in a media query.\n@mixin min-width($threshold) {\n  \/\/ We're calling another function (scut-rem) to convert pixels to rem units.\n  \/\/ We'll cover that in the next section.\n  @media screen and (min-width: scut-rem($threshold)) {\n    @content;\n  }\n}\n\n.MyComponent {\n  display: block;\n  \n  \/\/ Call the min-width mixin and pass 768 as the argument.\n  \/\/ min-width passes 768 and scut-rem converts the unit.\n  @include min-width(768) {\n    display: flex;\n  }\n}\n\n\/\/ Compiles to \n.MyComponent {\n  display: block;\n}\n\n@media screen and (min-width: 48rem) {\n  .MyComponent {\n    display: flex;\n  }\n}<\/code><\/pre>\n\n\n\n<p>There are a couple of new ideas here. The mixin has a nested function called <code>@content<\/code>. So, in the <code>.MyComponent<\/code> class, we\u2019re no longer calling the mixin alone, but also a block of code that gets output inside the media query that\u2019s generated. The resulting code will compile where <code>@content<\/code> is called. This allows the mixin to take care of the <code>@media<\/code> declaration and still accept custom code for that particular breakpoint.<\/p>\n\n\n\n<p>I also am including the mixin within the <code>.MyComponent<\/code> declaration. Some people advocate keeping all responsive calls in a separate stylesheet to reduce the amount of times <code>@media<\/code> is written out in a stylesheet. Personally, I prefer to keep all variations and changes that a component can go through with that component\u2019s declaration. It tends to make it easier to keep track of what\u2019s going on and help debug the component if something doesn\u2019t go right, rather than sifting through multiple files.<\/p>\n\n\n\n<p>Did you notice the <code>scut-rem<\/code> function in there? That is a Sass function taken from a Sass library called <a href=\"https:\/\/davidtheclark.github.io\/scut\/\" rel=\"noopener\">Scut<\/a>, created by David The Clark. Let\u2019s take a look at how that works.<\/p>\n\n\n<h3 class=\"wp-block-heading\" id=\"getting-functional\">Getting functional<\/h3>\n\n\n<p>A function differs from a mixin in that mixins are meant to output common groups of properties, while a function modifies properties based on arguments that return a new result. In this case, <code>scut-rem<\/code> takes a pixel value and converts it to a rem value. This allows us to think in pixels, while working with rem units behind the scenes to avoid all that math.<\/p>\n\n\n\n<p>I\u2019ve simplified <code>scut-rem<\/code> in this example because it has a few extra features that utilize loops and lists, which are out of the scope of what we\u2019re covering here. Let\u2019s look at the function in its entirety, then break it down step-by-step.<\/p>\n\n\n\n<pre rel=\"SCSS\" class=\"wp-block-csstricks-code-block language-scss\" data-line=\"\"><code markup=\"tt\">\/\/ Simplified from the original source\n$scut-rem-base: 16 !default;\n\n@function scut-strip-unit ($num) {\n  @return $num \/ ($num * 0 + 1);\n}\n\n@function scut-rem ($pixels) {\n  @return scut-strip-unit($pixels) \/ $scut-rem-base * 1rem;\n}\n\n.MyComponent {\n  font-size: scut-rem(18px);  \n}\n\n\/\/ Compiles to\n.MyComponent {\n  font-size: 1.125rem;\n}<\/code><\/pre>\n\n\n\n<p>The first thing to note is the declaration on Line 2. It\u2019s using <code>!default<\/code> when declaring a variable, which tells Sass to set the value to 16 <em>unless this variable is already defined<\/em>. So if a variable is declared earlier in the stylesheet with a different value, it won\u2019t be overridden here.<\/p>\n\n\n\n<pre rel=\"SCSS\" class=\"wp-block-csstricks-code-block language-scss\" data-line=\"\"><code markup=\"tt\">$fontSize: 16px;\n$fontSize: 12px !default;\n\n.MyComponent {\n  font-size: $fontSize;\n}\n\n\/\/ Compiles to\n.MyComponent {\n  font-size: 16px;\n}<\/code><\/pre>\n\n\n\n<p>The next piece of the puzzle is <code>scut-strip-unit<\/code>. This function takes a px, rem, percent or other suffixed value and removes the unit label. Calling <code>scut-strip-unit(12px)<\/code> returns 12 instead of 12px. How does that work? In Sass, a unit divided by another unit of the same type will strip the unit and return the digit.<\/p>\n\n\n\n<pre rel=\"HTML\" class=\"wp-block-csstricks-code-block language-markup\" data-line=\"\"><code markup=\"tt\">12px \/ 1px = 12<\/code><\/pre>\n\n\n\n<p>Now that we know that, let\u2019s look at the <code>scut-strip-unit<\/code> function again.<\/p>\n\n\n\n<pre rel=\"SCSS\" class=\"wp-block-csstricks-code-block language-scss\" data-line=\"\"><code markup=\"tt\">@function scut-strip-unit ($num) {\n  @return $num \/ ($num * 0 + 1);\n}<\/code><\/pre>\n\n\n\n<p>The function takes in a unit and divides it by 1 of the same unit. So if we pass in 12px, the function would look like: <code>@return 12px \/ (12px * 0 + 1)<\/code>. Following the <a href=\"http:\/\/mathworld.wolfram.com\/PEMDAS.html\" rel=\"noopener\">order of operations<\/a>, Sass evaluates what\u2019s in the parentheses first. Sass smartly ignores the <code>px<\/code> label, evaluates the expression, and tacks <code>px<\/code> back on once it\u2019s done: <code>12 * 0 + 1 = 1px<\/code>. The equation is now <code>12px \/ 1px<\/code> which we know returns 12.<\/p>\n\n\n\n<p>Why is this important to <code>scut-rem<\/code>? Looks look at it again.<\/p>\n\n\n\n<pre rel=\"SCSS\" class=\"wp-block-csstricks-code-block language-scss\" data-line=\"\"><code markup=\"tt\">$scut-rem-base: 16 !default;\n\n@function scut-rem ($pixels) {\n  @return scut-strip-unit($pixels) \/ $scut-rem-base * 1rem;\n}\n\n.MyComponent {\n  font-size: scut-rem(18px);  \n}<\/code><\/pre>\n\n\n\n<p>On Line 4, the <code>scut-strip-unit<\/code> function removes <code>px<\/code> from the argument and returns <code>18<\/code>. The base variable is equal to <code>16<\/code> which turns the equation into: <code>18 \/ 16 * 1rem<\/code>. Remember, Sass ignores any unit until the end of the equation, so <code>18 \/ 16 = 1.125<\/code>. That result multiplied by <code>1rem<\/code> gives us <code>1.125rem<\/code>. Since Scut strips the unit off of the argument, we can call <code>scut-rem<\/code> with unit-less values, like <code>scut-rem(18)<\/code>.<\/p>\n\n\n\n<p>I don\u2019t write that many functions because I try to keep the stuff I create as simple as possible. Being able to do some complex conversions using something like <code>scut-rem<\/code> is helpful though.<\/p>\n\n\n<h3 class=\"wp-block-heading\" id=\"the-selector-order-that-placeholders-mess-up\">The selector order that placeholders mess up<\/h3>\n\n\n<figure class=\"wp-block-image size-large\"><img loading=\"lazy\" decoding=\"async\" width=\"590\" height=\"350\" src=\"https:\/\/i0.wp.com\/css-tricks.com\/wp-content\/uploads\/2019\/01\/s_AEC826C4342602287E093B460A3F3347EF5DB3BC156C3A8539B2175D342907EA_1544067644164_yoda.jpg?resize=590%2C350&#038;ssl=1\" alt=\"\" class=\"wp-image-280780\" srcset=\"https:\/\/i0.wp.com\/css-tricks.com\/wp-content\/uploads\/2019\/01\/s_AEC826C4342602287E093B460A3F3347EF5DB3BC156C3A8539B2175D342907EA_1544067644164_yoda.jpg?w=590&amp;ssl=1 590w, https:\/\/i0.wp.com\/css-tricks.com\/wp-content\/uploads\/2019\/01\/s_AEC826C4342602287E093B460A3F3347EF5DB3BC156C3A8539B2175D342907EA_1544067644164_yoda.jpg?resize=300%2C178&amp;ssl=1 300w\" sizes=\"(min-width: 735px) 864px, 96vw\" data-recalc-dims=\"1\" \/><figcaption>End up where I think it did, that CSS?<\/figcaption><\/figure>\n\n\n<h4 class=\"wp-block-heading\" id=\"be-careful-what-is-extended\">Be careful what is extended<\/h4>\n\n\n<p>I tried writing out some examples to demonstrate why using <code>@extend<\/code> can be problematic, but I have used them so little that I can\u2019t create any decent examples. When I first learned Sass, I was surrounded by teammates who\u2019ve already gone through the trials and tribulations. My friend Jon Bebee wrote an extremely <a href=\"https:\/\/codepen.io\/somethingkindawierd\/post\/scss-unexpected-extend-matching\" rel=\"noopener\">excellent article<\/a> on how <code>@extend<\/code> can get you into trouble. It\u2019s a quick read and worth the time, so I\u2019ll wait.<\/p>\n\n\n<h4 class=\"wp-block-heading\" id=\"about-those-placeholders\">About those placeholders&#8230;<\/h4>\n\n\n<p>Jon proposes using placeholders as a solution to the problem he outlines: Placeholders don\u2019t output any code until they\u2019re used with <code>@extend<\/code>.<\/p>\n\n\n\n<pre rel=\"SCSS\" class=\"wp-block-csstricks-code-block language-scss\" data-line=\"\"><code markup=\"tt\">\/\/ % denotes an extended block\n%item {\n  display: block;\n  width: 50%;\n  margin: 0 auto;\n}\n\n.MyComponent {\n  @extend %item;\n  color: blue;\n}\n\n\/\/ Compiles to\n.MyComponent {\n  display: block;\n  width: 50%;\n  margin: 0 auto;\n}\n\n.MyComponent {\n  color: blue;\n}<\/code><\/pre>\n\n\n\n<figure class=\"wp-block-image size-large\"><img loading=\"lazy\" decoding=\"async\" width=\"575\" height=\"304\" src=\"https:\/\/i0.wp.com\/css-tricks.com\/wp-content\/uploads\/2019\/01\/sass-trenches-03.gif?resize=575%2C304&#038;ssl=1\" alt=\"\" class=\"wp-image-280782\" data-recalc-dims=\"1\"\/><\/figure>\n\n\n\n<p>OK, wait. So it output <code>.MyComponent<\/code> twice? Why didn\u2019t it simply combine the selectors?<\/p>\n\n\n\n<p>These are the questions I had when I first started using placeholders (and then subsequently stopped). The clue is the name itself. Placeholders simply hold a reference to the place in the stylesheet they were declared. While a mixin copies the properties to the location it is used, placeholders copy the selector to the place where the placeholder was defined. As a result, it copies the <code>.MyComponent<\/code> selector and places it where <code>%item<\/code> is declared. Consider the following example:<\/p>\n\n\n\n<pre rel=\"SCSS\" class=\"wp-block-csstricks-code-block language-scss\" data-line=\"\"><code markup=\"tt\">%flexy {\n  display: flex;\n}\n\n.A {\n  color: blue;\n}\n\n.B {\n  @extend %flexy;\n  color: green;\n}\n\n.C {\n  @extend %flexy;\n  color: red;\n}\n\n\/\/ Compiles to\n.B, .C {\n  display: flex;\n}\n\n.A {\n  color: blue;\n}\n\n.B {\n  color: green;\n}\n\n.C {\n  color: red;\n}<\/code><\/pre>\n\n\n\n<p>Even though B and C are declared further down in the stylesheet, the placeholder places the extended properties tall the way up to where it was originally declared. That\u2019s not a big deal in this example because it\u2019s really close to the source where it\u2019s used. However, if we\u2019re adhering to something like the 7-1 Pattern we covered earlier, then placeholders would be defined in a partial in the abstracts folder, which is one of the first imported files. That puts a lot of style between where the extend is intended and where it\u2019s actually used. That can be hard to maintain as well as hard to debug.<\/p>\n\n\n\n<p>Sass Guidelines (of course) does a great job covering <a href=\"https:\/\/sass-guidelin.es\/#extend\" rel=\"noopener\">placeholders and extend<\/a> and I would recommend reading it. It not only explains the extend feature, but at the end, advocates against using it:<\/p>\n\n\n\n<blockquote class=\"wp-block-quote is-layout-flow wp-block-quote-is-layout-flow\"><p>Opinions seem to be extremely divided regarding the benefits and problems from <code>@extend<\/code> to the point where many developers including myself have been advocating against it, [&#8230;]<\/p><\/blockquote>\n\n\n\n<hr class=\"wp-block-separator\"\/>\n\n\n\n<p>There are many other features of Sass I didn\u2019t cover here, like loops and lists, but I\u2019ve honestly haven\u2019t relied on those features as much as the ones we did cover in this article. Take a look through the Sass documentation, if for nothing else, to see what things do. You may not find a use for everything right away, but a situation may come up and having that knowledge in your back pocket is priceless.<\/p>\n\n\n\n<p>Let me know if I missed something or got something wrong! I\u2019m always open to new ideas and would love to discuss it with you!<\/p>\n\n\n<h4 class=\"wp-block-heading\" id=\"further-reading\">Further Reading<\/h4>\n\n\n<ul><li><a href=\"https:\/\/css-tricks.com\/sass-style-guide\/\">Sass Style Guide<\/a> &#8211; Thoughts and recommendations for keeping Sass clean and maintainable.<\/li><li><a href=\"https:\/\/css-tricks.com\/what-a-css-code-review-might-look-like\/\">What a CSS Code Review Might Look Like<\/a> &#8211; Predominantly looks at CSS, but includes tips to code review Sass files.<\/li><li><a href=\"https:\/\/css-tricks.com\/defining-and-dealing-with-technical-debt\/\">Defining and Dealing with Technical Debt<\/a> &#8211; We talked a lot about DRY methods and efficiency in this article. This post talks about the various consequences of verbose or inefficient code.<\/li><li><a href=\"https:\/\/css-tricks.com\/loops-css-preprocessors\/\">Loops in CSS Preprocessors<\/a> &#8211; We didn&#8217;t cover loops here, but Miriam Suzanne goes in depth in this article.<\/li><li><a href=\"https:\/\/css-tricks.com\/snippets\/sass\/\">Sass Snippets<\/a> &#8211; A collection of handy Sass mixins and other Sass patterns.<\/li><\/ul>\n","protected":false},"excerpt":{"rendered":"<p>Having been in the web development industry for more than 14 years, I\u2019ve seen and written my fair share of good and bad CSS. When I began at Ramsey Solutions five years ago, I was introduced to Sass. It blew my mind how useful it was! I dove right in and wanted to learn everything [&hellip;]<\/p>\n","protected":false},"author":256801,"featured_media":280785,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_bbp_topic_count":0,"_bbp_reply_count":0,"_bbp_total_topic_count":0,"_bbp_total_reply_count":0,"_bbp_voice_count":0,"_bbp_anonymous_reply_count":0,"_bbp_topic_count_hidden":0,"_bbp_reply_count_hidden":0,"_bbp_forum_subforum_count":0,"sig_custom_text":"","sig_image_type":"featured-image","sig_custom_image":0,"sig_is_disabled":false,"inline_featured_image":false,"c2c_always_allow_admin_comments":false,"footnotes":"","jetpack_publicize_message":"Buddy Reno broke down a list of Sass techniques he's learned over the years. Any that you'd add in there?","jetpack_is_tweetstorm":false,"jetpack_publicize_feature_enabled":true,"jetpack_social_post_already_shared":true,"jetpack_social_options":[]},"categories":[4],"tags":[476],"jetpack_publicize_connections":[],"acf":[],"jetpack_featured_media_url":"https:\/\/i0.wp.com\/css-tricks.com\/wp-content\/uploads\/2019\/01\/Untitled_Artwork.png?fit=4000%2C2000&ssl=1","jetpack-related-posts":[],"featured_media_src_url":"https:\/\/i0.wp.com\/css-tricks.com\/wp-content\/uploads\/2019\/01\/Untitled_Artwork.png?fit=1024%2C512&ssl=1","_links":{"self":[{"href":"https:\/\/css-tricks.com\/wp-json\/wp\/v2\/posts\/280768"}],"collection":[{"href":"https:\/\/css-tricks.com\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/css-tricks.com\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/css-tricks.com\/wp-json\/wp\/v2\/users\/256801"}],"replies":[{"embeddable":true,"href":"https:\/\/css-tricks.com\/wp-json\/wp\/v2\/comments?post=280768"}],"version-history":[{"count":10,"href":"https:\/\/css-tricks.com\/wp-json\/wp\/v2\/posts\/280768\/revisions"}],"predecessor-version":[{"id":310961,"href":"https:\/\/css-tricks.com\/wp-json\/wp\/v2\/posts\/280768\/revisions\/310961"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/css-tricks.com\/wp-json\/wp\/v2\/media\/280785"}],"wp:attachment":[{"href":"https:\/\/css-tricks.com\/wp-json\/wp\/v2\/media?parent=280768"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/css-tricks.com\/wp-json\/wp\/v2\/categories?post=280768"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/css-tricks.com\/wp-json\/wp\/v2\/tags?post=280768"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}