Skip to content

Commit 9392e24

Browse files
committed
Add section about mixins
In my previous commit, I revised this document to advise against using @extend, which included removing the section about mixins because it only existed to recommend against using argumentless mixins in favor of @extend. However, this document feels a bit incomplete without some guidance on mixin usage, so I am adding a few sentences here.
1 parent a6a2e3e commit 9392e24

File tree

1 file changed

+5
-0
lines changed

1 file changed

+5
-0
lines changed

README.md

Lines changed: 5 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -17,6 +17,7 @@
1717
1. [Sass](#sass)
1818
- [Syntax](#syntax)
1919
- [Ordering](#ordering-of-property-declarations)
20+
- [Mixins](#mixins)
2021
- [Extend directive](#extend-directive)
2122
- [Nested selectors](#nested-selectors)
2223

@@ -218,6 +219,10 @@ We recommend creating JavaScript-specific classes to bind to, prefixed with `.js
218219
}
219220
```
220221

222+
### Mixins
223+
224+
Mixins should be used to DRY up your code, add clarity, or abstract complexity--in much the same way as well-named functions. Mixins that accept no arguments can be useful for this, but note that if you are not compressing your payload (e.g. gzip), this may contribute to unnecessary code duplication in the resulting styles.
225+
221226
### Extend directive
222227

223228
`@extend` should be avoided because it has unintuitive and potentially dangerous behavior, especially when used with nested selectors. Even extending top-level placeholder selectors can cause problems if the order of selectors ends up changing later (e.g. if they are in other files and the order the files are loaded shifts). Gzipping should handle most of the savings you would have gained by using `@extend`, and you can DRY up your stylesheets nicely with mixins.

0 commit comments

Comments
 (0)