CSS框架开发指南.docx

.widget{}

.widget.title{}

.widget.contents{}

.widget.action{}

　　像.title、.contents、.action这些子元素类选择器可以被安全地进行样式命名，无需担心这些样式会蔓延到拥有相同类名的其他元素中。

这是千真万确的。

但它并没有阻止相同样式类名称会蔓延到这个组件上。

　　在一些大型项目上，像.title这样的名称很有可能会被用在另外一个页面或者本身。

如果这样的情况发生，那么整个标题部分明显会和预期的不一样。

　　过于通用的类选择器名称会导致许多不可预测的CSS样式发生。

　　一个规则做太多事

　　有时，你要在网站的左上角区域做一个20pixels的可视化组件。

CSSCode

.widget{

position:

absolute;

top:

20px;

left:

20px;

background-color:

red;

font-size:

1.5em;

text-transform:

uppercase;

}

　　下面，你需要在网站的其他区域使用该组件，那么上面的这个代码明显是错误的，不可重用的。

　　问题的关键是你让.widget这个选择器做的事情太多，不仅对该组件的位置进行了规定，还对它的外观和感觉方面进行了样式。

外观和感觉可以通用，而位置是不可以的。

有时候，把它们整合起来使用反而会大打折扣。

　　虽然这些看起来并无害处，对一些缺乏经验的CSS程序员来说，复制和粘贴已经成为一种习惯。

如果一个新团队需要一个特定组件，比如.infobox，他们会尝试使用这个类选择器。

但如果该信息框没有按照期望的那样，在每个需要的地方正确显示出来。

这时，你认为他们会怎么做？

以我的经验来看，他们会打破可重用这一规则，相反，他们会简单地把这些代码复制粘贴到每个需要的地方。

做些不必要的重复工作。

　　3.原因

　　上面列举的这些常规错误实践都有一个相似性，CSS样式承担过多。

　　对这样的说法你会感到奇怪，毕竟，它是一个样式表，难道不应该承担大多数（如果不是全部）的样式吗？

那不正是我们想要的吗？

　　的确。

但是通常来讲，事情并没有那么简单。

内容与表现（presentation）相分离是件好事，但CSS从HTML中独立出来并不意味着内容也需要从表现中分离。

换句话说，如果CSS请求深入分析HTML架构，那么从HTML中分拆所有的显示代码并不一定会实现所有的目标。

　　此外，HTML很少会只包含内容，也表示整体框架。

通常，架构是会包含container元素，允许CSS隔离一些固定元素。

即使没有表象类（presentationalclasses），也能混合HTML清晰地把内容展示出来。

　　我相信，鉴于当前的HTML和CSS状态，把HTML和CSS明智地结合起来，当做表现层是非常需要的。

而通过模板和局部模板（partials）也可以把内容层进行分离。

　　4.解决方案。

　　如果把HTML和CSS结合起来，作为一个Web应用程序的表现层，那么它们需要采取一些方式更好地促进优秀CSS架构的形成。

　　最好的方法是CSS中尽可能少的包含HTML架构。

CSS则是应该定义元素的视觉效果，无论该视觉元素在哪里。

如果有一些特定的组件需要在不同的场合显示不同的效果，那么应该赋予不同的名称。

例如，CSS通过.button类选择器定义了一个按钮组件。

如果HTML想要一个特定的元素看起来像按钮，那么就可以使用.button。

如果这里有特殊要求，这里的按钮与其他的有所不同（有可能更大和宽些），那么CSS需要定义一个新的类，HTML可以使用新的类来赋予该元素新的视觉效果。

　　CSS赋予元素的外在特征，HTML在页面上进行调用。

更少的CSS能被更多的HTML架构调用是最好的。

　　准确地在HTML中声明元素不仅可以清晰表达设计意图，其他开发者也可以清晰地查看标记并且知道元素将呈现的样子。

如果没有这种实践，它很难区分一个元素的外观设置是有意或无意的，这样很容易导致团队混乱。

　　在标记中填入大量的类（classes）是种常见缺陷，这样做往往需要花费额外的精力。

一个CSS样式可以给一个特定组件引用上千次。

那么，为了在标记里面进行显示声明，就真的值得去重复编写这样的类吗？

　　虽然这种担心是有效的，但它可能会产生误导。

言下之意就是无论你在CSS中使用一个父选择器还是亲手编写上千个Class，这里都会有些额外的选择。

在Rails或者其他框架里查看同级别抽象很大程度上可以在HTML中保持很好的视觉外观，并且无需在类中一遍又一遍地编写相同的类。

　　5.最佳实践。

　　针对上面的种种错误，我进行了很好地总结，并且根据自身经验提出了一些建议，希望它们能帮助您更好地实现良好的CSS架构目标。

　　专注

　　确保选择器对一些元素不进行无关样式的最好方法是不给它们机会。

例如像#main-navulliullidiv这样的选择器可能很容易地应用于不想要的元素上。

另一方面，像.subnav这样的选择器就不会给它们任何机会。

把类选择器直接应用于你想要的元素上是最好的方式，并且可以保持元素的可预测性。

CSSCode

/*Grenade*/

#main-navulliul{}

/*SniperRifle*/

.subnav{}

　　模块化

　　一个组织结构良好的组件层可以帮助解决HTML架构与CSS那种松散的耦合性。

此外，CSS组件本身应该是模块化的。

组件应该知道如何进行样式和更好地工作，但是关于布局、定位以及它们与周围元素的关系不应该做太多的假设。

　　一般而言，CSS要定义的应该是组件的外观，而不是布局或者位置。

同样在使用background、color和font这些属性时也要遵循原则使用。

　　布局和位置应当由一个单独的布局类或者单独的容器元素构成（请记住，有效地把内容与展示进行分离其实就是把内容与容器进行分离）。

　　给类进行命名空间

　　我们已经检查出为什么父选择器不能在封闭和防止交叉样式污染上面发挥100%的功效。

而一个更好的解决方案就是在类上应用命名空间。

如果一个元素是可视化组件的一员，那么该元素的每个子元素都应该使用基于命名空间的组件。

CSSCode

/*Highriskof

auto;height:

auto;float:

none;"id="14_nwp">

none;"mpid="14"target="_blank"href="id="14_nwl">

#0000ff;font-size:

14px;width:

auto;height:

auto;float:

none;">stylecross-contamination*/

.widget{}

.widget.title{}

/*Lowriskofstylecross-contamination*/

.widget{}

.widget-title{}

　　给类进行命名空间可以保持组件独立性和模块化。

它可以把现有类冲突降至最小并且减少子元素的一些特殊要求。

　　创建修饰符类来扩展组件

　　当一个现有组件需要在一个特定的语境中有所不同时，可以创建一个修饰符类（modifierclass）来扩展它。

CSSCode

/*Bad*/

.widget{}

#sidebar.widget{}

/*Good*/

.widget{}

.widget-sidebar{}

　　正如我们看到的，基于父元素的缺点对组件进行修改，需要重申：

一个修饰符类可以在任何地方使用。

基于位置的覆盖只能被用在一个特定的位置，修饰符类也可以根据需要被多次使用。

显然，修饰符类是符合HTML开发者需求的。

　　把CSS组织成逻辑结构

　　JonathanSnook在其非常优秀的《SMACSS》书中提到，CSS可以被分成四个不同的类：

基础（base）、布局（layout）、模块（modules）和状态（state）。

基础包括了复位原则和元素缺省值；布局是对站点范围内的元素进行定位以及像网格系统那样作为一种通用布局助手；模块即是可重用的视觉元素；状态即指样式，可以通过JavaScript进行开启或关闭。

　　组件是一个独立的视觉元素。

模板在另一方面则是构建块。

模板很少独自站在自己的角度去描述视觉和感觉，相反，它们是单一的、可重用的模式，可以放在一起形成组件。

　　为了提供更详细的例子，一个组件可能就是一个模式对话框。

该模式可能在头部包含渐变的网站签名、或者在周围会有阴影、在右上角会有关闭按钮、位置固定在垂直与水平线中间。

这四个模式可能被网站重复多次使用，所以在每次使用的时候，你都很少会想到重新编码与设计。

这些所有的模板即形成了一个模块组件。

　　因样式和风格使用类

　　有过大型网站建设的人可能有个这样的经验，一个拥有类的HTML元素可能完全不知道其用途。

你想删除它，但是又犹豫不决，因为它的作用你可能还未意识到。

一旦这样的事情一遍又一遍发生的时候，随着时间的推移，项目中将会有越来越多这样的类，只因为团队成员都不敢删除。

　　在Web前端开发中，类承担了太多的责任，因此才会产生这样的问题。

样式化HTML元素、扮演着JavaScripthook角色、功能检测、自动化测试等。

当这么多应用程序在使用类时，让你从HTML中删除它们将会变的非常艰难。

　　然而，使用一些成熟的约定（惯例）即可完全避免这种问题。

当在HTML中看到一个类时，你应该立即明白它的目的。

我建议在前面使用前缀，例如用于JavaScript的在前面加.js，表示Modernizrclasses可以在前面加.supports，没有加前缀的即用于表示样式。

　　这样来发现未使用的类和从HTML中移除它们将会变得非常简单。

你甚至可以自动完成这一个过程，在JavaScript中通过交叉引用HTML中的document.styleSheets对象。

如果在document.styleSheets中没有发现该类，即可安全移除。

　　一般来说，最佳做法是把内容与演示相分离，另外把功能分离开来也同样重要。

使用样式类像JavaScripthook在某种程度上可以加深CSS与JavaScript之间的耦合，但在不打破功能性的前提下很难或者根本不可能更改外观。

　　有逻辑的命名类

　　大多数写CSS的人喜欢使用连字符来分隔命名词，但连字符并不足以区分不同类型之间的类。

　　NicolasGallagher最近针对遇到的问题写了一个解决方案，并且取得了巨大的成功（略有改动），为了说明命名约定，可以考虑以下格式：

CSSCode

/*Acomponent*/

.button-group{}

/*Acomponentmodifier（modifying.button）*/

.button-primary{}

/*Acomponentsub-object（liveswithin.button）*/

.button-icon{}

/*Isthisacomponentclassora

auto;height:

auto;float:

none;"id="8_nwp">

none;"mpid="8"target="_blank"href="id="8_nwl">

#0000ff;font-size:

14px;width:

auto;height:

auto;float:

none;">layoutclass?

*/

.header{}

　　从上述类中可以发现其很难正确区分类型规则。

这不但会困惑，而且连自动测试CSS和HTML也变的很难。

一个结构化的命名约定应该是初看就能够知道其类名与其他类之间的关系，并且知道它出现在HTML中的位置——使命名更加简单和容易测试。

CSSCode

/*TemplatesRules（usingSassplaceholders）*/

%template-name

%template-name--modifier-name

%template-name__sub-object

%template-name__sub-object--modifier-name

/*ComponentRules*/

.component-name

.component-name--modifier-name

.component-name__sub-object

.component-name__sub-object--modifier-name

/*LayoutRules*/

.l-layout-method

.grid

/*StateRules*/

.is-state-type

/*Non-

auto;height:

auto;float:

none;"id="7_nwp">

none;"mpid="7"target="_blank"href="id="7_nwl">

#0000ff;font-size:

14px;width:

auto;height:

auto;float:

none;">styledJavaScriptHooks*/

.js-action-name

　　重做第一个例子：

CSSCode

/*Acomponent*/

.button-group{}

/*Acomponentmodifier（modifying.button）*/

.button--primary{}

/*Acomponentsub-object（liveswithin.button）*/

.button__icon{}

/*A

auto;height:

auto;float:

none;"id="6_nwp">

none;"mpid="6"target="_blank