Cette fois, je vais vous montrer comment utiliser le style SASS de CSS et quelles sont les précautions lors de l'utilisation du style SASS de CSS. Ce qui suit est un cas pratique, jetons un coup d'œil.
Alors que de plus en plus de développeurs utilisent SASS, nous devons faire attention au nombre de codes SASS. Nous pouvons partir de la syntaxe CSS (feuilles de style en cascade) pour expliquer certaines des particularités de la syntaxe SASS. Après tout, les guides de style CSS sont très courants.
Cet article présente principalement certaines fonctionnalités qui m'intéressent personnellement. Vous pourrez peut-être en bénéficier et créer votre propre ensemble de guides d'utilisation de SASS.
Continuez à maintenir vos propres règles de formatage CSS et guides de style couramment utilisés
Cet article se concentre sur la discussion de certains contenus sur SASS, mais sur cette base, les développeurs doivent conserver leurs bonnes règles de formatage existantes. Si vous n’avez pas encore développé votre propre ensemble de règles de formatage, voici une revue de quelques guides de style qui devraient vous aider à développer vos propres habitudes d’écriture CSS. Voici quelques-uns des contenus inclus :
1. Gardez les indentations de ligne cohérentes
2. Gardez le nombre d'espaces avant et après les deux-points/accolades cohérent
3. Gardez un sélecteur par ligne, un règle par ligne
4. Essayez d'écrire les attributs associés ensemble
5. Pour les règles de dénomination des noms de classe, suivez un plan
6. Évitez d'utiliser CSS sélecteur d'identifiant
7 .
Apprenons ensuite à écrire du beau code SASS, en prenant comme exemple l'écriture d'une propriété de la classe .weather :
Première liste @extend(s)
.weather { @extends %module; ... }
Faire cela peut permettre aux développeurs de garder une idée claire, de connaître immédiatement la relation entre cette classe et ses attributs et d'autres classes et leurs attributs, et de maintenir une idée claire de la cohérence des attributs et de la réutilisation des attributs.
Style normal
.weather { @extends %module; background: LightCyan; .. } @include(s) .weather { @extends %module; background: LightCyan; @include transition(all 0.3s ease-out); ... }
Cela permet aux développeurs de voir le déploiement de @extend(s) et @include(s) en un coup d'œil, ce qui facilite l'interprétation du code pour eux-mêmes et pour les autres développeurs. Vous pouvez également décider de faire la distinction entre les @includes personnalisés et les @includes sources publiques dans certains cas (en particulier en tenant compte de la réutilisabilité et de l'actualité du code)
Imbrication des sélecteurs
.weather { @extends %module; background: LightCyan; @include transition(all 0.3s ease); > h3 { border-bottom: 1px solid white; @include transform(rotate(90deg)); } }
Dans les sections imbriquées, continuez à utiliser le style règles ci-dessus. Les parties imbriquées doivent toujours venir en dernier.
Utilisez @mixins pour tous les préfixes de fournisseur
Les préfixes de fournisseur (préfixes CSS) sont très sensibles au facteur temps. En raison des mises à jour des navigateurs modernes, ces préfixes seront de moins en moins utilisés. Vous pouvez vous adapter à ces changements en mettant à jour le contenu de vos mixins (ou certaines bibliothèques utilisées dans vos mixins seront mises à jour automatiquement). Même si le mixin ne comporte qu’une seule ligne, cela n’a pas d’importance.
Mais lorsque la privatisation de certains préfixes de fournisseurs est très sérieuse, ces préfixes seront très difficiles à standardiser et appliquer d'autres préfixes ou versions non préfixées n'en vaudra pas le gain, je choisirai d'abandonner @mixin ces préfixes de fournisseurs. Par exemple -webkit-line-clamp, -mscontent-zoom-chaining ou des situations similaires.
N'imbriquez pas plus de 3 niveaux
.weather { .<span style="width: auto; height: auto; float: none;" id="14_nwp"><a style="text-decoration: none;" mpid="14" target="_blank" href="http://cpro.baidu.com/cpro/ui/uijs.php?adclass=0&app_id=0&c=news&cf=1001&ch=0&di=128&fv=0&is_app=0&jk=be9ebff1476c47c4&k=cities&k0=cities&kdi0=0&luki=6&n=10&p=baidu&q=06011078_cpr&rb=0&rs=1&seller_id=1&sid=c4476c47f1bf9ebe&ssp2=1&stid=0&t=tpclicked3_hc&tu=u1922429&u=http%3A%2F%2Fwww%2Eadmin10000%2Ecom%2Fdocument%2F2137%2Ehtml&urlid=0" id="14_nwl"><span style="color:#0000ff;font-size:14px;width:auto;height:auto;float:none;">cities</span></a></span> { li { // no more! } } }
Si vous imbriquez plus de trois fois, vous risquez d'écrire un sélecteur de triche (mauvais ?). La raison de la triche est que ce sélecteur s'appuie trop sur la structure du HTML (instable), qu'il est trop détaillé (la fonction est trop puissante et n'a aucune flexibilité), ou que la réutilisabilité est trop mauvaise (pas très utilisable). Dans le même temps, un trop grand nombre de niveaux d’imbrication peut facilement conduire à un code obscur et difficile à comprendre.
Parfois, il y a trop de code lié à une classe, il faut donc utiliser le sélecteur de balises. Vous devrez peut-être être très précis sur une classe pour éviter une cascade inutile. Même si cela est possible, utilisez extend pour profiter de certaines fonctionnalités de réutilisabilité de CSS.
.weather > h3 { @extend %line-under; } }
Le code imbriqué ne doit pas dépasser 50 lignes
S'il y a plus de 50 lignes de code imbriqué dans SASS, il peut ne pas être entièrement affiché dans le compilateur sur un. page, cela rendra le code difficile à lire et à comprendre. L'imbrication est initialement destinée à faciliter et simplifier la réflexion et l'organisation du code. Si cela viole la lisibilité, veuillez ne pas imbriquer.
Les séquences de fichiers SASS globales et régionales sont équivalentes au contenu des tableaux
En d'autres termes, elles n'ont pas de style fixe. Les développeurs doivent se rappeler de garder le style de toutes les parties cohérent et ordonné.
Répertoriez d'abord les bibliothèques fournisseur/globales, puis listez les bibliothèques personnalisées, puis les modes et enfin les bibliothèques utilisées par chaque division.
Le 'répertoire' ressemblera à cet exemple en un coup d'œil :
/* Vendor Dependencies */ @import "compass"; /* Authored Dependencies */ @import "<span style="width: auto; height: auto; float: none;" id="10_nwp"><a style="text-decoration: none;" mpid="10" target="_blank" href="http://cpro.baidu.com/cpro/ui/uijs.php?adclass=0&app_id=0&c=news&cf=1001&ch=0&di=128&fv=0&is_app=0&jk=be9ebff1476c47c4&k=global&k0=global&kdi0=0&luki=9&n=10&p=baidu&q=06011078_cpr&rb=0&rs=1&seller_id=1&sid=c4476c47f1bf9ebe&ssp2=1&stid=0&t=tpclicked3_hc&tu=u1922429&u=http%3A%2F%2Fwww%2Eadmin10000%2Ecom%2Fdocument%2F2137%2Ehtml&urlid=0" id="10_nwl"><span style="color:#0000ff;font-size:14px;width:auto;height:auto;float:none;">global</span></a></span>/colors"; @import "global/mixins"; /* Patterns */ @import "global/tabs"; @import "global/modals"; /* Sections */ @import "global/header"; @import "global/footer";
Ces fichiers sont comme une boussole, les couleurs et les mixins ne sont pas générés. Code CSS compilé, ils. sont des bibliothèques purement autonomes. Des modèles ont ensuite été introduits pour rendre la réécriture plus sûre sans conflits de spécificité.
Divisez raisonnablement SASS en plusieurs petits fichiers
这样做没有任何不好。在情况允许的时候,尽量使用小而精的多个文件,这样便于开发者在寻找一些特定文件,而不是在几个拥有冗长代码的大文件中大海捞针。
... @import "<span style="width: auto; height: auto; float: none;" id="9_nwp"><a style="text-decoration: none;" mpid="9" target="_blank" href="http://cpro.baidu.com/cpro/ui/uijs.php?adclass=0&app_id=0&c=news&cf=1001&ch=0&di=128&fv=0&is_app=0&jk=be9ebff1476c47c4&k=global&k0=global&kdi0=0&luki=9&n=10&p=baidu&q=06011078_cpr&rb=0&rs=1&seller_id=1&sid=c4476c47f1bf9ebe&ssp2=1&stid=0&t=tpclicked3_hc&tu=u1922429&u=http%3A%2F%2Fwww%2Eadmin10000%2Ecom%2Fdocument%2F2137%2Ehtml&urlid=0" id="9_nwl"><span style="color:#0000ff;font-size:14px;width:auto;height:auto;float:none;">global</span></a></span>/header/header/"; @import "global/header/logo/"; @import "global/header/dropdowns/"; @import "global/header/nav/"; @import "global/header/really-specific-thingy/";
我经常做的就是在一个全局scss文件中逐个引用这些文件,而不是引用一个_header.scss文件,然后再_header.scss文件中在逐个引用。这样做能够降低索引的时间和提高阅读效率。
当这些文件过多导致import序列太长时,你可能会用到 Globbing 。
记得将Partials命名为_partial.scss
这是一个常见对于不能自身编译的文件的命名。这样的文件多少会依赖于其他的文件,使得自身不能独立完成编译。我个人喜欢在文件名之前添加一个下划线,譬如_dropdown-menu.scss
在本地编译时添加行映射
看这里,这意味着开发工具能够告诉你每一条规则的来源,哪怕是一个被引入的partial文件。
在部署时,记得编译已精简的文件
运行中的网页永远都只需要使用精简的CSS。
无需递交.css文件
这可能要花些时间,但是不在文件库中放入.css文件可以是一件非常美妙的事. 文件编译在部署的时候就完成了。 所以唯一可以看见的是那些已经精简的格式美妙的sass文件。 这使得对于文件的描述变得大有用途。文件描述是用于对比由版本发布者所做的一些更改。而对于已经精简的.css文件,文件描述基本不需要了。
大方的使用注释
很少有人会后悔在代码中留下了注释。不论是有用的还是不起眼的注释,他们最终都会在编译成精简的CSS文件时被抹去,对于开发者来说不会有任何附加代价。
.overlay { /* modals are 6000, saving messages are 5500, header is 2000 */ z-index: 5000; }
提到注释,你可能也需要对它做一些标准化的调整。在SASS中,’//’非常适用于添加注释,’//’使得注释和取消注释变得非常方便。
将一些常用的数值和有特殊意义的数值转化成变量
如果你发现自己重复使用一个数值(这在前端设计里是很常见的),你最好将它转化成一个变量。这样你可以通过命名来提醒自己这个数值的含义,并且在编写代码时保持一致性,是的你在更改这个数值时不需要逐行调整。
若果一个数字有着明显的含义,那么将它转化成变量是必不可少的啦。
相信看了这些案例你已经掌握了方法,更多精彩请关注php中文网其它相关文章!
相关阅读:
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!