Einige Tipps zum Schreiben von CSS

Javascripty hat den Weg des Engineering eingeschlagen. Wir werden hier nicht auf JS eingehen. Lassen Sie mich über einige meiner Erfahrungen beim Schreiben von CSS in der Praxis sprechen. Natürlich ist das, worüber ich spreche, definitiv nicht so gut wie das, was die Experten einfach selbst geschrieben haben Berufserfahrung und teile sie mit allen.

Wenn Sie Ihre Arbeit gut machen wollen, müssen Sie zuerst Ihre Werkzeuge schärfen

Beim Schreiben von CSS müssen Sie mindestens ein Entwicklungstool beherrschen. ob es sich um SASS handelt, es ist immer noch WENIGER. Im Wesentlichen sind sie gleich, aber die Syntax ist etwas anders. Wenn Sie CSS immer noch von Hand schreiben, informieren Sie sich bitte so schnell wie möglich darüber, wählen Sie eines davon entsprechend Ihren eigenen Gewohnheiten aus und verwenden Sie es. Persönlich bevorzuge ich Sass, was eher zu meinen Schreibgewohnheiten passt. Es gibt auch viele Leute, die Less mögen. Sie denken, dass die Less-Syntax bequemer ist.

Was SASS/LESS

SASS (LESS) ist eine Erweiterung von CSS3, die Regelverschachtelung, Variablen, Mixins, Selektorvererbung usw. hinzufügt. Konvertieren Sie es mithilfe von Befehlszeilentools oder WEB-Framework-Plug-Ins in standardmäßigen, wohlgeformten CSS-Code.

Warum brauchen Sie SASS/LESS?

Als Entwicklungstool bieten sie viele praktische Schreibmethoden, die Designern viel Zeit sparen und die CSS-Entwicklung einfacher machen wartbar.
Sie sind auch der Grundstein für das Schreiben von modularem, wartbarem CSS.

Verwendung

Es gibt viele Tutorials zu SASS/LESS im Internet, daher werde ich hier keinen Platz verschwenden, um über die grundlegende Syntax zu schreiben.
Sie können selbst online suchen. Sobald Sie eines gelernt haben, können Sie es grundsätzlich verwenden:

Ich verwende SASS als Beispiel für den Inhalt , WENIGER gilt auch!

Gott sagte, es gibt keine Regel ohne Regeln

Ja, es gibt keine Regel ohne Regeln. Sie müssen einen CSS-Namensstandard verstehen oder Ihren eigenen Standard formulieren (. Es wird nicht empfohlen, es selbst anzupassen) Definition, nicht förderlich für Teamarbeit);

Warum ist eine Namenskonvention erforderlich?

Wenn Sie viel CSS geschrieben haben, werden Sie feststellen, dass es Ihnen schlecht geht, wenn Sie keine effektive Namenskonvention haben. Dieses Gefühl macht sich besonders bemerkbar, wenn Sie an einem etwas größeren Projekt arbeiten oder es gemeinsam mit anderen entwickeln. Denn wenn Sie das CSS benennen, werden Sie feststellen, dass der Name an anderer Stelle verwendet wird oder ein Teamkollege ihn bereits verwendet hat, und Sie müssen ihn umbenennen. Mit der Zeit wird die Benennung von CSS chaotisch, stinkend und lang, und es ist unmöglich, die Bedeutung der Benennung auf einen Blick zu erraten.

BEM-Benennungsstandards

Verschiedene Benennungsstandards sind unterschiedlich, und die Weisen haben unterschiedliche Meinungen. Hier werde ich die BEM-Benennungsstandards vorstellen, die möglicherweise nicht geeignet sind Für Sie müssen Sie darüber nachdenken, welche Namenskonvention zu Ihnen passt. .

BEM ist eine vom Yandex-Team vorgeschlagene Benennungsmethode für CSS-Klassen mit dem Ziel, CSS/Sass-Module besser zu erstellen.

BEM bedeutet Block, Element und Modifikator.

●Block: Es kann als Region, Komponente oder Element auf Blockebene verstanden werden. Die spezifische Unterscheidung muss basierend auf der tatsächlichen Situation analysiert werden.

●Block__Element: Dies ist der Fall ein Element im obigen Block, wenn es beispielsweise ein a-Tag (a: element) in der Navigation (nav: block) gibt, ist es ein Block und ein Element, die durch zwei Unterstriche verknüpft sind >●block__element–modifikator: Mein Verständnis ist Zustand oder Attribut. Beispielsweise hat ein Tag im Element drei Zustände: aktiv, schwebend und normal. Diese drei Zustände sind Modifikatoren. Der Mittelwerter verwendet zwei „–“-Bindestriche, um

Für das oben erwähnte Beispiel werde ich den tatsächlichen Code zur Demonstration verwenden:

<!-- 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{ }

Es ist ersichtlich, dass mit SASS und BEM ein leicht lesbarer, wartbarer und modularer Code geschrieben werden kann

Ein lesbares SASS muss eine Beschreibung haben.

Für eine SASS-Datei müssen Sie mindestens zwei Punkte erklären, ob diese SASS öffentlich oder privat ist, welche Seite und welcher Teil

@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;
  }}

●Reset

Es gibt viele CSS-Reset-Codes im Internet. Sie müssen nur @importieren „Kompass/Reset“. Wenn Sie der Meinung sind, dass diese Codes zu redundant sind, müssen Sie zumindest sicherstellen, dass in Ihrem CSS die Ränder und der Abstand zurückgesetzt wurden, damit Sie sicherstellen können, dass das CSS in jedem Browser den gleichen Stil hat.

*{
  margin: 0;
  padding: 0;}

●Schriftgröße

●Farbe

●Ebene

●Höhe

......

Die Verwendung einer separaten Variablen hat viele Vorteile Das größte Problem ist die Wartbarkeit. Wer es nutzt, weiß Bescheid!

●Wenn Sie mit der Entwicklung fertig sind, bringen Sie es zur Abnahme zum Designer. Der Designer sagt, das sei nicht gut, also ändern Sie die Farbe! ——Es ist okay, ich werde die Variable ändern!

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

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

……

这些例子可以让你明白有一份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覆盖会导致重新渲染，影响性能。