早期的WordPress 5.9外观：走向更深层次的响应式块状设计之路

Gutenberg项目负责人Matías Ventura今天早些时候在Make Core博客上宣布了通往5.9的初步路线图。他涵盖了几个大项目，包括每个项目的几个子点。他还链接了一个GitHub问题，其中包括需要工作的具体任务和票据。

这篇文章涵盖了关于块状模式、导航菜单、theme.json接口（全局样式）、设计工具和块状主题的编辑流程的说明。有很多信息需要吸收，也有足够的领域来涵盖各种兴趣。

WordPress 5.9最令人兴奋的焦点可能只是深入到块级的响应式设计，无论是引擎盖下的代码还是通过用户界面提供的块选项。

文图拉写道：”模式和主题构建者最大的摩擦点之一是缺乏块级的响应工具”。”这需要以一种不会不成比例地增加界面复杂性的方式来解决。”

本质上的网页设计与块状结构

在过去的几年里，人们很容易对响应式块状选项的缓慢进展感到不满。我并不是完全不满意，因为我希望团队有条不紊地以一种面向未来的方式来处理这个问题，至少是在它能做到的范围内。

太多时候，我们在请求甚至第三方插件中看到的是使用基于视口的媒体查询来控制区块对不同设备（如桌面、平板和移动）的响应。虽然这种控制有时是正确的工具，但它们并不总是基于组件的设计的正确途径。

媒体查询倾向于整体的设计方法。然而，基于组件的设计是网络的现代面貌。块只是另一个组件，由于开发者甚至用户可以把它们放在整体设计的任何地方，我们必须处理它们对周围环境的反应，而不是浏览器视口。

“文图拉写道：”块模型是应用一些内在设计原则的好案例，因为块可以在许多不同的布局和容器中占有一席之地，对于这些没有考虑到上下文的规范性媒体查询是不灵活的。

一个简单的例子是WordPress核心的Columns块。我们可以很容易地为每个内部的Column块添加媒体查询选项。然而，对于三栏和四栏以及不同的宽度，排版应该如何反应？这是一个容器尺寸的函数，而不是视口的函数。

而且，当Column嵌套在另一个Column中时，这样的媒体查询如何工作？如果你把布局控制放到用户手中，这将成为一个更复杂的问题。在响应式块选项上按下快进按钮，目前可能感觉很好，但也可能造成遗留的包袱，当更好的解决方案出现时就很难丢掉。

即使是像基本的网站标题这样看似简单的东西，在为用户输入设计时也会变得复杂。对于主题设计师来说，没有办法知道网站标题中有多少个字符，或者导航菜单中有多少个项目。块状系统可以使之进一步复杂化，因为它允许终端用户放入其他未知的东西。

“文图拉写道：”每个区块都应该具有内在的响应性，允许区块组合在一起，包裹、堆叠和组织自己，以适应不同的空间和屏幕。”为了使这一工作顺利进行，容器块需要吸收更多的布局控制”。

他还提到容器查询是未来浏览器完全支持时的一个可能的扩展点。Chrome Canary目前有一个支持标志来启用该功能。

容器查询对设计师来说有点像圣杯。正如网页设计师Ethan Marcotte四年前写的那样：

也许我会从这里开始：在过去的几年里，我的设计工作更多地集中在模式上，而不是 “页面 “上。与其把响应式设计当作一个整体的、统一的东西，让布局的每一部分都以同样的速度变化和适应，不如把响应式布局分解成更小的、可重复使用的设计部分，包括像 “刊头”、”页脚”、”图片标题 “等等。

换句话说，我的设计过程包括把一个响应式设计看成是一个小型布局系统的网络。这些组件中的每一个基本上都是小的响应式设计本身，有它们自己的断点集。

听起来很熟悉吗？是的，WordPress的块系统也是建立在同样的小型布局组件的基础上的。

WordPress今天在用户界面层面所做的任何事情都需要考虑到未来的容器查询。或者，至少要利用现有的可以在某些方面复制这个功能的工具，比如min()、max()和 clamp()这些CSS函数。

问题是要弄清楚哪些功能应该作为块选项公开，而不是在引擎盖下处理。开发团队必须在用户体验和设计师的灵活性之间取得平衡。有些东西应该开箱即用，而有些则应该根据具体情况进行配置。

这应该是WordPress 5.9周期中要解决的更有趣、更复杂、更令人沮丧和更有价值的问题之一。对于那些寻找挑战的人来说，这可能是一个完美的切入点。