CSS プリプロセッサとは何ですか?一般的に言えば、彼らは CSS を記述するときに私たちが解決するのが難しい問題を解決するために、CSS に基づいた独自の DSL (ドメイン固有言語) のセットを拡張しました。
つまるところ、抽象的な能力です。したがって、これによって CSS プリプロセッサの主な目標が決定されます。つまり、CSS に欠けているスタイル レイヤーの再利用メカニズムを提供し、冗長なコードを削減し、スタイル コードの保守性を向上させることです。これはおまけではありませんが、タイムリーな助けになります。
ただし、CSS プリプロセッサは万能薬ではありません。CSS の利点は、いつでもどこでも簡単に使用してデバッグできることです。プリコンパイルされた CSS ステップの追加により、開発ワークフローに別のリンクが追加され、デバッグがさらに面倒になります。さらに大きな問題は、プリコンパイルが子孫セレクターの悪用に簡単につながる可能性があることです。したがって、CSS プリプロセッサを使用する場合は、このような問題を回避するように注意してください。
$ で始まる Sass 変数は、CSS 標準構文と競合する可能性が低くなります。 Less の変数は @ で始まります。後続の仕様更新の新しい構文と競合するのは簡単ですが、理論的には、CSS 仕様が @a: b のようなルールを導入しない限り、問題は次のとおりです。大きくない。さらに、仕様を策定する際には、多くの既存の実装が参照されます。
Sass と Less の変数メカニズムは大きく異なります。Sass は JS のブロックレベルのスコープに似ています。外部に影響を与えることなくスコープ内で値を再割り当てできます。Less は最後の値に基づいています。グローバル割り当てです。 SASS と SCSS は 2 つの構文スタイルにすぎません。SCSS は CSS 構文に近く、フロントエンドでの記述がより快適です。 Less と Sass の最も一般的に使用される部分に明らかな違いはないため、どちらを使用するかについてあまり心配せず、どちらかを選択してください。会社がどちらを使用しているかについては、そのまま使用し、大きな問題がない場合は変更を検討しないでください。
ページはますます複雑になり、ロードする必要がある CSS ファイルもますます大きくなっています。大きなファイルを分割する必要があります。そうしないと、メンテナンスが困難になります。従来の CSS ファイル分割ソリューションは、基本的に CSS ネイティブの @import ディレクティブ、または HTML での複数の CSS ファイルの読み込みであり、通常、これらのソリューションはパフォーマンス要件を満たすことができません。
CSS プリプロセッサは、コンパイル プロセスを通じて分割ファイルを 1 つの大きなファイルに再マージする @import ディレクティブの機能を拡張します。これにより、大きなファイルのメンテナンスが不便になるという問題が解決される一方で、小さなファイルを大量にロードするときのパフォーマンスの問題も解決されます。
ファイルのセグメント化の考え方をさらに一歩進めたものが「モジュール化」です。大きな CSS ファイルが適切に分割された後、結果として得られる小さなファイル間の関係はツリー構造になるはずです。
ツリーのルート ノードは一般に「エントリ ファイル」と呼ばれ、ツリーの他のノードは一般に「モジュール ファイル」と呼ばれます。通常、エントリ ファイルは複数のモジュール ファイルに依存し、各モジュール ファイルは他のターミナル モジュールにも依存する場合があるため、ツリー全体が形成されます。
以下は簡単な例です:
entry.less ├─ base.less │ ├─ normalize.less │ └─ reset.less ├─ layout.less │ ├─ header.less │ │ └─ nav.less │ └─ footer.less ├─ section-foo.less ├─ section-bar.less └─ ...复制代码
Entry fileentry.less コンパイル時に必要なモジュールが導入され、entry.css が生成され、その後ページで参照されています。
モジュール メカニズムを備えた他のプログラミング言語を使用したことがある場合は、モジュール化がコードを編成する非常に優れた方法であり、開発者がコード構造を設計するための重要な手段であることをすでに深く理解しているはずです。モジュールはコードの階層化、再利用、依存関係の管理を明確に実装できるため、CSS 開発プロセスで最新のプログラム開発の利便性を享受できるようになります。
セレクターのネストは、ファイル内のコード編成方法であり、これにより、一連の関連ルールが階層関係を表すことができます。
変更が発生する前は、CSS 内のすべてのプロパティ値は「マジック ナンバー」です。この値がどこから来たのか、その意味が何なのかはわかりません。変数を取得したら、記憶、読み取り、理解を容易にするために、これらの「魔法の数字」の名前を付けることができます。
次に、特定の値が複数の場所で使用されている場合、変数はそのような重複を排除し、コードをより DRY にすることができるシンプルで効果的な抽象化方法であることがわかります。
変数を使用すると、開発者は Web サイトのビジュアル スタイルを統一しやすくなり、「スキンの変更」などの要件も容易になります。
変数があるだけでは十分ではなく、操作も必要です。変数が値に意味を持たせる場合、操作は値を値に関連付けることができます。一部の属性の値は、実際には他の属性の値と密接に関連しています。CSS 構文ではこの関係を表現できません。前処理言語では、変数と式を使用してこの関係を表現できます。
たとえば、コンテナーに最大 3 行のテキストのみを表示させる必要がある場合、以前は通常次のように記述していました:
.wrapper { overflow-y: hidden; line-height: 1.5; max-height: 4.5em; /* = 1.5 x 3 */}复制代码大家可以发现，我们只能用注释来表达 max-height 的值是怎么来的，而且注释中 3 这样的值也是幻数，还需要进一步解释。未来当行高或行数发生变化的时候，max-height 的值和注释中的算式也需要同步更新，维护起来很不方便。
接下来我们用预处理语言来改良一下：
.wrapper $max-lines = 3 $line-height = 1.5 overflow-y: hidden line-height: $line-height max-height: unit($line-height * $max-lines, 'em')复制代码
乍一看，代码行数似乎变多了，但代码的意图却更加清楚了——不需要任何注释就把整件事情说清楚了。在后期维护时，只要修改那两个变量就可以了。
值得一提的是，这种写法还带来另一个好处。$line-height 这个变量可以是 .wrapper 自己定义的局部变量（比如上面那段代码），也可以从更上层的作用域获取：
$line-height = 1.5 // 全局统一行高 body line-height: $line-height .wrapper $max-lines = 3 max-height: unit($line-height * $max-lines, 'em') overflow-y: hidden复制代码
这意味着 .wrapper 可以向祖先继承行高，而不需要为这个“只显示三行”的需求把自己的行高写死。有了运算，我们就有能力表达属性与属性之间的关联，它令我们的代码更加灵活、更加 DRY。
把常用的运算操作抽象出来，我们就得到了函数。
开发者可以自定义函数，预处理器自己也内置了大量的函数。最常用的内置函数应该就是颜色的运算函数了吧！有了它们，我们甚至都不需要打开 Photoshop 来调色，就可以得到某个颜色的同色系变种了。
举个例子，我们要给一个按钮添加鼠标悬停效果，而最简单的悬停效果就是让按钮的颜色加深一些。我们写出的 CSS 代码可能是这样的：
.button { background-color: #ff4466;
}.button:hover { background-color: #f57900;
}复制代码我相信即使是最资深的视觉设计师，也很难分清 #ff4466 和 #f57900 这两种颜色到底有什么关联。而如果我们的代码是用预处理语言来写的，那事情就直观多了：
.button $color = #ff9833 background-color: $color &:hover background-color: darken($color, 20%)复制代码
此外，预处理器的函数往往还支持默认参数、具名实参、arguments 对象等高级功能，内部还可以设置条件分支，可以满足复杂的逻辑需求。
Mixin 是 CSS 预处理器提供的又一项实用功能。Mixin 的形态和用法跟函数十分类似——先定义，然后在需要的地方调用，在调用时可以接受参数。它与函数的不同之处在于，函数用于产生一个值，而 Mixin 的作用是产生一段 CSS 代码。
Mixin 可以产生多条 CSS 规则，也可以只产生一些 CSS 声明。
一般来说，Mixin 可以把 CSS 文件中类似的代码块抽象出来，并给它一个直观的名字。比如 CSS 框架可以把一些常用的代码片断包装为 mixin 备用，在内部按需调用，或暴露给使用者在业务层调用。
举个例子，我们经常会用到 clearfix 来闭合浮动。在原生 CSS 中，如果要避免 clearfix 代码的重复，往往只能先定义好一个 .clearfix 类，然后在 HTML 中挂载到需要的元素身上：
/* 为 clearfix 定义一个类 */
.clearfix {...}
.clearfix::after {...}复制代码<!-- 挂载到这两个元素身上 --><p class="info clearfix">...</p>...<footer class="clearfix">...</footer>复制代码
把表现层的实现暴露到了结构层，是不是很不爽？而在预处理器中，我们还可以选择另一种重用方式：
// 为 clearfix 定义一个 mixin clearfix() ... &::after ... // 在需要的元素身上调用 .info clearfix() footer clearfix()复制代码
CSS 预处理语言无法直接运行于浏览器环境，这意味着我们编写的源码需要编译为 CSS 代码之后才能用于网页。这似乎是一个门槛，需要我们付出“额外”的成本。
但在目前的大环境下，大多数项目的前端开发流程已经包含了构建环节，比如选择任何一个脚本模块化方案都是需要在部署时走一道打包程序的。所以对大多数团队来说，这个门槛其实已经跨过去一大半了。
而一旦接受了这种设定，我们还可以享受到“额外”的福利。在给 CSS 的开发加入编译环节的同时，还可以顺道加入其它构建环节，比如代码校验、代码压缩、代码后处理等等。
“代码后处理”是指 PostCSS 平台上各类插件所提供的功能，光是 Autoprefixer 这一项就已经值回票价了。我们再也不需要在 CSS 代码中手工添加浏览器前缀了，直接使用标准写法，剩下的事情让工具搞定吧！
推荐教程：《CSS教程》
以上がCSSプリプロセッサの詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。
![[Web フロントエンド] Node.js クイック スタート](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
