CSS 架构 已翻译 100%

avrilmaomao 投递于 2013/06/07 15:11 (共 36 段, 翻译完成于 12-10)
阅读 3194
收藏 46
8
加载中

对于许多 Web 开发人员来说,精通 CSS 意味着您可以使用一个可视化的模型,并在代码中完美地复制它。你不用表格,而且你为自己使用尽可能少的图片而自豪。如果你真的很优秀,你可以使用最新最好的技术,比如 media queries, transitions 和 transforms。虽然所有这些对于优秀的 CSS 开发人员来说都是正确的,但是 CSS 有一个完全独立的方面,在评估一个人的技能时很少被提及。有趣的是,我们通常不会对其他语言进行这种忽略。Rails 开发人员之所以被认为是优秀的,并不是因为他的代码是按照规范工作。当然,它必须按照规格工作;它的优点基于其他方面:代码是否可读?更改或扩展是否容易?它是否与应用程序的其他部分分离?它能扩展吗?

在评估代码库的其他部分时,这些问题是很自然的,CSS 也不应该有任何不同。今天的 Web 应用程序比以往任何时候都要大,一个考虑不周的 CSS 架构可能会削弱开发。现在是时候像评估应用程序的其他部分一样评估 CSS 了。它不可能是事后的想法,也不可能仅仅被认为是“设计师”的问题。

枫子飘漂
翻译于 2018/10/15 17:23
0

好的 CSS 架构的目标

在 CSS 社区中,普遍共识是很难获得最佳实践。从 Hacker News 的评论和开发者对 CSS Lint 发布反应来看,很明显,许多人甚至在 CSS 作者应该和不应该做的基本事情上存在分歧。

因此,与其为我自己的一套最佳实践提出论据,我认为我们应该从定义我们的目标开始。如果我们能就目标达成一致,希望我们能开始发现糟糕的 CSS,不是因为它打破了我们对好的东西的固有观念,而是因为它实际上阻碍了开发过程。

我认为好的 CSS 架构的目标应该与所有好的软件开发的目标没有太大的区别。我希望我的 CSS 是可预测的、可重用的、可维护的和可扩展的。

枫子飘漂
翻译于 2018/10/15 17:25
0

可被预测

可预测的CSS意思是您的规则能按照您预想的方式运行。当您添加或更新一个规则时,它不应该影响您的站点中您不想影响的部分。在很少改变的小站点上,这并不重要,但在有数十或数百个页面的大站点上,可预测的CSS是必须的。

可复用

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

ZICK_ZEON
ZICK_ZEON
翻译于 2018/10/11 08:32
0

可维护

当您的站点需要添加、更新或重新安排新的组件和特性时,这样做不需要重构现有的CSS。向页面中添加某组件甲不应该破坏某组件乙。

可扩展

随着站点的规模和复杂性的增长,通常需要更多的开发人员来维护。可扩展的CSS意味着它可以由一个人或一个大型工程团队轻松管理。这也意味着您的站点的CSS架构不需要大量的学习曲线就可以轻松学习掌握。不能因为您是目前唯一维护CSS的开发人员,就不考虑以后的变化。

ZICK_ZEON
ZICK_ZEON
翻译于 2018/10/11 08:38
0

常见的糟糕实践

在我们寻找如何实现好的CSS体系结构目标的方法之前,我认为看看妨碍我们实现目标的常见实践是有帮助的。只有通过了解那些不断重复的错误,我们才能开始接受另一种路径。

下面的示例都是我实际编写的代码的概括总结,虽然在技术上是有效的,但它们的结果都导致了灾难和头痛。尽管我的本意是好的,而且希望每次的开发会有所不同,但这些模式持续让我陷入困境。

ZICK_ZEON
ZICK_ZEON
翻译于 2018/10/11 08:44
0

根据组件的父类修改组件

几乎在 Web 上的每个站点中都有一个特定的视觉元素,它与每个事件看起来完全相同,只有一个例外。当遇到这种一次性的情况时,几乎每一个新的 CSS 开发人员(甚至是经验丰富的开发人员)都以同样的方式处理它。您要为这个特定的事件找出某个唯一的父元素(或者创建一个),然后编写一个新规则来处理它。

.widget {
  background: yellow;
  border: 1px solid black;
  color: black;
  width: 50%;
}

#sidebar .widget {
  width: 200px;
}

body.homepage .widget {
  background: white;
}

初看起来这似乎是相当简单的代码,但是让我们基于上面建立的目标来检查它。

枫子飘漂
翻译于 2018/10/15 17:38
0

首先,examle 中的小部件是不可预测的。一个开发过这些小部件的开发人员会希望它看起来是某种样子的,但是当她在侧边栏或主页上使用它时,它看起来就不一样了,尽管标记完全一样。

这也不是可重复使用或可扩展的。当它在主页上的样子被要求在其他页面上时,会发生什么呢?必须添加新的规则。

最后,它不容易维护,因为如果要重新设计小部件,它必须在 CSS 中的几个位置进行更新,并且与上面的示例不同,提交这种特定反模式的规则很少会出现在相邻的位置。

枫子飘漂
翻译于 2018/10/15 17:39
0

想像一下这个代码是其它语言来完成的。你会先定义一个类,然后在另一部分代码中深入到了该类的定义,根据特殊的用例对它进行修改。这直接违反了软件开发的开放/封装原则:

软件实体(类、模块、函数等)应该为扩展开放,对修改封闭。

本文稍后会介绍如何在不依赖父选择器的情况下修改组件。

 

边城
边城
翻译于 2018/10/17 15:50
0

过于复杂的选择器

偶尔会有一篇文章出现在互联网上,展示 CSS 选择器的强大功能,并宣称无需使用任何类或 id 就可以对整个网站进行样式设计。

虽然在技术上是正确的,但是我使用 CSS 开发得越多,就越远离复杂的选择器。选择器越复杂,它与 HTML 的耦合就越紧密。依赖 HTML 标记和组合符可以保持 HTML 的干净,但它会让 CSS 代码变得很混乱和“肮脏”。

#main-nav ul li ul li div { }
#content article h1:first-child { }
#sidebar > div > h3 + p { }
liyue李月
liyue李月
翻译于 2018/10/15 17:48
0

以上所有的例子都符合逻辑。第一个可能是用样式实现下拉菜单,第二个说文章的主标题应该看起来不同于所有 h1 元素,最后一个例子可能是在侧边栏的第一段增加一些额外的间距。

如果这个 HTML 永远不会改变,就可以对它的优点进行讨论,但是假设这个 HTML 永远不会改变的可能性有多大?过于复杂的选择器可能会令人印象深刻,它们可以消除 HTML 中的所有表象的挂钩,但它们很少帮助我们实现好的 CSS 架构的目标。

上面的这些示例根本不能重用。由于选择器指向标记中的一个非常特殊的位置,那么另一个具有不同 HTML 结构的组件如何重用这些样式呢?以第一个选择器(下拉列表)为例,如果在另一个页面上需要一个类似的下拉列表,而它不在 #main-navelement 中呢?你必须重新打造整个样式。

liyue李月
liyue李月
翻译于 2018/10/15 17:53
0
本文中的所有译文仅用于学习和交流目的,转载请务必注明文章译者、出处、和本文链接。
我们的翻译工作遵照 CC 协议,如果我们的工作有侵犯到您的权益,请及时联系我们。
加载中

评论(7)

小小黄鸡
小小黄鸡
+1s
韦小仇
韦小仇
naive,to young to simple
丁富贵
css现在也谈架构了吗😥
白two白
白two白
写出CSS易,写好CSS难
一只囧蟹
一只囧蟹
老板给你多少钱?
宇润
宇润
这标题有点暴力
返回顶部
顶部