Préprocesseur CSS

Qu'est-ce qu'un préprocesseur CSS ? D'une manière générale, ils ont étendu un ensemble de leur propre DSL (Domain Specific Language) basé sur CSS pour résoudre des problèmes qui nous sont difficiles à résoudre lors de l'écriture de CSS :

• La syntaxe n'est pas assez puissante, comme l'incapacité d'imbriquer l'écriture. Cela entraîne la nécessité d'écrire de nombreux sélecteurs répétés dans le développement modulaire
• n'a pas de variables et un mécanisme de réutilisation de style raisonnable, donc les valeurs d'attribut logiquement liées doivent être sorties à plusieurs reprises dans la forme de littéraux, ce qui rend difficile sa maintenance.

Cela se résume à la capacité d’abstraction. Cela détermine donc l'objectif principal du préprocesseur CSS : fournir le mécanisme de réutilisation des couches de style manquant dans CSS, réduire le code redondant et améliorer la maintenabilité du code de style. Ce n’est pas la cerise sur le gâteau, mais une aide opportune.

Cependant, le préprocesseur CSS n'est pas une panacée. L'avantage du CSS est qu'il est facile à utiliser et à déboguer à tout moment et en tout lieu. L'ajout de l'étape CSS précompilée ajoute un lien supplémentaire à notre flux de travail de développement et rend le débogage plus difficile. Le plus gros problème est que la précompilation peut facilement conduire à un abus des sélecteurs descendants. Ainsi, lorsque vous utilisez des préprocesseurs CSS, veillez à éviter de tels problèmes.

Les variables Sass commençant par $ sont moins susceptibles d'entrer en conflit avec la syntaxe standard CSS. Les variables dans Less commencent par @. Bien qu'il soit facile d'entrer en conflit avec la nouvelle syntaxe des mises à jour ultérieures des spécifications, en théorie, tant que la spécification CSS n'introduit pas de règles telles que @a: b, le problème n'est pas grave. De plus, de nombreuses implémentations existantes seront prises en compte lors de la formulation des spécifications.

Les mécanismes variables de Sass et Less sont très différents. Sass est similaire à la portée au niveau du bloc de JS. Les valeurs peuvent être réaffectées dans la portée sans affecter le monde extérieur. mission globale. SASS et SCSS ne sont que deux styles de syntaxe. SCSS est plus proche de la syntaxe CSS et est plus confortable à écrire sur le front-end. Il n’y a pas de différence évidente entre les parties les plus couramment utilisées de Less et de Sass, alors ne vous inquiétez pas trop de celle à utiliser, choisissez-en simplement une. Quant à celui que l’entreprise utilise, respectez-le. S’il n’y a pas de problèmes majeurs, n’envisagez pas de le changer.

Partage de fichiers

Les pages deviennent de plus en plus complexes et les fichiers CSS à charger sont de plus en plus gros. C'est nécessaire. pour nous de diviser les gros fichiers, sinon ce sera difficile à maintenir. Les solutions traditionnelles de fractionnement de fichiers CSS sont essentiellement des directives @import CSS natives ou le chargement de plusieurs fichiers CSS en HTML. Ces solutions ne peuvent généralement pas répondre aux exigences de performances.

Le préprocesseur CSS étend les capacités de la directive @import pour fusionner à nouveau les fichiers divisés en un seul gros fichier via le processus de compilation. D'une part, cela résout le problème de la maintenance peu pratique des fichiers volumineux et, d'autre part, cela résout également le problème de performances lors du chargement d'un tas de petits fichiers.

Modularisation

Pousser l'idée de segmentation de fichiers un peu plus loin est la « modularisation ». Une fois qu'un gros fichier CSS est raisonnablement divisé, la relation entre les petits fichiers résultants doit être une structure arborescente.

Le nœud racine de l'arbre est généralement appelé « fichier d'entrée », et les autres nœuds de l'arbre sont généralement appelés « fichiers module ». Les fichiers d'entrée dépendent généralement de plusieurs fichiers de module, et chaque fichier de module peut également dépendre d'autres modules terminaux, formant ainsi l'arborescence entière.

Ce qui suit est un exemple simple :

entry.less
 ├─ base.less
 │   ├─ normalize.less
 │   └─ reset.less
 ├─ layout.less
 │   ├─ header.less
 │   │   └─ nav.less
 │   └─ footer.less
 ├─ section-foo.less
 ├─ section-bar.less
 └─ ...复制代码

Fichier d'entrée entry.less Les modules requis seront introduits lors de la compilation, le fichier Entry.css sera généré, puis référencé par la page.

Si vous avez utilisé d'autres langages de programmation avec des mécanismes de module, vous devriez déjà comprendre profondément que la modularisation est un très bon moyen d'organiser le code et un moyen important pour les développeurs de concevoir la structure du code. Les modules peuvent clairement implémenter la superposition de code, la réutilisation et la gestion des dépendances, permettant au processus de développement CSS de profiter de la commodité du développement de programmes modernes.

Imbrication de sélecteurs

L'imbrication de sélecteurs est une méthode d'organisation du code au sein d'un fichier, qui permet à une série de règles liées de présenter une relation hiérarchique.

Variables

Avant que le changement ne se produise, toutes les valeurs de propriété en CSS sont des "nombres magiques". Vous ne savez pas d'où vient cette valeur ni quelle est sa signification. Une fois que nous avons des variables, nous pouvons donner des noms à ces « nombres magiques » pour faciliter la mémoire, la lecture et la compréhension.

Nous découvrirons ensuite que lorsqu'une valeur spécifique est utilisée à plusieurs endroits, les variables constituent une méthode d'abstraction simple et efficace qui peut éliminer une telle duplication et rendre votre code plus SEC .

Les variables permettent aux développeurs d'unifier plus facilement le style visuel du site Web et facilitent également les exigences telles que le « changement de skin ».

Opération

Il ne suffit pas d'avoir des variables, nous avons aussi besoin d'opérations. Si les variables donnent du sens aux valeurs, les opérations peuvent associer des valeurs à des valeurs. Les valeurs de certains attributs sont en fait étroitement liées aux valeurs d'autres attributs. La syntaxe CSS ne peut pas exprimer cette relation dans le langage de prétraitement, nous pouvons utiliser des variables et des expressions pour présenter cette relation ;

Par exemple, nous devons faire en sorte qu'un conteneur n'affiche que trois lignes de texte au maximum. Dans le passé, nous l'écrivions généralement comme ceci :

.

.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

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教程》

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!