如何搭建系统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}

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

CS/CSS架构应用的软件性能测试模型分析

作者：夏海涛 出处：测试员杂志

1. CS/CSS系统架构的基本概念 1.1系统架构定义

虽然B/S结构、J2EE架构愈来愈成为流行模式，但基于传统的C/S结构的应用程序还广泛地应用于各种行业。尤其是金融行业中的商业银行柜面－核心帐务系统等。一方面由于传统商业银行一般都有大量的字符终端等需要复用的设备，一方面也是因为他们存在大量密集的对实时性要求很高的高柜业务，使用传统的基于C/S结构或者C/S/S结构的应用效率更有保证。

C/S结构即CLIENT/SERVER结构。传统的C/S结构一般分为两层：客户端和服务器端。该结构的基本工作原理是，客户程序向数据服务器发送SQL请求，服务器返回数据和结果。客户端负责实现用户接口功能，同时封装了部分应用逻辑。服务器端的数据库服务器主要提供数据存储功能，也通过触发器和存储过程提供部分应用逻辑。

C/S/S结构即客户/应用服务器/数据库服务器三层结构，中间增加了应用服务器，通常实现应用逻辑，是连接客户与数据库服务器的桥梁。它响应用户发来的请求执行某种业务任务，并与数据库服务器打交道，技术实现上通常选用中间件产品，如BEA公司的TUXEDO和IBM公司的CICS等。（事实上J2EE架构的应用也属于这种三层或多层结构，这里不包括。）

三层或多层C/S结构与两层C/S结构相比，它的优势主要表现在：安全性加强、效率提高、易于维护、可伸缩性、可共享性、开放性好等。 1.2系统架构示意图

1.3CS/CSS系统架构中性能测试的特点 1.3.1CS/CSS系统架构的性能影响因素

由于CS/CSS系统的以下特性，测试工程师对一个CS/CSS系统实施性能测试具有很大的难度： *整个系统的各个部分使用多种操作系统，性能上有差别；

*整个系统架构的各个环节上使用多种数据库，同样在性能上有差别；

*应用是多个，分属多个种类，分布在不同设备上，包括自行开发的应用、第三方的应用； *系统中的设备、组件通过不同协议进行连接、通讯；

*系统的内部接口多，性能瓶颈多；而系统的整体性能往往取决于最差的部分；需要分别测试和联合测试

*系统的性能指标不光同应用系统架构有关，还和具体行业应用的业务模式有关； *采用此架构的行业应用往往是一个7×24小时系统；

*采用此架构的行业应用可能高柜业务多，这样会影响对性能度量项的选取和转换； *各个环节基本上以交换数据报文的方式通信，其格式经常会比较复杂。

因此这样的系统对于对测试工程师的知识的深度和广度都是一个考验。对于这样的系统，到底如何使用什么样的测试策略、如何分析测试需求、如何选取性能度量项的转换计算模型、如何确定测试内容和轮次、如何设计性能测试案例等等以及规划和实施性能测试中的其它诸多问题，都需要遵循一个系统的方法来解决。

1.3.2CS/CSS系统架构中性能测试的基本策略 1. 确定好测试工作范围

首先可以分析压力测试中最容易出现瓶颈的地方，从而有目的地调整测试策略或测试环境，使压力测试结果真实地反映出软件的性能。例如，服务器的硬件限制、数据库的访问性能设置等常常会成为制约软件性能的重要因素，但这些因素显然不是用户最关心的，我们在测试之前就要通过一些设置把这些因素的影响调至最低。

另外，用户更关心整个系统中哪个环节的性能情况也会影响工作范围。如有的环节是全新系统，而有的环节已经是成熟系统只是稍有改动，这样可能全新系统的局部性能测试就需要系统和全面一些。 2. 分析好客户的性能测试需求

客户是已经明确提出了性能指标，还是只提供了用户使用方式和历史交易流量数据，需要我们自己进行性能基准的计算？性能测试的目的是验证系统性能还是想确定目标系统的理想配置？是否还要使用测试结果预测在不同机型的处理能力？是否要求在性能测试各个轮次中安排性能调优过程等等问题都需要有针对性的解答。

3. 要作好性能测试的计划和方案

测试计划和方案中要注意测试需求分析阶段提出的问题的解决。 4. 确定的测试通过准则、性能测试的计划、结果要获得客户的认可

要和客户确认，系统的性能指标达标的标准是什么；对于性能测试中各个部分和步骤的计划和结果，甚至是性能测试过程，都要根据其重要程度，决定是否需要客户进行确认和签字。获得客户的认可是最重要的。

1.3.3CS/CSS系统中性能测量与性能探测 性能测量

1. 在性能测试开始前必须认真规划性能测量：

软件性能测量技术范围很广。可以包括日志、事件计数、事件持续时间、采样等性能测量技术。 *确定性能测量的策略：我们要测试什么？ *规划性能测试中使用什么样的测量工具。

关于如何处理网站的CSS，各个网站做法都不一样，这随着网站的性质及大小不同，公司前人留下的规范不同，以及CSS工程师的眼界不同而有所不同。由于我从业经历有限，所知甚浅，只能说些肤浅业余的内容，不准确之处欢迎指出。

就CSS文件而言，有的网站分为header.css, body.css, footer.css，不做评价；

有的分为reset.css, main.css, content.css，不做评价；

有的分为common.css,然后每个种类的页面一个CSS，例如home.css(主页), album.css(相册页面),message.css(站内信页面),blog.css(日志页面)等，不做评价；

有的分为base.css，然后每个活动页面一个单独的CSS，等，不做评价；

还有的直接将CSS嵌在页面中，而非外部链接调用，不做评价。

这些不同的处理方法，没有什么正确与错误之分，只有适合不适合。每种方法都有其存在的道理，所以我是没有资格做任何评价的。

就每个CSS文件的内容而言，一般都会有一段长长的CSS reset（样式重置），然后就是有着统一前缀，命名较长的样式内容，就像人人网的部分样式截图：

使用长命名，统一的父级命名避免样式冲突时无可厚非的。确实！曾经我也如此。

三、我是如何对网站CSS进行架构的

首先关于CSS文件，我一般只使用一个文件，这无关于网站的大小，网站越大，某种意义上我这种做法的优势与潜力就会体现的越明显。我这种单CSS文件的做法适合于web2.0的网站，例如像是SNS网站（开心、人人、白社会），嘀咕网，虾米网，凡客这类网站，如果是门户网站，sorry，铁定不适合。

让网站单CSS谁都会，关键是为何可以使用单CSS文件，这个CSS文件不会很大吗，如果一个网站有400个页面，那么这个CSS文件岂不要数百K。非也，在网站页面风格一致，在web系统结构良好的情况下，CSS文件可以控制的非常小，而且高性能，同时页面扩展性也非常好。下面就开始一点一点的展示，内容较多，需要慢慢来~~

1、整体概述

页面布局与文章内容显示需要，我将整体架构做成了一张图片，见下图：

2、关于CSS reset

CSS reset(css重置)基本上是不需要的，至少可以说80%的的CSS reset都是没有必要的，反而增加了页面CSS 的overwrite，尤其像开心网*{margin:0}这样子业余的做法更是要不得（反而破坏了很多UI的兼容性，比如说单复选框等）。我不是一概鄙弃CSS reset，有些常用标签我也是会简单重置一下的，而且会避免overwrite（样式重写），以保证样式最精简，渲染最高效。如下代码示例：

body{

line-height:1.4

color:#333

font-family:arial

font-size: 12pxbackground:white}

input,textarea,select{font-size:12pxfont-size:100%font-family:arialfont-family:inherit

}

body,h1,h2,h3,h4,h5,h6,p,ul,ol,form{

margin:0

}

h4,h5,h6{

font-size:1em

}

ul,ol{

padding-left:0

list-style-type:none

}

/*image with no-border*/a img{border:0}img{border:0}

这就是我全部的CSS reset。就这些就足够了，我是没有遇到什么兼容性的问题，不要盲从于一些主流的做法，就这些，足够了。

3、关于CSS通用样式库

完整的通用样式库如下（您可以根据自己的喜好重命名或是添加删除部分样式）：

.l{float:left}.r{float:right}.cl{clear:both}

.n{font-weight:normalfont-style:normal}.b{font-weight:bold}.i{font-style:italic}

.fa{font-family:Arial}.fg{font-family:Georgia}.ft{font-family:Tahoma}.fl{font-family:Lucida Console}.fs{font-family:'宋体'}.fw{font-family:'微软雅黑'}

.tc{text-align:center}.tr{text-align:right}.tl{text-align:left}

.tdl{text-decoration:underline}.tdn,.tdn:hover,a.tdl:hover{text-decoration:none}

.g0{color:#000000}.g3{color:#333333}.g6{color:#666666}.g9{color:#999999}.red{color:red}.wh{color:white}

.f0{font-size:0}.f10{font-size:10px}.f12{font-size:12px}.f13{font-size:13px}.f14{font-size:14px}.f16{font-size:16px}.f20{font-size:20px}.f24{font-size:24px}

.vm{vertical-align:middle}.vtb{vertical-align:text-bottom}.vt{vertical-align:top}.vn{vertical-align:-2px}.vimg{margin-bottom:-3px}

.m0{margin:0}.ml1{margin-left:1px}.ml2{margin-left:2px}.ml5{margin-left:5px}.ml10{margin-left:10px}.ml20{margin-left:20px}.mr1{margin-right:1}.mr2{margin-right:2px}.mr5{margin-right:5px}.mr10{margin-right:10px}.mr20{margin-right:20px}.mt1{margin-top:1}.mt2{margin-top:2px}.mt5{margin-top:5px}.mt10{margin-top:10px}.mt20{margin-top:20px}.mb1{margin-bottom:1px}.mb2{margin-bottom:2px}.mb5{margin-bottom:5px}.mb10{margin-bottom:10px}.mb20{margin-bottom:20px}.ml-1{margin-left:-1px}.mt-1{margin-top:-1px}

.p1{padding:1px}.pl1{padding-left:1px}.pt1{padding-top:1px}.pr1{padding-right:1px}.pb1{padding-bottom:1px}.p2{padding:2px}.pl2{padding-left:2px}.pt2{padding-top:2px}.pr2{padding-right:2px}.pb2{padding-bottom:2px}.pl5{padding-left:5px}.p5{padding:5px}.pt5{padding-top:5px}.pr5{padding-right:5px}.pb5{padding-bottom:5px}.p10{padding:10px}.pl10{padding-left:10px}.pt10{padding-top:10px}.pr10{padding-right:10px}.pb10{padding-bottom:10px}.p20{padding:20px}.pl20{padding-left:20px}.pt20{padding-top:20px}.pr20{padding-right:20px}.pb20{padding-bottom:20px}

.rel{position:relative}.abs{position:absolute}

.dn{display:none}.db{display:block}.dib{-moz-inline-stack:inline-blockdisplay:inline-block}.di{display:inline}

.ovh{overflow:hidden}.ovs{overflow:scroll}.vh{visibility:hidden}.vv{visibility:visible}

.lh14{line-height:14px}.lh16{line-height:16px}.lh18{line-height:18px}.lh20{line-height:20px}.lh22{line-height:22px}.lh24{line-height:24px}

.fix{*zoom:1}.fix:after,.fix:before{display:blockcontent:"clear"height:0clear:bothoverflow:hiddenvisibility:hidden}.z{_zoom:1}

上面的样式是有简单的分类的，某种意义上讲，CSS库与js库属于类似的东西。

关于此样式库，您可以直接在您的页面头部<head>标签内嵌入如下代码：

<link rel="stylesheet" href="http://www.zhangxinxu.com/study/css/zxx.lib.css" type="text/css" />

如果您想下载此CSS文件，您可以狠狠地点击这里：(右键-[目标|链接另存为])。您可以随意修改，如果能保留我的一个个人信息，那真是感激不尽~~

4、网站CSS样式库

这里的样式是根据当前实际的项目内容指定的。例如，文字链接颜色是什么，文字链接经过的样式是什么；一些常用的背景色样式，常用的边框样式等，以及一些高宽等。按照我的经验，网站CSS样式库又可以架构为以下几部分：

①网站常见颜色，尤其是链接色

②网站常见背景色（我习惯用bg+颜色前2字母表示，例如.bgf7表示background:#f7f7f7）

③网站常见边框色，这里类似于CSS 通用库中的margin属性，需拆分，例如.bbdd表示border-bottom:1px solid #ddd每人的命名习惯不一样，但是尽量简单为好，甚至您可以像Google一样，直接两个字母（大小写混搭）表示。另外，一定要告知设计师，边框取色不宜多，不能凭感觉，要有所牺牲，也就是如果之前使用了#cecece的边框色，后面的即使使用#d0d0d0更好看，请使用#cecece代替，这就是团队协作。

④网站遗留的单margin属性，例如，某一div留白较大，有个单独的margin-top:35px的属性，ok，这个属性请放在网站CSS样式库中，以.mt35{margin-top:35px}保留，以供之后类似布局或需要的地方使用。

⑤网站遗留的单padding属性，例如，双栏自适应布局时，无论是浮动自适应，还是绝对定位自适应，都需要使用padding-left值，此时的padding-left多单样式，可抽取出来，以网站样式库的形式存在。记住，是单属性，且不可从通用元素中抽取单独的padding值，否则是给自己挖火坑。

⑥网站遗留的width属性，在流体布局思想下，宽度是有限的，是珍贵的，需好好利用。

⑦网站常用的一些height属性，指一些高度值，例如height:18pxheight:20pxheight:24pxheight:50pxheight:100pxheight:200px等。

记住一个原则：网站通用的元素（按钮，导航，选项卡的）的样式千万不能分离作为网站的CSS样式库。

5、网站通用小图标样式集

小图标的样式合并是普遍处理的较好的，由于其规律可循，所以经常在CSS文件较上的位置看到有关小图标的CSS合并样式，这在SNS网站中很是常见。一般合并样式部分样式为{background:url(xx.png) no-repeat}，分离部分的样式是{background-position:x, y}，就实现而言，我觉得没有多少说头，只是命名有些自己的见解。在小图标样式命名的时候，我的建议是不要关联图片的内容，比如说一个相册的下图标，不应该使用iAlbum这样的命名。原因有三：

1. 思考图片的命名杀死n多脑细胞

2. 命名较长，占用字节数，也就是CSS文件大小

3. 也是最重要的，后期的维护。设想下，如果日后相册的图标不再被使用了，原来相册图标的位置可以被其他小图标（如RSS小图标）替换吗？理论上可以，实际上，我们除了必要的html替换，还需要重新修改图标样式的命名，即iAlbum→iRss的命名，而往往取而代之的做法是直接在后面添加新的图标。

我目前的做法是使用一个不常用的标签作为网站的小图标专用标签，例如s标签，或是u标签，我习惯将小图标单独为一个小图标Sprite，每个图标放在20*20像素的格子中。在这种情况下，我都是使用矩阵命名法。命名只关联位置，例如，我使用u标签作为整个网站的小图标专用标签，则按照图标的位置（假设一行20个图标），我会依次命名为：u00,u01,u02…u019,u10,u11,…u119…。这种命名的好处是不用关心到底哪个位置是那个图标，不用担心命名冲突，在小图标位置以及内容更换的情况下也无需重命名。

例如，上图中标注的u113的意思其实是u(1,13)，这种小图标命名的方法我称之为“小图标矩阵命名法”。此命名略有不足在于在使用小图标时需要打开源文件或通过注释准确查询到对应的class。

6-10、网站通用样式

这里的“网站通用样式”可以说与“网站通用样式库”最为对立的两部分。网站通用样式专指“独立元素”的通用样式，所谓“独立元素”指的是网站通用的导航，菜单，按钮，选项卡，文本框装饰，图片装饰，圆角处理等等。这些“独立元素”的样式千万不能对其进行分离并归入“网站通用样式库”中，否则，日后会给你留下无尽的痛苦的！

我几乎从不对按钮或是导航进行定宽，都是宽度自适应，这样，可以大大节约Sprite背景图片以及CSS代码的成本。以前多有探讨，这里不多说了。

网站通用样式的代码量在整个CSS文件中所占据的比重是相当大的，如果您的CSS文件中发现CSS通用样式只占整个CSS文件的一小部分，尤其网站项目较大时，那就需要引起警惕，可能最后的结果就是CSS文件超负荷，最后反而一团糟。

11、网站公共结构样式

所谓“网站的结构样式”主要指的是最外框div的样式，一般限制网站的宽度(960~990不等)，还有就是网站的分栏布局样式，这里的样式仅仅针对主体结构，例如left_part，或是right_part；还包括网站的头部的一些公用结构，底部的样式结构等。

我是强烈建议公共结构仅仅定宽定高，设置浮动属性，切不可在结构样式上添加margin或是padding属性，这会使网站的公共结构的重用性大大降低！

12、单页面的精细结构

如果上述11项您都架构的非常好，那么您在编写每个具体页面的时候，就会非常轻松，非常迅速。因为80%~90%的样式都可以从上面11项中直接拿来用（上述11项全部都是网站公用样式）。

对于中型大型网站，我们可能要花3~4天甚至更多的时间分析页面设计图，处理CSS Sprite，架构网站的CSS，这段时间不写任何页面，就是处理网站（可以说是）唯一的CSS文件。所谓“磨刀不误砍柴功”，站在整站的角度上去思考CSS是非常重要的，这可以让你避免迷路，有助于写出精简高效的样式代码。

当我们把1-11项都完成了，就开始着手写页面了，这时候，整个网站的页面基本上都在你脑中了，您在下手的时候就会清除：我现在做的是哪个页面，在整个网站中扮演着什么样的地位，这个页面的CSS对整个网站的CSS有什么影响，这里的样式该怎么处理（分离，合并还是独立）等。

一般而言，就我个人经验，每个页面，即使这个页面看上去很复杂，其代码开销也是非常小的。其新增的代码开销去处有三处：一是分离一些样式归入“网站CSS样式库”中；二是凡事使用的CSS Sprite的样式与其他样式进行合并；三就是一些精细的复杂的样式，这些就是CSS文件的架构的最后一部分“单页面的精细结构了”，何为单页面的精细结构，如下图的样式，就可以说是精细结构，需要独立出来新写样式（可适当分离，注意“适当”一词）：

例如上图鼠标经过后显示，红色虚框样式，剪刀，粗边框投影，最优惠标示，一些按钮等就属于精细结构，我们需要在页面上单独写一个样式。虽然理论上，我们使用分离也是可以实现这个效果的，但是此时html代码的开销实在太大，根本就不适合使用分离，这里就该老老实实的写样式。这里的写法，命名都应该跟随内容而不是属性本身。我们可以在单一类别的页面使用同样的前端的前缀避免样式冲突等~~

四、关于适用性

有些东西虽然看上去好，但是却不适用。通过上述的CSS架构，我可以把网站的样式控制地非常的精简与高效（当然，需要设计师与后台工程师的通力配合），但是，对于别人，套用此架构可能就没有这样的效果，可能反而会更糟。前面也提到了，这种架构是我自己摸索出来的，是根据自己的写法，布局思想，甚至性格等形成的，带有明显的个人印记。

比方说，我是个推崇自适应布局（流体布局）的人，是个十足的自适应控，但是，有很大一部分同行是固定布局（像素级兼容，有计算）。固定布局固然有其优点，但是其CSS代码的消耗量以及页面的扩展性我是很诟病的，显然，这是无法应用到我这里的架构中的。

其次，不少CSS刚入门的页面开发工程师对CSS属性理解不够透彻，常会写一些没有必要的冗余代码。对于他们而言，但CSS文件的架构确实很吃力。

说实话，我对自己的这个CSS架构的适应性都不看好，一是自己在表达方面的火候欠缺，没有很好的展示架构的精髓，二是因为此架构本身需要有很多的控制，这种控制受制于设计师，网站页面架构，CSS工程师自身的功力，一旦样式泛滥，这种架构也就毫无意义，反而弄巧成拙；但是，一旦控制下来，那么网站就CSS性能这块保证领先，而这些需要优秀的有眼界的CSS工程师来掌控，需要优秀的设计师，程序员通力协作。虽然全然套用我展示的这套架构会由于不熟悉或是掌控不够而产生问题，但是，里面一些概念，一些思想应该能有一定的启示作用的，这也是本文的意义所在了。

我只是个初出茅庐的小生，我知道，很多真正功力深厚的前端开发人员有着更好的更广泛适应的前端架构，如果您有幸来到这里，欢迎分享您的一些见解与认识。还有，文中若有您觉得不合理的观点，也非常欢迎通过评论或是邮件[email protected])的方式进行指正。我们需要在不断的交流中提高的。

---