在范围之间设计

CSS 的编写速度很慢，逐行进行，并且随着时间的推移，我们限制了设计系统中可能的范围。 以此为例

body {
  font-family: 'Proxima-Nova', sans-serif;
  color: #333;
}

仅需几行 CSS，我们就为整个代码库设置了默认值。 大多数元素（如段落、列表和普通的 div）将继承这些指令。 但是，我们在编写 CSS 时很少想到的是，从现在开始，如果我们想要另一种字体或颜色，就必须不断覆盖这些规则。 正是这些覆盖在维护和可扩展性方面造成了很多问题。 正是这些问题让我们心碎、浪费时间和金钱。

在上面的示例中，这可能不是问题，但我认为总的来说，我们没有认识到级联的真正优势和危险，以及它对我们设计系统意味着什么； 大多数人认为级联是为了让我们能够覆盖之前的指令，但我对此表示警告。 每次覆盖继承的样式时，我们都会使代码库变得更加复杂。 你花了多少时间检查元素，并滚动浏览每个规则，以了解元素为什么看起来是这样，或者长长的继承链是如何完全搞乱你的样式的？

我认为造成这种情况的原因是我们经常没有为元素设置正确的默认样式。 当我们想要更改元素的样式时，与其花时间质疑和重构这些默认样式，我们只是简单地覆盖它们 - 使情况变得更糟。

因此，我一直思考我们应该如何构建一个代码库，激励我们所有人编写更好的代码，以及如何设计我们的 CSS，使其不会鼓励其他人创建骇客类来覆盖事物。

我最喜欢的关于此主题的帖子之一是本月早些时候由 Brandon Smith 撰写的，他在其中描述了 CSS 如何变得如此复杂（重点是我的）

…永远不要比你需要的更明确。 网页默认情况下是响应式的。 编写良好的 CSS 意味着利用这一事实，而不是覆盖它。 如果可能，使用百分比或视窗单位，而不是媒体查询。 尽可能使用 min-width 而不是 width。 考虑规则，考虑你真正想说的话，而不是仅仅添加属性直到看起来不错。 尝试了解浏览器如何解析布局和大小调整，并谨慎地进行更改和添加。 **与 CSS 合作，而不是反对它。**

Brandon 的建议之一是完全避免使用 width 属性，而是坚持使用 max-width 或 min-width。 在整篇文章中，他提醒我们，无论我们构建什么，都应该位于两个极端之间的范围内。 以下是一个具有不良默认样式的类的示例

.button {
  width: 300px;
}

这个按钮可能总是、在任何地方都保持这种宽度吗？ 在移动设备上？ 在每个媒体查询中？ 在每种状态下？ 我高度怀疑，事实上，我相信这个类正是那种渴望被另一个类覆盖的类

.button-thats-just-a-bit-bigger {
  width: 310px;
}

这是一个愚蠢的例子，但我曾在许多团队中见过这样的代码 - 这不是因为这个人编写了糟糕的代码，而是因为**系统鼓励他们编写糟糕的代码**。 每个人都有发布产品的截止日期，而且大多数人没有时间或意愿深入研究大型代码库并重构我提到的那些核心默认样式。 继续编写 CSS 更容易，因为它可以立即解决所有问题。

沿这条线，Jeremy Keith 前几天写了关于这个问题的文章

与需要了解循环、变量和其他概念的编程语言不同，CSS 非常容易上手。 也许正是因为如此，它才获得了“简单”的名声。 它在“不复杂”的意义上是简单的，但这并不意味着它很容易。 将“简单”误认为“容易”只会导致痛苦。

我认为，这就是一些第一次接触 CSS 的程序员所遇到的情况。 他们听说它很简单，所以他们认为它很容易。 但是当他们尝试使用它时，它却无法正常工作。 问题一定出在语言上，因为他们知道自己很聪明，而且这应该很容易。 所以他们责怪语言。 他们说它坏了。 因此，他们试图通过使它符合更具程序性的思维方式来“修复”它。

我不禁认为，如果他们接受 CSS 并不容易，他们会不那么沮丧。 简单，是的，但不简单。

CSS 很简单的理由是级联，但它并不像我们最初想象的那样容易，也是因为级联。 正是那些向下过滤到所有内容的默认样式，是这种语言最大的优势和最大的弱点。 我认为基于 JavaScript 的解决方案并不能像每个人争论的那样有效地解决这个问题。

那么解决方案是什么？ 我认为，以范围设计，考虑不同状态，并将每一行 CSS 都视为建议，而不是绝对的、不可打破的规则，是向前迈出的第一步。 接下来该怎么做？ 容器查询。 容器查询。 容器查询。