Python技巧你Get了吗？

你可以随时在配置文件中更改这些断点，比如你所需要的小屏幕 sm 可能指的是更小的 320px，那么你想要在小屏幕时候采用 flex 布局，还是照常写 sm:flex，遵循同样的约定，只是这个 sm 已经被你修改成适合于项目需求的值了。

在比如说，Tailwind 里的 spacing 掌管了 margin、padding、width 等各个属性里的代表空间占用的值，默认是采用了 rem 单位，当你在配置里这样覆写后
 

它并不是真的为所有网站提供一些唯一的实用工具 CSS，取而代之的是，它提供了一些公用的命名约定。通过一个配置文件[6]，你可以为你的网站生成一套专属的实用工具 CSS。

ssh 注：这里原作者没有深入介绍，为什么说是一套命名约定呢而不是生成一些定死的 CSS 呢?

举几个例子让大家感受一些，Tailwind 提供了一套强大的构建系统，比如默认情况下它提供了一些响应式的断点值：
 

使用实用工具/原子 CSS，我们可以把结构层和表示层结合起来:当我们需要改变按钮颜色时，我们直接修改 HTML，而不是 CSS!

这种紧密耦合在现代 CSS-in-JS 的 React 代码库中也得到了承认，但似乎 是 CSS 世界里最先对传统的关注点分离有一些异议。

CSS 权重也不是什么问题，因为我们使用的是最简单的类选择器。

我们现在通过 html 标签来添加样式，发现了一些有趣的事儿：

我们增加新功能的时候，样式表的增长减缓了。

我们可以到处移动 html 标签，并且能确保样式也同样生效。

我们可以删除新特性，并且确保样式也同时被删掉了。

可以肯定的缺点是，html 有点臃肿。对于服务器渲染的 web 应用程序来说可能是个缺点，但是类名中的高冗余使得 gzip 可以压缩得很好。同时它可以很好地处理之前重复的 css 规则。

一旦你的实用工具/原子 CSS 准备好了，它将不会有太大的变化或增长。可以更有效地缓存它(你可以将它附加到 vendor.css 中，重新部署的时候它也不会失效)。它还具有相当好的可移植性，可以在任意其他应用程序中使用。

实用工具/原子 CSS 的限制

实用工具/原子 CSS 看起来很有趣，但它们也带来了一些挑战。

人们通常手工编写实用工具/原子 CSS，精心制定命名约定。但是很难保证这个约定易于使用、保持一致性，而且不会随着时间的推移而变得臃肿。

这个 CSS 可以团队协作开发并保持一致性吗?它受巴士因子[5]的影响吗?

巴士系数是软件开发中关于软件专案成员之间讯息与能力集中、未被共享的衡量指标，也有些人称作“货车因子”、“卡车因子”(lottery factor/truck factor)。一个专案或计划至少失去若干关键成员的参与(“被巴士撞了”，指代职业和生活方式变动、婚育、意外伤亡等任意导致缺席的缘由)即导致专案陷入混乱、瘫痪而无法存续时，这些成员的数量即为巴士系数。

你还需要预先开发好一个不错的实用工具/原子样式表，然后才能开始开发新功能。

如果实用工具/原子 CSS 是由别人制作的，你将不得不首先学习类命名约定(即使你知道 CSS 的一切)。这种约定是有主观性的，很可能你不喜欢它。

有时，你需要一些额外的 CSS，而实用工具/原子 CSS 并不提供这些 CSS。没有约定好的方法来提供这些一次性样式。

Tailwind 赶来支援

Tailwind 使用的方法是非常便捷的，并且解决了上述一些问题。

它通过 Utility-First 的理念来解决 CSS 的一些缺点，通过抽象出一组类名 -> 原子功能的集合，来避免你为每个 div 都写一个专有的 class，然后整个网站重复写很多重复的样式。

传统卡片样式写法：

（编辑：淮安站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!