TECH
Vol.61
M.S.
Practical code design using Sass to prevent CSS bloat
In this installment, I will walk through how to install and compile Sass using Coda 2, which I use in my daily work. Building on the previous discussion, I will also share key considerations from real-world practice, along with the improvements and insights gained.
Installing Sass, using it in Coda, and Compiling
How to Install Sass in Coda
First, visit the official Coda website.
Select [ Plug-ins ] from the menu, and search for “Sass” using the search form. A Sass plug-in for Coda will appear.
Click the light green [ Install ] button to launch Coda, and Sass will be automatically installed.
If “Sass” appears under the General section in the Plug-ins tab of Coda’s Preferences, the installation is complete.
Compiling Sass (SCSS) in Coda
拡張子が「.scss」のscssファイルを作成し、css、scssの記述方法に合わせてコードを書いて保存をします。
Codaでは、scssファイルを保存すると、同階層に同じファイル名のCSSファイルが自動で吐き出されます。scssでコードを書いて、上書き保存をするたびにcssファイルを更新していってくれるのでコンパイルをするたびにコマンド実行などの手間がなく便利です。
Key points practiced in this implementation
- Separate SCSS files by page and consolidate them into a single CSS file using import
- Standardize and reuse classes
- Utilize mixins and extend
- Avoid excessive nesting
Results of the implementation
What worked well
- ページごとに分けているので見やすい、それぞれのファイルのコード量が少なく軽い
1ページごとにscssファイルを分けたため修正の際などに作業するファイルが明確になった。 - 1ページのscssファイルをさらにPC用とレスポンシブ用の2ファイルに分けたため、それぞれのファイルサイズが格段に小さくなり、作業効率が良くなった。
- 同じコードが減り、無駄な記述がなくなった
共通のクラスを使用、またmixinやextendを使用するなど、同じコードを何度も繰り返し書かず済んだことですっきりしたコードになった。 - 多量なインデント、深すぎる階層のセレクタがなくなった
scss内で入れ子をしすぎ、エディタ画面の半分がインデントで埋まるということや必要以上に深い階層の、強いセレクタがなくなった。
What didn’t work well
- importでファイルを細かく分けたためコードが見つからないことがある
ページごとにファイルを分けたため、一部で使っていたコードを後から共通化したあと、その記述を特定ページのscssファイルにそのまま残してしまうなど、編集したい記述を探すのに手間取ってしまった。 - extend継承のしすぎ
ボタンなどの記述にextendを使用したが、共通化するセレクタの数が増えすぎてしまい、コンパイル後、大量のセレクタが羅列してしまった。
またextendを使用したセレクタを入れ子にして別の場所で使った場合、そちらでもグループ化されて、いらない上書きが発生してしまった。
//extend）
.btn1{border:1px solid #000000; width:120px; font-size:14px;}
.btn2{@extend .btn1; border:1px dotted #cccccc;}
.box{
.btn1{border-color:#ff0000;}
}
↓
//extendコンパイル後）
.btn1,.btn2{border:1px solid #000000; width:120px; font-size:14px;}
.btn2{border:1px dotted #cccccc;}
.box .btn1,.box .btn2{border-color:#ff0000;}
How to improve
- Write shared code in a common SCSS file from the beginning
This may seem obvious, but layout changes are inevitable during development.
If you find the need to refactor code into shared components later on, move it to the common SCSS file as soon as possible. If immediate relocation is difficult due to structural constraints, leave comments so the code can be easily found through search. - Avoid overusing the same extend declarations
Unlike mixins, extend groups selectors into the same rule.
While it is convenient and prevents duplication by automatically grouping selectors, excessive use can lead to a large number of selectors being chained together. To prevent this, limit the number of times extend is used, or define a single shared class instead. - Use placeholder selectors for controlled grouping
Sass provides placeholder selectors specifically for use with extend.
Placeholder selectors are defined using “%” instead of “#” or “.”. Unlike regular selectors, they behave more like mixins—they are only applied when explicitly called and are not included in the compiled output unless used.
This approach prevents unintended grouping from other declarations and allows you to call and use only the necessary styles.
//extend using placeholder selector）
%btn-extend{border:1px solid #000000; width:120px; font-size:14px;}
.btn1{@extend %btn-extend;}
.btn2{@extend %btn-extend; border:1px dotted #cccccc;}
.box{
.btn1{border-color:#ff0000;}
}
↓
//after compilation with placeholder selector）
.btn1,.btn2{border:1px solid #000000; width:120px; font-size:14px;}
.btn2{border:1px dotted #cccccc;}
.box .btn1{border-color:#ff0000;}
Reflections on this implementation
By applying the key points and considerations outlined in the previous article, I found that the final compiled CSS was likely more optimized in size compared to before.
Since this implementation focused specifically on reducing CSS file size, and unlike refactoring, there was no direct baseline for comparison, this remains a subjective assessment. However, I believe the use of Sass and the standardization of code contributed significantly to the improvements.
That said, this exercise also revealed several areas that still require improvement, and made it clear that there is more to be done before achieving a truly efficient workflow for minimizing CSS output.
There are also Sass features that I have yet to explore and therefore could not cover in this article. Moving forward, I intend to leverage those capabilities as well, with the goal of further reducing CSS size and refining code design.
RECENT POSTS
Vol.203
What Is Design Management
Vol.202
Why Hiring No Longer Works— Redesigning Organizations and Decisions for an Uncertain Age
Vol.201
How to Choose a Branding Agency: 5 Criteria to Avoid Failure
Vol.200
Design Management: A Practical Guide for SMEs and Startups to Drive Real Results
Vol.199
How to Rebuild Brand Competitiveness: A Practical Guide to Brand Management for SMEs
Vol.198
From parent–child bonds to community: The future of education that nurtures diversity and designs relationships
