F2.15.3component response decouples from page breakpoints设计

组件级响应使布局可以脱离页面级断点系统独立演化

别名: 解耦断点 · independent layout evolution

概念解释

营销页可以继续只保留两个视口断点管壳(导航、分栏)。产品卡、报价块、引用各自在自己的容器宽上切换,不必为了「卡在 420 要改排」去给整页加一个新的 420 视口断点。组件级响应让局部布局按自己的节奏改,页面断点矩阵不必跟着每个内层模块膨胀。

视口断点数量会乘验证成本。把内层切换从矩阵里拿出去,是在给那条账做减法。

机制

关注点分开:页面 @media 编码壳的信息架构,组件 @container 编码局部怎么装。两者变更频率不同、所有者也不同。卡团队改 420 的内部切换,不必走一页壳的发布;壳团队改汉堡阈值,不必重测每张卡。独立演化来自这层接口。

耦合的残渣是:仍然用视口查询去改单一内层组件。那一刀会把组件重新焊回页面矩阵,独立演化立刻消失。

边界

壳和组件如果必须同步改(新的折叠屏形态要求卡和导航同一天换拓扑),独立是假的,该一起做。没有容器查询的降级路径会把组件行为重新绑到视口,演化再次耦合。微型站点只有一页、两三个组件,分开两套断点系统的管理成本可能高过收益。

怎么落地

  • 盘点现有视口断点,凡是只为了给某一个内层组件换排而存在的,改写成该组件的容器查询,并从页面矩阵里删掉。
  • 文档里分开两列:壳断点、各组件自己的容器切换。改其中一列不应要求另一列发版。
  • 验证:给产品卡加一种新的内部布局,看是否动到了页面媒体查询。动到了,耦合还在。再看页面断点列表:若某条的唯一理由是「让卡变矮」,那条应已不在。回归壳的主路径,确认删掉那条视口断点没有弄坏导航。

延伸

  • 同组F2.15.1 容器查询让组件依据自身可用空间而非视口断点响应 · F2.15.2 同一组件在不同容器宽度下可复用不同布局 · F2.15.4 过度细分的容器断点会造成组件行为难以预测
  • 相邻F2.10 响应式断点 · F2.11 流式与自适应布局 · F2.08 卡片式布局
  • 站内检索decoupled breakpoints · container query · page shell · layout evolution

同组卡片

快捷操作

分享

分享当前页面

ios_share

https://hci.top/zh/handbook/F2.15.3