table of contents

• 1、 tailwindcss 简介
• 2、 tailwindcss 中的基础尺寸单位
• 3、 更详细的尺寸单位表示方式
• 4、更规范的尺寸单位
• 5、总结

1、 tailwindcss 简介

tailwindcss 是目前比较主流的 CSS 解决方案。

尽管社区里对 tailwindcss 的评价褒贬不一，但是我个人对其的使用感受还是非常不错的。虽然每一种解决方案都存在一些痛点，例如有的人会觉得 tailwindcss 的样式类名冗长，这是客观存在的。不过相比较而言，其他解决方案的痛点我更加不能接受。

因此目前我一直在深度使用它，新的项目开发都会使用 tailwindcss

在本专栏中，我也会大量基于 tailwindcss 来实现案例。

如何在项目中安装 tailwindcss，大家可以在官网中找到步骤

tailwindcss 的理念是，通过预定义的类名，来实现样式的快速开发。这种方式俗称为原子化样式。例如，我们定义一个 flex 的类名，如下所示

1
.flex {
2
  display: flex;
3
}

1
<div class="flex">
2
  ...
3
</div>

这样做的好处就是，我们不需要再手动去写 display: flex; 这样的样式了。只需要通过一个简短的类名，就可以实现一个 flex 布局。坏处就是，当项目中存在大量的原子化样式时， class 会显得非常冗长。

1
<div class="flex flex-col flex-1 bg-red-500">
2
  ...
3
</div>

不过总体来说，tailwindcss 的类名设计得还是非常合理，使用起来也比较方便，也不需要切换文件去写样式，对开发效率的提升是非常明显的。当然，如果使用不合理，也会导致项目的维护难度变得更高。

要熟练使用 tailwindcss，我们还需要对 tailwindcss 的尺寸单位有一定的了解。

2、 tailwindcss 中的基础尺寸单位

tailwindcss 中，以 rem 作为尺寸单位的基准。默认情况下，根节点的字体大小为 16px，即 1rem = 16px。

1
:root {
2
  font-size: 16px; /* 1rem = 16px */
3
}

在此基础之上，tw 将 1rem 一分为四，重新设计了自己的尺寸单位，以 width 为例，有如下尺寸设计

10
/* w 表示 width 的缩写 */
20
.w-1 {
30
  width: 0.25rem; /* 4px */
40
}
50
.w-2 {
60
  width: 0.5rem; /* 8px */
70
}
80
.w-3 {
90
  width: 0.75rem; /* 12px */
10
}
11
.w-4 {
12
  width: 1rem; /* 16px */
13
}

如下所示，我们可以直接使用 tw 的类名来设置一个元素的样式。12 对应 12 个 w-1 的宽度。即 12 * 4px = 48px

1
<div class="w-12 h-12 bg-violet-500">
2
</div>

3、 更详细的尺寸单位表示方式

tailwindcss 的设计初衷，是依托于一套设计规范，因此，在最开始的版本中，对于尺寸单位的支持并不是那么灵活。但是随着使用的人越来越多，很多使用者很难在这套设计规范中，找到自己想要的尺寸，于是，在后续的版本中，tailwindcss 也提供了更加灵活的尺寸单位表示方式。

例如，我们想要表达一个 73 像素的宽度，在 tw 中，我们可以使用 w-[73px] 来表示。

tw 会自动根据你编写的类名生成对应的 css 样式

1
.w-[73px] {
2
  width: 73px;
3
}

1
<div class="w-[73px] h-[73px] bg-violet-500">
2
</div>

当然，这种使用方式并不优雅，仅仅只是在没有设计规范时的兜底方案。如果我们想要更优雅的使用 tw，则应该先理解 tw 的尺寸设计规范，然后在规范的范围内，使用 tw 的类名来表示。

4、更规范的尺寸单位

以字体大小为例，tw 提供了规范的缩写来表示常用的字体大小。例如 text-xs

1
.text-xs {
2
  font-size: var(--text-xs); /* 0.75rem (12px) */ 
3
  line-height: var(--text-xs--line-height); /* calc(1 / 0.75) */
4
}

其他常用尺寸已经表现如下

5、总结

本篇文章仅仅只是针对 tw 的尺寸单位进行简单介绍，是为了我们在后续的案例学习中不至于对其感受到陌生。

这里需要注意的是：如果在团队开发中，如果我们想要用最合理的方式使用 tw，则需要首先和设计师沟通，基于 tw 的设计规范达成一致，然后基于 tw 的设计规范进行扩展。否则你的 tw 使用体验会降低很多