【转载】大型项目中的结构化CSS

特别声明:如果您喜欢小站的内容,可以点击申请会员进行全站阅读。如果您对付费阅读有任何建议或想法,欢迎发送邮件至: airenliao@gmail.com!或添加QQ:874472854(^_^)

本文转载自:众成翻译 译者:dreamforker 链接:http://www.zcfy.cc/article/785 原文:https://medium.com/peergrade-io/structuring-css-in-large-projects-37f1695f5ec8#.wyys1qbhg

写CSS很容易。 写持续可维护的CSS则很难。

你也许听说过不下100 次了。因为在CSS中默认都是全局的申明。如果你是个写C的程序员你知道全局变量是糟糕的。如果你是程序员你会知道,独立及可组合的模块是一个可维护系统的关键所在。

已经有很多CSS指南帮助人们构建可维护的CSS: SMACSS, OOCSS, BEM, ITCSS, ACSS, CCSS, Atomic Design, Maintanable CSS, rscss, 也许更多.

然而CSS的问题在哪里呢?

span {
  font-size: 11px;
}

.header-right {
  font-size: 22px;
  text-align: right;
}

如上的CSS定义, 样式立即生效于全局,并且影响到引用到此段代码的所有页面。 这里没有封装,没有独立的模块。

在一个标准的程序语言中, 仅为需要实现的方法引入需要的模块即可,例:

# Python modules
import requests
from Flask import url_for

// Node modules
var express = require(‘express’)

这样就知道引入模块将会怎样影响到你的代码,且引用的资源会明确影响到你正在实现的功能。

在CSS中这种角色是相反的。每次我写一行CSS时,会潜在地影响到项目中所有的东西,并且无意中改变了我当前工作以外其它页面的展现。 我的样式不仅仅是外泄, 它们像洪水般涌进我应用中的所有角落和缝隙。

现在这就变得好理解了,那些基本排版、文本输入框以及全局继承的样式就显得合理了。这是HTML和CSS为何被构建出来根本原因。这些语言工具是公开创建的。 想理解这些语言背后的原因,我常想去排版一本书:想每页看起来是类似的, 想一个简单连贯的样式贯穿始终但不需要那些冗余的CSS代码。那就是为何<h1-6>,<section>等标签合理存在的原因,并且始终能影响全局的样式。

然而,世界已经变化,Web也已经变化。 我们不再构建 Web 页面,我们开始创建Web应用。我们今天不再需要从Web上请求很多资源,到处都是已经内建好的HTML和CSS公共模块。

事实上这些谓之为一个 特定样式的新方式,也可能是一个构建web的新方式。但是如今,我们已经被CSS和HTML纠结良久,那意味着我们要小心翼翼的去用那些工具制作可管理和可维护的Web应用。

Peergrade.io处理CSS的方式

规则1: 使用前缀 (class类名)

在Peergrade.io中我们在所有样式名中使用前缀 .pg。 在你的CSS代码中如果不使用前缀可能会带来些麻烦。原因是无前缀的类名最终将会导致和引入的样式冲突。例如你需要一个选色器datepicker - 你绝对不希望胡乱拼凑的去构建它(至少我不希望如此!),所以你引用了这个组件。 现在你可能在你的样式中随处可见类似 .prev, .next.separator等的类名, 如果你不用前缀它们可能会和你的类名有潜在的冲突。

在很长一段时间内字体是不会在类名中用前缀的, 那意味着你经常会遇到.icon-***之类为前缀的命名冲突(现在他们用 **.fa前缀)。我们仍然拥戴作者Mark Otto,虽然我们对他无后缀名的Bootstrap有一点失望。

规则2: 不要嵌套CSS选择器

在Peergrade.io中用到了Sass。 用Sass时,Sass本身有能够快速和HTML匹配的模式,例如:

#user-profile-page

  .profile-description
    h3

    ul
      li
        a

过不了多久你会意识到 - 它其实很不友好。当你写它的时候,你也许会想这里仅有一个.profile-description的列表命名,但一两个月后, 你必须要增改另一个列表时,混乱的结构已经超出你想到的范围。

同样,可以在父元素内的子元素中独立定义样式 - 这并不会受到你在Sass这一层已经定义好样式的影响。

你可以通过subtlebrittle ways 在CSS中通过做选择器的嵌套来绑定你的HTML结构。

规则3: 构建组件时用边界元法(BEM)命名

尽可能试着用BEM命名去创建独立的组件,我们不必完全按照BEM的规范 - 只是命名组合,这意味着类名以如下的方式命名:

.block__element--modifier

为了达到这些我们按照如下构建Sass:

.pg-deadline
    &__date
        // becomes `.pg-deadline__date`
        color: $color-gray

    &__header
        // becomes `.pg-deadline__header`
        font-weight: 700

    &--highlight
        // becomes `.pg-deadline__header--highlight`
        color: $color-green

如下我们用Sass嵌套去创建BEM类名命名方式。多少有点违背常理, 这实际会产生大量的扁平化CSS结构 - 没有嵌套 - 仅仅只有头部的类名定义。

如规则2预期我同样可允许.block--modifier 方式的类名:

.pg-deadline--editable
  .pg-deadline__header
    background-color: $color-blue

  .pg-deadline__date
    color: $color-black

在这个特殊例子中我们允许一层的CSS选择器嵌套。 这允许我们仅可以修改在特定块(block)级别的修饰符, 并且在子块中不能重复修饰符(“E”在BEM中即元素elements)。

为了更好的理解BEM体系,可以转向这里 - 由Harry Roberts写的CSS指南 :BEM形式的命名。(事后我们碰到类似的CSS时,自然会提及到Harry的这个命名体系)

向前看

看来没有人真正找到CSS最好的解决方案, 并且当看到Hacker News最新文章后, 相比较现状,我多少会有些失望。

归根结底:我们相信我们找到了一个CSS的可持续发展的根本, - 当然有更多改善的空间。 这计划就是去经常检查我们的指南书,去看看任务是否如我们所期望的那样去执行, 是否有必要去修正。

我们收藏的一些CSS参考

  • Harry Roberts’ CSS指南书
  • CSS魔法 博客 (同样是 Harry Roberts的)
  • 可维护的CSS 框架
  • https://philipwalton.com/articles/side-effects-in-css/Air Jordan 3 For Kids-033

如需转载,烦请注明出处:https://www.w3cplus.com/css/structuring-css-in-large-projects.html

如果文章中有不对之处,烦请各位大神拍正。如果你觉得这篇文章对你有所帮助,打个赏,让我有更大的动力去创作。(^_^)。看完了?还不过瘾?点击向作者提问!

赏杯咖啡,鼓励他创作更多优质内容!
返回顶部