英文原文：
CSS Architecture
对于许多 Web 开发人员来说，精通 CSS 意味着您可以使用一个可视化的模型，并在代码中完美地复制它。你不用表格，而且你为自己使用尽可能少的图片而自豪。如果你真的很优秀，你可以使用最新最好的技术，比如 media queries, transitions 和 transforms。虽然所有这些对于优秀的 CSS 开发人员来说都是正确的，但是 CSS 有一个完全独立的方面，在评估一个人的技能时很少被提及。有趣的是，我们通常不会对其他语言进行这种忽略。Rails 开发人员之所以被认为是优秀的，并不是因为他的代码是按照规范工作。当然，它必须按照规格工作；它的优点基于其他方面：代码是否可读？更改或扩展是否容易？它是否与应用程序的其他部分分离？它能扩展吗？
在评估代码库的其他部分时，这些问题是很自然的，CSS 也不应该有任何不同。今天的 Web 应用程序比以往任何时候都要大，一个考虑不周的 CSS 架构可能会削弱开发。现在是时候像评估应用程序的其他部分一样评估 CSS 了。它不可能是事后的想法，也不可能仅仅被认为是“设计师”的问题。
好的 CSS 架构的目标
在 CSS 社区中，普遍共识是很难获得最佳实践。从 Hacker News 的评论和开发者对 CSS Lint 发布的反应来看，很明显，许多人甚至在 CSS 作者应该和不应该做的基本事情上存在分歧。
因此，与其为我自己的一套最佳实践提出论据，我认为我们应该从定义我们的目标开始。如果我们能就目标达成一致，希望我们能开始发现糟糕的 CSS，不是因为它打破了我们对好的东西的固有观念，而是因为它实际上阻碍了开发过程。
我认为好的 CSS 架构的目标应该与所有好的软件开发的目标没有太大的区别。我希望我的 CSS 是可预测的、可重用的、可维护的和可扩展的。
可被预测
可预测的CSS意思是您的规则能按照您预想的方式运行。当您添加或更新一个规则时，它不应该影响您的站点中您不想影响的部分。在很少改变的小站点上，这并不重要，但在有数十或数百个页面的大站点上，可预测的CSS是必须的。
可复用
CSS规则应该足够抽象和可被解耦的，您不必对已经解决的模式和问题进行重新编码，可以依靠现有的部分快速构建新的组件。
其它翻译版本 (1)
加载中
可维护
当您的站点需要添加、更新或重新安排新的组件和特性时，这样做不需要重构现有的CSS。向页面中添加某组件甲不应该破坏某组件乙。
可扩展
随着站点的规模和复杂性的增长，通常需要更多的开发人员来维护。可扩展的CSS意味着它可以由一个人或一个大型工程团队轻松管理。这也意味着您的站点的CSS架构不需要大量的学习曲线就可以轻松学习掌握。不能因为您是目前唯一维护CSS的开发人员，就不考虑以后的变化。
其它翻译版本 (1)
加载中
常见的糟糕实践
在我们寻找如何实现好的CSS体系结构目标的方法之前，我认为看看妨碍我们实现目标的常见实践是有帮助的。只有通过了解那些不断重复的错误，我们才能开始接受另一种路径。
下面的示例都是我实际编写的代码的概括总结，虽然在技术上是有效的，但它们的结果都导致了灾难和头痛。尽管我的本意是好的，而且希望每次的开发会有所不同，但这些模式持续让我陷入困境。
其它翻译版本 (1)
加载中
根据组件的父类修改组件
几乎在 Web 上的每个站点中都有一个特定的视觉元素，它与每个事件看起来完全相同，只有一个例外。当遇到这种一次性的情况时，几乎每一个新的 CSS 开发人员（甚至是经验丰富的开发人员）都以同样的方式处理它。您要为这个特定的事件找出某个唯一的父元素（或者创建一个），然后编写一个新规则来处理它。
.widget {
background: yellow;
border: 1px solid black;
color: black;
width: 50%;
}
#sidebar .widget {
width: 200px;
}
body.homepage .widget {
background: white;
}初看起来这似乎是相当简单的代码，但是让我们基于上面建立的目标来检查它。
首先，examle 中的小部件是不可预测的。一个开发过这些小部件的开发人员会希望它看起来是某种样子的，但是当她在侧边栏或主页上使用它时，它看起来就不一样了，尽管标记完全一样。
这也不是可重复使用或可扩展的。当它在主页上的样子被要求在其他页面上时，会发生什么呢？必须添加新的规则。
最后，它不容易维护，因为如果要重新设计小部件，它必须在 CSS 中的几个位置进行更新，并且与上面的示例不同，提交这种特定反模式的规则很少会出现在相邻的位置。
想像一下这个代码是其它语言来完成的。你会先定义一个类，然后在另一部分代码中深入到了该类的定义，根据特殊的用例对它进行修改。这直接违反了软件开发的开放/封装原则：
软件实体（类、模块、函数等）应该为扩展开放，对修改封闭。
本文稍后会介绍如何在不依赖父选择器的情况下修改组件。
过于复杂的选择器
偶尔会有一篇文章出现在互联网上，展示 CSS 选择器的强大功能，并宣称无需使用任何类或 id 就可以对整个网站进行样式设计。
虽然在技术上是正确的，但是我使用 CSS 开发得越多，就越远离复杂的选择器。选择器越复杂，它与 HTML 的耦合就越紧密。依赖 HTML 标记和组合符可以保持 HTML 的干净，但它会让 CSS 代码变得很混乱和“肮脏”。
#main-nav ul li ul li div { }
#content article h1:first-child { }
#sidebar > div > h3 + p { }
以上所有的例子都符合逻辑。第一个可能是用样式实现下拉菜单，第二个说文章的主标题应该看起来不同于所有 h1 元素，最后一个例子可能是在侧边栏的第一段增加一些额外的间距。
如果这个 HTML 永远不会改变，就可以对它的优点进行讨论，但是假设这个 HTML 永远不会改变的可能性有多大？过于复杂的选择器可能会令人印象深刻，它们可以消除 HTML 中的所有表象的挂钩，但它们很少帮助我们实现好的 CSS 架构的目标。
上面的这些示例根本不能重用。由于选择器指向标记中的一个非常特殊的位置，那么另一个具有不同 HTML 结构的组件如何重用这些样式呢？以第一个选择器（下拉列表）为例，如果在另一个页面上需要一个类似的下拉列表，而它不在 #main-navelement 中呢？你必须重新打造整个样式。
本文中的所有译文仅用于学习和交流目的，转载请务必注明文章译者、出处、和本文链接。
2KB翻译工作遵照
CC 协议，如果我们的工作有侵犯到您的权益，请及时联系我们。
2KB项目（www.2kb.com，源码交易平台）,提供担保交易、源码交易、虚拟商品、在家创业、在线创业、任务交易、网站设计、软件设计、网络兼职、站长交易、域名交易、链接买卖、网站交易、广告买卖、站长培训、建站美工等服务
