- 原文地址:On the Growing Popularity of Atomic CSS
- 原文做者:OLLIE WILLIAMS
- 译文出自:掘金翻译计划
- 本文永久连接:github.com/xitu/gold-m…
- 译者:Cherry
- 校对者:Tina92、ClarenceC
即便你自认为是 CSS 方面的专家,也极可能在某一大型项目中,处理一个错综复杂而且愈来愈庞大的样式表,它们中一些样式表看起来就像一张相互继承而且混乱缠绕的网。css
级联的做用很是强大。微小的改变可能会引发很大的改变,这就致使了很难知道下一秒会发生什么。重构、更改和移除 CSS 都是高危动做,由于很难知道这个 CSS 在哪里被引用。前端
你何时能够作到改变 CSS 不引发没必要要的改动? 答案是不管在何种状况下,你都不多有这种想法。android
在我有限的经验中,其中的一种状况是,在大型团队的大型代码库中,给人的感受是 CSS 太大了以致于团队的成员开始对 CSS 很敏感而且对 CSS 感到惧怕,可是实际上只是让你增长 CSS。ios
由此产生一个工具,它能作的事情远远少于 CSS,可是在某种程度上(在你学会以后),没有人在对其感到惧怕,我认为这很是棒。git
我不在须要去考虑如何组织个人 CSS。我也不须要考虑如何给个人组件起名,也不须要考虑将一个组件和另外一个组件彻底分离,应该将其放在哪里,最重要的,当有新的需求是怎么进行重构。github
原子 CSS 提供了一套直接、明显而且简单的方法论。类是不可变的,你不能够改变类名。这使得s使用 CSS 是可预见的和可靠的,由于类老是作彻底相同的事情。在 HTML 文件中添加或者移除一个有做用域范围的公用类是明确的,它让你确信你不会破坏其余任何东西。这能够减小认知负荷和精神负担。后端
给组件命名是出了的困难。想出一个既有意义又足够通用的类名费时又费力。缓存
计算机科学中只有两个难题:缓存失效和命名问题。bash
– Phil Karltonapp
提出适当的抽象是困难的。相比之下,命名工具类就简单直接一些。
/* 工具类命名 */
.relative {
position: relative;
}
.mt10 {
margin-top: 10px;
}
.pb10 {
padding-bottom: 10px;
}
复制代码
原子的类从名字就能够知道它们的功能。意图和效果显而易见。而包含无数类名的 HTML 会显得很乱,HTML 比一个庞大而且错综复杂的样式要容易一些。
在一个先后端混合的团队中,可能参与开发的后台人员对 CSS 知识有限,不多有人将样式表搞乱。
工具类 很是适合处理小的样式差别。虽然设计系统和模式库如今可能风靡一时,可是你要意识到将会有不断的新需求和变化。全部组件的可重用性每每不是体如今设计模拟。虽然实现和设计稿一致是最好的,可是一个大型网站繁多的上下环境必定会有不少的不可避免的不一样。
Medium 的开发团队已经不使用 BEM 了,在 他们的博文中 有提到。
若是咱们但愿组件经过简单的方式和另外一个组件只有细微的差异,该怎么去作呢?若是你使用的 BEM 的命名方式,修饰符类极可能会不起做用。无数的修饰符每每只有一个效果。咱们以边距(margin
)为例。不一样组件的边框大部分都不相同,让全部组件的边框保持一致也不太可能。这个距离不只取决于组件,还取决于组件在页面中的位置和它相对于其余元素的相对位置。大部分的设计都包含类似可是不彻底相同的 UI 元素,使用传统的 CSS 很难处理。
这是质疑原子 CSS 的人常常会问到的问题。长期以来你们都认为行内样式不利于实践,自 Web 时代初期就不多有人使用了。**那些批评者将原子 CSS 与行内样式等同也是有道理的,由于行内元素和原子 CSS 有相同的弊端。**举个例子,若是咱们想要将全部的 .block
类中的 color
改变为 navy
会怎样?若是这样作:
.black {
color: navy;
}
复制代码
很明显,这是不对的。
如今的编辑器很复杂。使用查找和替换将全部的 .black
类换成一个新的 .navy
类十分的简单,可是倒是很危险的。问题是,你只是想将 某些 .block
类变为 .naby
类。
在传统的 CSS 方法中,调整组件的样式和在一个 CSS 文件中更新一个类的一个值同样简单。使用原子 CSS,这就变成了一项单调乏味的任务,它经过搜索每一块 HTML 来更新所述组件的每个实例。然而全部的高级编辑器都是这样。即便你将标记分离为可重用的模板,这仍然是一个主要缺点。也许这种手动操做对于这种简单的方法是值得的。用不一样的类更新 HTML 文件可能很乏味,但并不困难。(虽然有一些时候我在手动更新时遗漏了相关组件的某些实例,暂时引入了风格不一致)。若是改变了设计,你可能须要从 HTML 中手动编辑类。
虽然原子 CSS 和内联样式同样有很大的缺陷,可是这不是一种退后。工具类以各类方式优于内联样式。
原子类能够建立抽象类,内联样式不行。
<p style="font-family: helvetica; color: rgb(20, 20, 20)">
Inline styles suck.
</p>
<p class="helvetica rgb202020">
Badly written CSS isn't very different. </p> <p class="sans-serif color-dark"> Utility classes allow for abstraction. </p> 复制代码
当改变设计的时候,上面例子的前两个须要手动的修改和替换。第三个例子能够只调整一处样式表。
CSS 社区已经建立了不少用于行内样式的无用的工具例如:Sass, Less, PostCSS, Autoprefixer 等。
与其写出冗余的行内样式,倒不如像原子 CSS 同样写出简洁的声明缩写。相比之下少打了一些字符:mt0
和 margin-top: 0
,flex
和 display: flex
,等等。
这是一个有争议的话题。若是一个类或者行内样式仅仅只作一件事情,那么你是否但愿它只作一件事情,不少人提倡使用 !importent
来保证不被其余的除了 !important
的样式重写,这也就意味着这个样式确定会被应用。可是,一个类自己是足够具体的,能够覆盖其余的基本类。和行内样式相比,原子类特异性较低是一件好事。它容许更多的通用性。均可以使用 JavaScript 来改变样式。若是是行内样式的话就比较困难。
行内样式不支持媒体查询、伪选择器、@supports
和 CSS 动画。也许你有一个单独的悬停效果你想要应用在不一样的元素而不是一个组件。
.circle {
border-radius: 50%;
}
.hover-radius0:hover {
border-radius: 0;
}
复制代码
简单的可重用媒体查询规则也能够转换成实用的工具类,其经常使用的类名前缀表示小型、中型和大型的屏幕尺寸。下面有一个 flexbox 类的实例,只能对中型和大型屏幕尺寸有效:
@media (min-width: 600px) {
.md-flex {
display: flex;
}
}
复制代码
这在内联样式中是不可能的。
你是否是想要一个可重用的有伪内容的图标或标签?
.with-icon::after {
content: 'some icon goes here!';
}
复制代码
行内样式能够作任何事情。这过于自由以致于很容易致使显示效果混乱和不一致。经过每个预约类,原子 CSS 能够保证必定程度的风格一致。而不是杂乱的颜色值和不肯定的颜色值,工具类提供了一个预约义设置选项。开发者从有限的设置中选择单一功能的工具类,这种约束既能够消除日益增长的样式问题,保持视觉的一致性。
咱们来看一个 box-shadow
的例子。一个行内样式能够随意使用偏移量、范围、颜色、透明度和模糊半径。
<div style="box-shadow: 2px 2px 2px rgba(10, 10, 250, .4)">stuff</div>
复制代码
使用原子方法,CSS 做者能够定义首选样式,而后简单应用,不可能出现风格不一致。
<div class="box-shadow">stuff</div>
复制代码
毫无疑问,像 Tachyons 这样的原子类框架愈来愈受欢迎。然而,CSS 方法并非互斥的。不少状况下,工具类并非最好的选择:
原子类能够和其余样式方法共存。咱们应该将设置一些基础类和稳健的全局样式。若是你继续复制工具类的类似字符串,这些样式极可能被抽象为一个类。你能够在组件类中将其合并,可是你只能在知道它们不会被重用时才能够这样。
以组件为先的方法去写 CSS 意味着你建立一个组件事物即便他们不会再被重用。这种过早的抽象就是使样式表变得冗余和复杂的缘由。
单位越小,它的可重用性就越强。
看一下 Bootstrap 的最新版本,如今提供了一整套的工具类,仍然包括其传统的组件。将来,愈来愈多的流行框架采用这种混合方法。
掘金翻译计划 是一个翻译优质互联网技术文章的社区,文章来源为 掘金 上的英文分享文章。内容覆盖 Android、iOS、前端、后端、区块链、产品、设计、人工智能等领域,想要查看更多优质译文请持续关注 掘金翻译计划、官方微博、知乎专栏。