在密切关注 WordPress 通过 Gutenberg 项目进行变革的开发者圈子里，一个经常被重复的问题是：我们何时能获得更多的响应式控制？具体来说，这个问题通常围绕着根据桌面、平板或移动视图来更改区块的某些设计元素的能力。

这是一个重要的问题。设计师们几十年来一直在进行类似的讨论。如果你从业时间足够长，你可能用表格构建过一些完美对齐的网站，经历过令人沮丧的浮动时代，并最终掌握了 flexbox 和网格布局的强大功能。这是一门不断变化的学科。

在过去十年左右的时间里，大多数网页设计师学会了根据浏览者的屏幕尺寸来利用媒体查询的力量。网页设计需要调整以适应一个快速变化的世界，网站访问者突然将电脑握在手中，或者在客厅的大屏幕电视上舒适地阅读。然而，各种设备的激增带来了一个新问题：没有真正标准化的尺寸（最多是有根据的猜测，而非标准），即使有，明天也可能全部改变。媒体查询是一个很好的权宜之计，但过度使用它们也会使网站的 CSS 变得臃肿。

因此，设计需要继续演变成能够处理不断变化的网络环境的东西。这就是内在设计的用武之地。

什么是内在设计？

韦氏词典将“内在的”定义为“属于事物的本质或构成”。这就引出了一个问题：网络的“本质”是什么？

网络本质的一部分是它不断变化。与印刷设计不同，在印刷设计中你可以精确知道每一页的宽度和高度，并且可以完美地对齐所有内容而不用担心元素移位，网络是一种流动的媒介。它一直如此，而内在设计正是基于这个简单的事实来寻求解决问题的方法。

现代的流体排版是这一理念付诸实践的基础例子之一。想象一下，你希望设计中的 h1 标题为 64px。在网页设计的早期，你可能是在 800 像素的显示器上查看，并使用以下 CSS 来处理：

h1 {
	font-size: 64px;
}

在基于媒体查询的响应式网页设计中，你可能意识到 64px 在所有设备上看起来并不理想。也许你添加了一个媒体查询来根据设备视口更改它，如下面的 CSS 片段所示：

h1 {
	font-size: 48px;
}

@media screen and ( min-width: 767px ) {
	h1 {
		font-size: 64px;
	}
}

根据你需要定位的视口尺寸数量，这可能会迅速膨胀为多个媒体查询。此外，它并没有真正解决基于网络本质进行设计的问题。

遵循内在设计方法将意味着以一种无论视口大小如何都无关紧要的方式来处理问题。标题的大小无论如何都可以收缩和扩展。借助视口单位和 clamp() 等功能，这在现代 CSS 中是完全可能的，如下面的片段所示：

h1 {
	font-size: clamp( 2.25rem, 6vw, 3rem );
}

这是一个过于简单化的例子，涉及一个广泛的主题，但目标是让主题作者不断重新思考和重新评估使用他们可用的工具解决问题的最佳方案。

这也不意味着媒体查询和潜在的容器查询不是设计师工具箱中的关键元素。在某些场景下，继续使用它们是有意义的。然而，它们并不总是你需要使用的唯一工具。

本质上，内在设计确保单个项目知道如何布局自己，无论它在页面上的哪个位置使用。

内在设计对 WordPress 意味着什么？

随着 WordPress 5.0 中区块编辑器的引入，特别是 5.8 中区块主题的推出，在 WordPress 之上进行设计的格局发生了变化。从用户界面内部构建网站的最终目标正变得越来越现实。为了 WordPress 项目的健康发展，这意味着需要做出一些艰难的决定，不能一头扎进去将每个可能的 CSS 属性都作为界面中的选项添加。

很快人们就意识到，为了避免用户界面造成用户体验的噩梦，需要一种更缓慢、更有条理的方法。每一个新的设计工具都可能导致多年的技术债务。

此外，用户几乎可以在任何地方插入区块和区块模式。主题无法知道它们是在什么上下文中使用的，也无法考虑到所有用例。区块是在带有侧边栏的内容区域吗？布局是全宽、宽幅还是受限的？它遵循流式布局还是弹性布局？有太多的场景无法在区块级别使用媒体查询来解决。

现实是，设计仍然需要考虑屏幕尺寸的流动性。WordPress 需要使用现代技术来面对这个问题，同时控制用户界面的膨胀。
在一个标题为 Responsive blocks & intrinsic web design 的 Gutenberg 工单中，Joen Asmussen 阐述了这种方法背后的一些思考：

最终，动机不一定是完全摆脱媒体查询，而是探索一个问题：一个单一的区块模式在多大程度上可以做到开箱即用的响应式？一个可能受欢迎的副作用是，编辑用户界面可能会大大简化。媒体查询或容器查询可以被视为对内置内在行为的渐进式增强。

这不是一个一夜之间就能解决的问题。相反，它是一个迭代过程，开发者在过去几个主要版本中已经看到了新工具和技术的发布，并且可以期待更多。

这也是一种思维方式。不仅核心贡献者需要这样思考，主题社区也必须这样做。它必须不断问自己，今天的方法是否适合明天。

主题作者的工具和技术

在区块级别，主题作者没有太多控制权。虽然从技术上讲，可以编写大量自定义 CSS 来覆盖 WordPress 核心的功能，但通常最好避免这种情况。下一个主要更新可能会抹掉你大部分的工作。

对于容器/布局块（如 Group、Row、Stack 和 Columns）尤其如此。在几乎所有情况下，一般的经验法则是使用 WordPress 提供的功能。这些区块及其支持的功能在每个新版本中都变得更加强大。

主题作者最有控制权的地方是在 theme.json 中，通过利用排版和间距预设。

流体排版

WordPress 6.1 通过 theme.json 引入了对流体字体大小的内置支持。此功能允许主题开发者在指定范围内注册自定义大小，以根据屏幕尺寸增长和收缩，WordPress 在幕后处理所有复杂的计算。

主题作者可以将所有大小设置为流体，或者为单个大小启用/禁用该功能。下面的 theme.json 代码是 Twenty Twenty-Three 主题的删节示例，展示了如何通过 settings.typography.fontSizes 属性进行设置的三个例子：

{
	"$schema": "https://schemas.wp.org/trunk/theme.json",
	"version": 2,
	"settings": {
		"typography": {
			"fluid": true,
			"fontSizes": [
				{
					"fluid": {
						"min": "1rem",
						"max": "1.125rem"
					},
					"size": "1.125rem",
					"slug": "medium"
				},
				{
					"fluid": {
						"min": "1.75rem",
						"max": "1.875rem"
					},
					"size": "1.75rem",
					"slug": "large"
				},
				{
					"fluid": false,
					"size": "2.25rem",
					"slug": "x-large"
				}
			]
		}
	}
}

从用户的角度来看，这看起来像是用户界面中一个正常的大小选择：

然而，字体大小显示得有多大或多小完全取决于屏幕的尺寸。这对于创建能够自然适应读者所用设备的排版来说是一个巨大的胜利。

流体间距

WordPress 没有像字体大小那样开箱即用地提供流体间距系统。但是，它为主题开发者提供了构建自定义间距预设的自由，这意味着他们可以添加他们选择的任何有效的 CSS 值，包括使用 clamp() 来创建流体的边距、内边距和间隙选项。

Twenty Twenty-Three 主题是一个坚实的例子，展示了如何通过 theme.json 中的 settings.spacing.spacingSizes 设置来实现流体间距预设。以下是该主题 JSON 代码的删节示例：

{
	"$schema": "https://schemas.wp.org/trunk/theme.json",
	"version": 2,
	"settings": {
		"spacing": {
			"spacingScale": {
				"steps": 0
			},
			"spacingSizes": [
				{
					"size": "clamp(1.5rem, 5vw, 2rem)",
					"slug": "30",
					"name": "1"
				},
				{
					"size": "clamp(1.8rem, 1.8rem + ((1vw - 0.48rem) * 2.885), 3rem)",
					"slug": "40",
					"name": "2"
				},
				{
					"size": "clamp(2.5rem, 8vw, 4.5rem)",
					"slug": "50",
					"name": "3"
				}
			]
		}
	}
}

有几个在线工具可以计算 clamp() 值，甚至还有自己计算的公式，例如这篇来自 Smashing Magazine 的 clamp 教程。

添加自定义预设效果很好，它为用户提供了一个简单的滑块界面，用于调整支持边距、内边距和间隙选项的区块上的这些值，如下图所示：

用户不必担心这些看起来奇怪的值是什么。无论访问者使用什么屏幕尺寸查看，它们都能正常工作。

对于主题作者来说，这是将现有 CSS 功能集成到 WordPress 全局样式系统中的一种强大方法。