如何搭建系统CSS架构

css是英文Cascading Style Sheets的缩写。 它是一种用来表现HTML(标准通用标记语言的一个应用)或XML(标准通用标记语言的一个子集)等文件样式的计算机语言。那么如何搭建系统CSS架构呢，一起来学习学习!

搭建CSS法则

在项目开始的时候，我们谈论了开发者关于他们的流程和痛点，并问他们的接口设计系统如何让他们的工作量变简单。

完成我的前端指导问卷，这些导致一系列前端规则和系统封装。这里有些我们创建的CSS具体规则。

模块化 —— 设计系统在每一个方面都是模块，这是非常实用写CSS的方法。这在组件之间需要清晰分隔。

可读性是关键 ——开发者必须在第一眼理解CSS代码，并且理解每一个选择器的目的。

清晰胜过简洁 —— 设计系统有时候看上去很冗长，但是作为交换，它提供清晰和韧性。保持CSS可读性和可扩展性意味着牺牲简洁的语法。

保持平面化 —— 长的选择器要回避，无论什么地方，尽可能保持CSS独立DOM和模块化。

避免冲突 —— 因为组件会部署许多不同的应用，保证设计系统之间的CSS不会和其他的库和系统有冲突，这很重要。通过系统空间命名Class名可以完成这个，更多的会在之后描述。

从这些规则中，我们搭建了制约和语法，包含了这些规则，以满足开发者的需求。这里有一个我们总结出的class语法：

全局命名空间

所有的Class都和设计系统关联的都以全局命名空间为前缀，这就是公司名称后面加一个连体符

.cn-

如果你工作的CSS框架是用于单个网站或者如果你对你的开发环境有绝对控制，那么引入全局命名空间是不需要的。但是如果你的设计系统是混合的技术，那么为系统特定代码创建一个标识是很重要的。作为第三方开发者，在多个环境中利用他们的系统，营销团队可能会失控，因此Lightning Design System引用了相似的方法到他们的系统之中(通过前缀.slds-)，在我们的例子中，许多我们客户的.开发者使用Angular，因此他们已经很熟悉命名空间的概念，因为Angular使用ng-作为命名空间，为Angular特殊的代码。

Class前缀

除了命名空间，我们添加前缀到每个Class，为了使之更加明显，这个这个Class是做什么的。下面是我们使用的类前缀：

c- 用于UI组件,比如.cn-c-card 或.cn-c-header

l- 用于布局相关样式, 比尔.cn-l-grid__item或.cn-l--two-column

u- 用于公共部分, 比如.cn-u-margin-bottom-double 或.cn-u-margin-bottom-double

is- 和 has- 用于特定状态, 比如.cn-is-active或 .cn-is-disabled. 适用于这些状态为基础的样式。

js- 用于目标特定功能, 比如.js-modal-trigger. 这些class没有绑定样式他们只是为了行为而保留的. 对于大多数案例, 这些 js- 类将在元素上会切换基于状态的类。

我被灌输来自Harry Roberts的一个概念，并且一开始在我认为这有道理的同事，我还是持有质疑的态度的，仅仅因为这是额外的字符并且我认为前缀会降低代码可读性。然而我的想法是不对的。在实施类前缀之后，我发现他们对于分清每个类的角色十分有帮助并且对于破译一个应用的代码库十分容易一目了然。对于设计系统用户，这种清晰的代码能够整理清楚头绪，特别有用。

BEM语法

BEM 代表了“块元素修饰”，这意味着：

Block 主要组件块, 比如.cn-c-card或者.cn-c-btn

Element 是主要块的一个子类,比如.cn-c-card__title

Modifier 是一个组件样式的各种变化, 比如.cn-c-alert--error

这种方法论已经很受欢迎了，将这些概念和全局命名空间和类前缀结合在一起，允许我们创造更明显封装的类名。

把它们都放到一起：解剖一个类

全局命名空间的结合，类别前缀，和BEM语法引出了一个明确的(是的，冗长的)类字符创，允许开发者们在构造UI的时候演绎他在之间扮演的角色。

让我们检查下以下的例子：

.cn-c-btn--secondary

cn- 是来自设计系统的用于所有样式的全局命名空间。

c- 是class的类别, 在案例中，c- 一位置“组件”

btn 是块名(“Block(块)” 就是BEM中的“B”)

--secondary 是一个修饰成分, 指向一个块的变化多端的样式 (“Modifier(修饰)” 就是BEM中的“M”)

这里有另一个例子：

.cn-l-grid__item

cn- 再一次出现就是系统的全局命名空间。

l- 是类的类别, 在这种情况下l- 意味着 “布局”

grid 是块名

__item 是一个元素, 表明那是块中的一个分支(“Element”在BEM中指“E”)

还有一个：

.cn-c-primary-nav__submenu

cn- 是系统的全局命名空间。

c- 是类的类别, 在这个例子中c- 意味着 “component”

primary-nav 是块名

__submenu是一个元素, 指出他是块的子元素 (“Element” 在BEM中是“E”)

此外，毫无疑问，这些类比大多数其他方法的类更加冗长，但是对于这种特殊的系统，这些约定很有意义。

其他技巧

明确细节

为了防止代码瓦解，我们详细说明如何处理这么多细小的细节，就像注释、代码块之间的空间距，tab还是space等等。感谢上天，Harry Roberts已经将一个极佳的综合的资源整合在了一起，称之为CSS Guidelines，对于这些类型的约定，这个作为我们的底线。我们梳理所有的代码并且标记出我们偏离Harry指出地方的计划。

Sass父选择器

我一直有个关于CSS的一个问题，是找出究竟在哪里放一个规定的规则。如果我有一个主要的导航组件，我要把这些样式放在头部还是在部分的主要导航Sass?谢天谢地，Sass父元素原则器出现了，这允许我们把所有的组件特定的样式放在一个根元素下：

.cn-c-primary-nav {

/**

* Nav appearing in header

* 1) Right-align navigation when it appears in the header

*/

.cn-c-header &{

margin-left: auto/* 1 */

}}

这意味着，所有的主要导航样式都可以在一个主导航Sass部分中找到，而不是将他们分成好几个文件。

Sass嵌套的明确规则

在Sass中嵌套可能十分方便，但是增加了糟糕输出的危险，会有过长的选择器字符创。我们遵循《盗梦空间》规则，嵌套永远不超过3层。

牢记设计系统的CSS平坦规则，我们希望在下列情况中限制嵌套：

一个样式块修饰

媒体查询

父元素选择器

状态

样式块装饰 对于装饰来说，如果规则只有几行长度，装饰块可以被嵌套在父元素中，就像下面这样：

.cn-c-alert {

border: 1px solid gray

color: gray

/**

* 错误弹出

*/

&--error {

border-color: red

color: red

}}

由于&符号，这会编译成：

.cn-c-alert {

border: 1px solid gray

color: gray}.cn-c-alert--error {

border-color: red

color: red}

对于长样式块，我们不会嵌套装饰代码，因为这减少了代码的可读性。

媒体查询器

组件特定媒体查询器能够在组件块中嵌套。

.cn-c-primary-nav {

/* Base styles */

/**

* 1) On larger displays, convert to a horizontal list

*/

@media all and (min-width: 40em) {

display: flex

}}

这个会被编译成：

.cn-c-primary-nav {

/* Base styles */}@media all and (min-width: 40em) {

.cn-c-primary-nav {

display: flex

}}

父元素选择器

设计系统会充分使用Sass的父元素选择器原理。这里允许所有的给定组件的规则在一个地方维护。

.cn-c-primary-nav {

/**

* Nav appearing in header

* 1) Right-align navigation when it appears in the header

*/

.cn-c-header &{

margin-left: auto/* 1 */

}}

这会被编译成：

.cn-c-header .cn-c-primary-nav {

display: flex}

cn-c-primary-nav所有样式都会在一个地方找到，而不是分散在许多部分文件之中。

状态

组件的状态必须包括在一个嵌套的元素之中。这包括了hover, focus,和active状态：

.cn-c-btn {

background: blue

&:hover, &:focus {

background: red

}}

这需要编译为：

.cn-c-btn {

background: blue}.cn-c-btn:hover, .cn-c-btn:focus {

background: red}

状态同样可以选用通用类的形式，比如is-和 has-:

.cn-c-accordion__panel {

overflow: hidden

max-height: 0

&.cn-is-active {

max-height: 40em

}}

者会被编译成：

.cn-c-accordion__panel {

overflow: hidden

max-height: 0}.cn-c-accordion__panel.cn-is-active {

max-height: 40em}

为了创建一个坚固的系统，将这些规则都放入一个地方中，给我们需要坚持的一些制约和规定。当我们遇到一些规定不是很明显或者有多重解决方案的情况下，我们需要一次谈话，讨论如何处理这些问题，如果需要的话可以更新方针。

css架构是我们在进行网页开发的时候需要使用的重要编程代码之一，而今天我们就一起来了解一下，一个好的css架构都应该具有哪些特点，下面就开始今天的主要内容吧。

我认为好的CSS架构的目标应该与所有好的软件开发的目标没有太大的区别。

我希望我的CSS是可预测的、可重用的、可维护的和可扩展的。

可被预测可预测的CSS意思是您的规则能按照您预想的方式运行。

当您添加或更新一个规则时，它不应该影响您的站点中您不想影响的部分。

在很少改变的小站点上，这并不重要，但在有数十或数百个页面的大站点上，可预测的CSS是必须的。

可复用CSS规则应该足够抽象和可被解耦的，您不必对已经解决的模式和问题进行重新编码，可以依靠现有的部分快速构建新的组件。

可维护当您的站点需要添加、更新或重新安排新的组件和特性时，这样做不需要重构现有的CSS。

向页面中添加某组件甲不应该破坏某组件乙。

可扩展随着站点的规模和复杂性的增长，通常需要更多的开发人员来维护。

可扩展的CSS意味着它可以由一个人或一个大型工程团队轻松管理。

这也意味着您的站点的CSS架构不需要大量的学习曲线就可以轻松学习掌握。

不能因为您是目前维护CSS的开发人员，就不考虑以后的变化。

常见的糟糕实践在我们寻找如何实现好的CSS体系结构目标的方法之前，我认为看看妨碍我们实现目标的常见实践是有帮助的。

只有通过了解那些不断重复的错误，我们才能开始接受另一种路径。

虽然在技术上是有效的，但它们的结果都导致了灾难和头痛。

尽管我的本意是好的，而且希望每次的开发会有所不同，但这些模式持续让我陷入困境。

根据组件的父类修改组件几乎在Web上的每个站点中都有一个特定的视觉元素，它与每个事件看起来完全相同，只有一个例外。

佳音北大青鸟http://www.kmbdqn.cn/认为当遇到这种一次性的情况时，几乎每一个新的CSS开发人员(甚至是经验丰富的开发人员)都以同样的方式处理它。

您要为这个特定的事件找出某个的父元素(或者创建一个)，然后编写一个新规则来处理它。

文件的组织

构建css系统的第一步是大纲的拟定。(我认为)css组织规划的重要性堪比网站目录结构。(htmlor注:用词夸张一点，让你加深记忆) 没有哪种方案放之四海而皆准，因此我们会讨论一些基本的组织方案，以及它们各自的利弊。

主css文件

通常可以使用一个主css文件，来放置所有页面共享的规则。这个文件会包含默认的字体、链接、页眉和其他等样式。有了主css文件之后，我们开始探讨高级组织策略。

方法一:基于原型

最基本的策略是基于原型页面(archetype page)分离css文件。假如一个网站的首页、子页面和组合页设计不同，就可以采用基于原型的策略。(这种策略下)每个页面都会有专属的css文件。

在原型数量不多的情况下，这个方法简单明了、行之有效。然而，当页面元素并不按部就班的位于各个原型页时，问题就出现了。如果子页面和组合页共享某些元素，而首页却没有，我们应该怎么做呢?

把共享元素放入主css文件。这虽不是最纯正的解决办法，却适用于某些具体情况。可是如果网站庞大，(这样做的话)主css文件会迅速膨胀——这就违背了分离文件的初衷:避免导入不必要的大文件。

在组合页和子页面的css文件里各放一份样式代码。(这么做)就意味着要维护冗余代码，很显然我们不想这样。

创建一个新的文件，由这两种页面共享。这听起来不错。不过假如只有10行代码，我们创建这个

文件仅仅是为了共享这10行代码?(htmlor注:杀鸡用牛刀?)

这方法很纯粹，但如果网站庞大有很多对页面共享很少量元素时(htmlor注:比如30对页面分别共享10行代码)，就显得很笨重了。

创建一个单独的css文件，包含所有共享元素的样式。这方法可能比较简单，却要取决于网站的大小和共享元素的多少。有种情况会很烦:导入了一个很大的css文件，但页面只用到一小部分样式——还是那句话，这违背了分离文件的初衷。

这就是我所说的重叠的两难(overlap dilemma)。零碎css规则的重叠不一而足，并没有一个完全清晰无误的方案来组织它们。

方法二:基于页面元素/块

如果网站使用服务器端include，这个方法会很不错。举例说明，如果使用页眉include，它会有自己相应的css文件。页脚或者其他部分的include可以如法炮制，只须导入自己的css文件。这个方法简单干净，不过可能会产生很多小css文件。

举例来说，假如页脚的样式只需要20行css代码，单独创建一个文件就划不来了。而且这个方法会导致每个页面都包含一堆css文件——因为有多少include，就得有多少css文件。

方法三:基于标记

这个方案直观实际，与前一个类似。如果网站共有30个页面，其中10个含有form，那么可以创建一个css文件专门处理form的样式，只在这10个页面导入它。如果另外10个页面含有table，就创建一个文件专门处理table样式……诸如此类。

另外的组织技巧

除了用主观的方法组织文件，我们还要考虑如打印、手持设备和屏幕等多种媒体类型。这虽然已经很清楚的定义过，可依旧是建立文件结构时应该考虑的一个因素。一旦必须支持多种媒体类型，主css文件里的某些规则可能就得重新考虑。

另外，品牌联合也可能是一个重要因素。(htmlor注:如google和nike联手推出的joga) 如果涉及品牌联合，你就得考虑哪些元素应该调整以适应另一品牌。比如分别使用不同的css文件等。

还有一个常被忽略的技巧:使用嵌套的@import语句。只包含一连串@import语句，

或者再加几句css规则，就能创建一个css文件。用这个方法完全可以创建网站的主css文件(用@import导入各部分的样式文件)。假如网站的每个

页面都导入了4到5个不同的css文件，无疑你应该考虑使用这个技巧。

规则和选择器的组织

谈完了文件组织，接着讨论一下怎么组织文件里的东西吧。很自然，我们希望在文件里畅通无阻的浏览，迅速找到要编辑的选择器(selector)或规则。

冗余 vs. 附属

正如Dave Shea在其文章《冗余 vs. 附属》(Redundancy vs.

Dependency)里所说的，你必须不断了解级联(cascade)。你要决定是对选择器编组(意味着附属)，还是把它们分离(意味着冗余)。编组可

以保持代码简洁扼要，可是会建立附属关系，导致维护开销增加。如果不编组，就会增加文件大小，让相似的选择器保持一致变得困难。只有做好这种权衡、取舍，

才能每次都作出正确的决定。

按相互关系/上下文编组

既然文件组织可以是主观的，那么显然，按照规则和选择器与其他部分的相互关系来进行编组是最好的方法。举例说明，假设你用容器、页眉和页脚来完成布局，就应该把它们编成一组。

这似乎很简单，其实不然。比如，把页眉中的导航加入css时，是将它跟父元素编组还是独立编组?这种情况下，要视乎规则的上下文。通常，页眉与页面布局相关，应该与其他布局元素一起编组。而导航是页眉的一块，应该和页眉的其他块编组，而不是页眉本身。

使用注释

跟大多数代码类似，注释是组织良好与否的关键。应该根据css的控制范围，清楚的标注每节(section)。最好确保注释视觉突出，以便在内容滚动、一目十行时快速定位。

Doug Bowman在其文章《css组织技巧之一:标记》(CSS Organization Tip #1: Flags)里把css注释玩得高明之极。他详细说明了在节名之前加上等号，以便使用文本编辑器的查找功能迅速跳到某节。

别忘了

你应该细致认真的了解了特异性、级联和继承，并善用它们。它们之中的每一项都可以是你最可怕

的敌人，也可以是你最友善的朋友。当建立庞大的网站时，是否理解这些细微精妙之处，决定了你所构建的是坚如磐石的系统，还是经不起风雨的豆腐渣工

程。(htmlor注:这句完全意译，比较爽)

属性的组织

现在我们了解了文件的组织，也知道了文件内规则的组织，但还有一个重要的组织环节(没有提到)，那就是属性(attribute)。虽然属性比前两个概念更简单，可是还有一些非常好的、能够保持规则整洁的方法很值得一提。

按字母排序

提到属性，如果说需要遵循什么原则的话，那就是:按-字-母-排-序。其实这招对于属性浏览帮助不大，不过可以防止属性值覆盖这种偶然事件的发生。

举个例子吧，已经数不清有多少次，我为某个选择器定义过了margin值，之后的某天无意间

又加了一个(或前或后)。(这种情况下)后一个属性自然会起作用。假设不知道第二个属性存在，不管我怎么调整第一个属性值、刷新浏览器，也看不到页面变

化。(htmlor注:这个问题我深有体会) 如果按照字母顺序排列，你就会发现margin被定义了两次(因为它们挨在一起)，这个问题自然可以避免。

优先项

当网站复杂、牵涉太多css文件时，会建立大量的附属关系。一旦需要定制某个元素特有的样式，!important选项似乎是最佳选择。没错，!important是能解一时之需，但最好搞清楚导致问题的根源，然后根据级联关系决定是否真的需要用它。

如果你对上文提到的特异性、级联和继承很熟悉，大可不必抱着!important一颗树不 放。(htmlor注:整片森林等着你~)

当然它还是会派上用场，不过使用之前要对具体情况了然于胸。千万不要因为不知问题的症结所在而把!important当作捷径或是补救方案。

小结

当我们变得依赖css而使样式表日渐复杂时，就需要正确的计划来避免犯错，并使代码易于维护。既然完美无缺的方案并不存在，那么了解css的工作方式以及文件、选择器和属性的多种组织方案，无疑有助于我们写出优质的代码，经受住时间考验。

网站运营www.wzyunying.com

---