Quelques conseils pour écrire du CSS

Javascripty s'est engagé sur la voie de l'ingénierie. Divers frameworks mvm et mvvm sont devenus vertigineux Nous ne discuterons pas de js ici. Permettez-moi de parler d'une partie de mon expérience dans l'écriture de CSS dans le cadre de mon travail réel. Bien sûr, de nombreuses personnes ont également résumé cette expérience. Ce dont je parle n'est certainement pas aussi bon que ce que certains experts ont écrit. expérience et comparez-la avec Partagez-la avec tout le monde.

Si vous voulez bien faire votre travail, vous devez d'abord aiguiser vos outils

Lorsque vous écrivez du CSS, vous devez maîtriser au moins un outil de développement, que ce soit SASS, c'est toujours MOINS. Essentiellement, ce sont les mêmes, mais la syntaxe est un peu différente. Si vous écrivez encore du CSS à la main, veuillez vous renseigner dès que possible, choisissez-en un en fonction de vos propres habitudes et utilisez-le. Personnellement, je préfère l'audace, qui correspond davantage à mes habitudes d'écriture. Il y a aussi beaucoup de gens qui aiment Less. Ils pensent que la syntaxe Moins est plus pratique.

Qu'est-ce que SASS/LESS

SASS (LESS) est une extension de CSS3, ajoutant l'imbrication de règles, les variables, les mixins, l'héritage des sélecteurs, etc. Convertissez-le en code CSS standard et bien formé à l'aide d'outils de ligne de commande ou de plug-ins de framework WEB.

Pourquoi avez-vous besoin de SASS/LESS

En tant qu'outil de développement, ils fournissent de nombreuses méthodes d'écriture pratiques, ce qui fait gagner beaucoup de temps aux concepteurs et facilite le développement CSS. simple et maintenable.
Ils sont également la pierre angulaire de l’écriture de CSS modulaires et maintenables.

Comment utiliser

Il existe de nombreux tutoriels sur SASS/LESS sur Internet, je ne perdrai donc pas de place ici pour écrire sur la syntaxe de base.
Vous pouvez effectuer une recherche en ligne par vous-même. Une fois que vous en avez appris un, vous pouvez essentiellement l'utiliser :

J'utilise SASS comme exemple pour le contenu suivant. , MOINS est également applicable !

Dieu a dit, il n'y a pas de règle sans règles

Oui, il n'y a pas de règle sans règles Vous devez comprendre une norme de dénomination CSS ou formuler votre propre norme (. il n'est pas recommandé de le personnaliser soi-même) Définition, peu propice au travail en équipe) ;

Pourquoi y a-t-il besoin d'une convention de dénomination ?

Lorsque vous aurez écrit beaucoup de CSS, vous constaterez que ne pas avoir de convention de dénomination efficace vous rendra malheureux. Ce sentiment est particulièrement perceptible si vous travaillez sur un projet légèrement plus vaste ou si vous êtes en train de le développer en collaboration avec d’autres. Parce que lorsque vous nommez le CSS, vous constaterez que le nom est utilisé ailleurs, ou qu'un coéquipier l'a déjà utilisé, et vous devez le renommer. Au fil du temps, le nom du CSS deviendra compliqué, malodorant et long, et il est impossible de deviner la signification du nom d'un seul coup d'œil.

Normes de dénomination BEM

Différentes normes de dénomination sont différentes, et les sages ont des opinions différentes. Ici, je vais présenter les normes de dénomination BEM. Ce que j'introduit peut ne pas convenir. pour vous, vous devez réfléchir à la convention de dénomination qui vous convient. .

BEM est une méthode de nommage de classes CSS proposée par l'équipe Yandex, visant à mieux créer des modules CSS/Sass.

BEM signifie bloc, élément et modificateur.

● block : il peut être compris comme une région, un composant ou un élément au niveau d'un bloc. La distinction spécifique doit être analysée en fonction de la situation réelle ;

● block__element : c'est le cas. un élément dans le bloc ci-dessus, par exemple, s'il y a une balise a (a: element) dans la navigation (nav: block), c'est un élément et l'élément sont liés par deux traits de soulignement

<!-- HTML结构 --><nav class="nav">
  <a href="#" class="nav__item nav__item--active">当前页：active</a>
  <a href="#" class="nav__item nav__item--hover">假设鼠标在这里要加个hover的class</a>
  <a href="#" class="nav__item nav__item--normal">假设需要加个normar的状态</a></nav>

// SASS写法.nav{
  &__item{
    &--active{
      <!-- active样式 -->
    }
    &--hover{
      <!-- hover样式 -->
    }
    &--normal{
      <!-- normal样式 -->
    }
  }}

/* 编译后的css */
.nav{ }
.nav__item{ }
.nav__item--active{ }
.nav__item--hover{ }
.nav__item--normal{ }

Dieu a dit, je ne te connais pas<🎜 ; >Un SASS lisible doit avoir une description. Chaque fichier et fonction a besoin d'une description.

Pour un fichier SASS, vous devez expliquer au moins deux points, si ce SASS est public ou privé, quelle page et quelle partie

@charset "utf-8"/** 预定义函数* author：xxx* time:xxxx-xx-xx*//** 清除浮动* use: @include clearfix();* author: xxx* time: xxxx-xx-xx*/@mixin clearfix(){
  *zoom: 1;
  &:before,
  &:after {
      content: "";
      display: table;
  }
  &:after {
      clear: both;
      overflow: hidden;
  }}

Quantityreset

la réinitialisation CSS est essentielle. Il existe de nombreux codes de réinitialisation CSS sur Internet. Compass dispose également d'un module de réinitialisation. Il vous suffit de @. importer "boussole/réinitialisation". Si vous pensez que ces codes sont trop redondants, vous devez au moins vous assurer que votre CSS a une réinitialisation des marges et du remplissage, afin de pouvoir vous assurer que le CSS a le même style dans chaque navigateur.

*{
  margin: 0;
  padding: 0;}

QuantityTaille de la police

●Couleur

●Niveau

weightHauteur

......

L'utilisation d'une variable distincte présente de nombreux avantages, le le plus important est la maintenabilité, celui qui l'utilise le sait !

●Lorsque vous avez terminé le développement, apportez-le au concepteur pour acceptation. Le concepteur dit que ce n'est pas bon, alors changez la couleur ! ——C'est bon, je vais changer la variable !

●产品说，这里不好，列表间距太大了，小屏幕只显示那么一点点！—— 没事，我改个变量！

●来来来，产品说我们换一套皮肤！ —— 没事，我重新定义一份变量！

……

这些例子可以让你明白有一份variables是多么重要了吧。其实这些只是在可维护方面的好处。作为一名前端，我们是最接近用户的工程师，我们不能仅仅停留在代码层面，更需要的是站在用户体验的角度思考问题，而variables可以让我们有一套规范，确保页面一致性

一致性

FE是面向用户的，我们需要对用户负责。设计师在设计页面的时候，不能所有的像素的都很精确，不可能每次的颜色都是毫无差错的。所以在这时候，就需要规范了，如果设计师没有规范，那我们自己制定一套规范。例如：

●同一个项目，一个页面的列表高度是20px,另一个页面的列表是21px，这时我们无需理会，直接使用我们之前定义的列表高度进行开发。

●同一个页面，有两个error的颜色#dc4c4c和#d84a4a，我们也无需理会，使用统一的error颜色变量；

这些是用户体验的细节，通过一份variables可以让我们保持页面的一致性。
这里只是略微提下用户体验，之后我再写一篇《前端工程师必须重视的用户体验》来详细讲解下用户体验。

module（模块化，基于SASS/LESS）

模块化在js中经常听到，对于css来说，模块化对于易读性和可维护性同样重要。那么如何来做模块化呢？

多文件夹

建立多个文件夹，分类存放sass文件。例如：将variables、mixin、公共样式、私有样式分成多个文件夹存放；

多文件

同一个文件夹的sass可以按模块、功能等等分成多个文件，最终用@import 导入

这样说的有点粗糙，我举个例子吧(下划线开头的sass文件不会编译单独css文件)

——sass
  ——config                //基本变量
  ——mixin                 //函数
  ——common                //公用
    ——header
    ——aside
      ——_list.scss
      ——_nav.scss
      ——_base.scss
  ——compoment             //组件样式
    ——dropdown
    ——lightbox
  ——page
    ——index               //首页
      ——_ad.scss           //广告样式
      ——_content.scss      //内容信息
      ——_info.scss         //个人信息样式
      ——_base.scss         //index样式，@import 'ad';@import 'content';@import 'info';
    ——write               
    ——preview        
      ——_aside.scss       //preview页面独有侧边栏
    ——about
  ——main.scss             //导入所需要的样式，最终生成一个main.css

如上面所示的目录结构，能让人一目了然sass的目录的结构，维护的时候可以快速准确的找到文件。
如果是多页面的项目，也可以最大限度复用代码，而且可以导出公用样式，利用缓存提高加载速度，不用每个页面都重复写一样的代码。

注意：common文件夹的公共样式必须是其他页面所共有的样式，如果有些页面有特殊的样式，应该将会覆盖的css抽取出来，在页面中分别导入不同的私有样式。

根据命名规则限定使用样式

比如说preview页面有一个私有aside样式，可以在这样写preview里面的_aside.scss：

@charset "utf-8"/** 预览页面侧边栏* author：xxx* time:xxxx-xx-xx*/@import '../../common/aside/base'.preview{
  .aside{
    /* css */
    &__item{
      /* css */
    }
  }}

这里需要注意的是，css覆盖会导致重新渲染，影响性能。