原文：Solving Shrinkwrap: New Experimental Technique (Kizu)
欢迎关注 前端周刊，每周更新国外论坛的前端热门文章，紧跟时事，掌握前端技术动态。
前端写 UI 写久了，你总会遇到一种特别别扭的视觉：内容明明只有两三行字，容器却像被"撑到一整行"那样宽，留下一大块无意义的空白。标题、标签、气泡、tooltip、legend、图片 caption......只要文本会自动换行，这个问题就会反复出现。
大家管它叫 shrinkwrap：容器应该像"紧贴包裹"一样贴着内容生长。CSS 在很多场景里有 inline-block、max-content、fit-content()，看起来都像答案；但只要内容换行、参与布局分配（尤其是 flex / grid 的剩余空间分配），你就会发现"贴合"很容易变成"占满"。这也是 Roman Komarov 这篇文章要解决的核心：让会自动换行的内容，依旧能得到真正影响布局的 shrinkwrap，而不仅仅是画出来像。(Kizu)
文章给出的结论很直接：把两个近两年逐渐成熟的 CSS 能力拼起来------Anchor Positioning（锚点定位） + Scroll-driven Animations（滚动驱动动画） ------就能在纯 CSS 里完成一件过去高度依赖 JS 的事情：测量内部内容的几何尺寸，然后把测得的结果回写给外层容器作为尺寸约束 。(Kizu)
这听起来像"黑魔法"，但它的工程价值很明确：只要浏览器支持相关特性，布局就能进入一个更"内容驱动"的状态；不支持时还能优雅降级为普通布局（只是没那么好看）。作者也强调了实验性与风险，尤其提到 Safari 的崩溃 bug，以及生产使用要谨慎评估。(Kizu)
这个问题为什么难：换行会引发"宽度争夺战"
理解 shrinkwrap 的难点，关键在"自动换行"这四个字。
当文本能换行时，布局系统倾向于先拿到一个"可用空间"，再在这个空间里排版、换行、对齐。很多组件在 flex / grid 里看起来"突然变宽"，根源就在这里：元素宽度开始响应外部可用空间，内容的换行结果又反过来影响元素看起来"应该多宽"。你想让容器贴着内容，布局引擎却更愿意让内容适配容器。
这也是为什么过去常见的解决方案要么是 JS 测量（getBoundingClientRect() / offsetWidth），要么是硬编码换行（手动 <br>），要么是接受不完美（靠背景伪元素装饰出"看起来贴合"）。作者在 2023 年的旧文里就做过一种偏装饰性的 workaround：锚点能把装饰物贴到换行文本边上，但它不改变真正的布局尺寸，所以仍然"看起来对、布局没变"。(Kizu)
这次的新技巧，目标更激进：直接改布局。
核心思路：放一个"探针"，用滚动动画把尺寸"偷"出来
整套方案可以拆成一句话：
让内部内容在一个可控的"内盒子"里自然换行；再放一个绝对定位的 probe（探针）锚定到内容的边界；用 view-timeline 把 probe 的位置映射成 0~1 的动画进度；把这个进度还原成实际像素值；最终把像素值写回外层容器的
inline-size/min-inline-size。
这里最关键的点，是作者把"滚动驱动动画"当成了一个远程状态传递 / 远程测量 机制：动画本来是拿来做动效的，但它天然具备"把一个元素在某个坐标系里的位置，转成一个可被 CSS 变量表达的数"的能力。(Kizu)
这条思路在社区里也有呼应。作者引用了 Temani Afif 2024 年的文章：同样利用 scroll-driven animations，在纯 CSS 里计算元素宽高。两者差异在于测量点的选择：Temani 的方法更像用一个 1px 元素配合比例反推 scrollport；Roman 这篇更依赖 anchor positioning，把探针直接钉到想测的"那个边界点"，再配一个很大的 timeline-range 当分辨率去还原数值。(Kizu)
基础结构：为什么要多包三层
文章给出的基础 HTML 结构很"刻意"，因为它本身就是 API：
xml
<div class="shrinkwrap">
<div class="shrinkwrap-content">
<span class="shrinkwrap-source">
<!-- Text -->
</span>
<span class="shrinkwrap-probe"></span>
</div>
</div>每一层都有明确职责：(Kizu)
shrinkwrap：外层真正要参与布局、最终要被"缩到贴合内容"的元素。shrinkwrap-content：一个允许"比外层更宽"的内盒子，它决定文本如何换行；同时它承担溢出裁剪（overflow: hidden），为 view timeline 提供必要条件。(Kizu)shrinkwrap-source：被测量的目标，默认是行内内容（display: inline），并提供anchor-name作为锚点标识。(Kizu)shrinkwrap-probe：探针元素，绝对定位、禁用 pointer events，通过position-anchor锚定到 source，并建立 view timeline，让外层能"读到"它。(Kizu)
这里有个非常工程化的判断：作者建议 probe 优先用真实 DOM 元素，避免 Safari 在某些条件下因为伪元素 probe 触发标签页崩溃；他还给出了 WebKit 的 bug 链接，并解释了自己如何做最小复现来定位问题。(Kizu)
外层 shrinkwrap 的 CSS：测量 + 回写 + 降级
外层 shrinkwrap 的 CSS 片段里，能看到三个层次的动作：(Kizu)
1）用 layers + 自定义属性定义一套可覆写的 CSS API（让这套技巧像"组件"一样可配置）。
2）通过 timeline-scope + animation 把内部 probe 的 view timeline"提升"到外层可访问的作用域，然后把关键坐标写进自定义属性。(Kizu)
3）把写入的变量用于 inline-size / min-inline-size 的计算，最终让外层真的变窄。(Kizu)
作者还用了他自己长期研究的一类技巧：Cyclic Dependency Space Toggles ，用来做"条件式启用"和更顺滑的降级。它的意义很现实：当浏览器不支持 timeline-scope 或锚点定位时，布局回到普通状态，页面照样能用，只是视觉贴合度下降。(Kizu)
文章里也专门列了限制条件，比如外层可以处在普通流、block/inline-block、flex/grid item 都行，但它自己不适合再成为 flex/grid 容器；并且它的 max-inline-size 不能依赖兄弟元素，否则就会进入更难处理的循环依赖。(Kizu)
文本对齐是隐藏大坑：左对齐之外都要补一刀
如果文本永远左对齐，基础技巧已经够用：因为左边界固定，外层缩到合适宽度就能"贴住"。(Kizu)
一旦出现 text-align: center/right，问题就变得微妙：文本的对齐发生在更大的内盒子里（shrinkwrap-content），外层虽然缩小了，文本依旧在内盒子里"按大宽度对齐"，视觉上就会漂。作者给的解决方式很聪明：继续复用测量阶段得到的变量，给 shrinkwrap-content 加一个相对定位偏移，用 inset-inline-start 把它挪回去。(Kizu)
这里还提到 Safari 的一个渲染差异：同样的对齐切换，在 Safari 上第一行的排版变化可能比 Chrome 明显得多，这意味着边缘 case 仍然存在。(Kizu)
把基础技巧当积木：列表、卡片、段落都能拼
文章中段最有启发的一点，是作者把这套 shrinkwrap 当成"布局积木"来使用：
如果一个复杂内容能拆成多个"独立的行内内容上下文"，就对每一段行内内容重复使用 shrinkwrap，然后在更外层用 max-content 或其他方式把整体也贴合起来。作者用多项列表放进卡片、每项可能多段落的例子说明：只要拆分得当，这套技巧就能覆盖比"标题贴合"更复杂的 UI。(Kizu)
这也解释了为什么 API 里最重要的自定义属性是 --sw-limit：它相当于告诉这套技巧"允许文本最多占用多宽的上限"，常见默认是 100cqi（容器查询的 inline size 单位），当你希望旁边还留空间给其他列或控件时，就把它算成 50% 减 gap/padding 的形式。(Kizu)
此外还有 --sw-padding、--sw-inner-padding、--sw-inset、--sw-source 等，用于把 padding 纳入计算、改写 probe 测量范围、甚至让被测量元素在 shrinkwrap 外部时建立连接。(Kizu)
复杂内容：从"枚举锚点"到"链式锚点怪物"
当内容不再是简单的行内文本，而是可换行的 flex/grid items，问题会升级。
文章给了两条路线：
1）多个显式锚点：知道元素数量，就能算出包围盒
思路很直接：给每个 item 分配唯一 anchor，然后在一个 min() 里把所有 anchors 的 inset 都列出来，计算出决定 shrinkwrap 尺寸的"最远边界"。作者还提到需要用 calc(infinity * 1px) 作为回退，避免某些 item 不存在时计算出错，并让它在 min() 中被"优雅忽略"。(Kizu)
2）链式锚点怪物：不枚举数量，用布局顺序做"求最值算法"
这一段读起来像科幻：每个列表项里放两个 probe（left/right），利用"多个 anchors 共享同名时可以链式指向前一个有效目标"的行为，配合容器查询，当 probe 宽度变成正值时动态写入 anchor-name，让"最左/最右"像接力一样传递下去。作者把它形容成"用布局表达的求最大值算法"。(Kizu)
现实限制同样明确：这个 chaining 行为目前主要在 Chrome 可用，Safari 和 Firefox 存在严重 bug，作者还给出了对应的 WebKit 与 Bugzilla 链接。(Kizu)
性能也有边界：元素超过 100 个可能出现 long task，1000 个元素能测到十几秒级别。(Kizu)
这两段内容的价值，更多在于"把 layout 当计算模型"的思维：CSS 在逐步获得可组合、可推导的能力，开发者开始能用声明式规则去逼近过去必须写脚本才能做的布局决策。
跨依赖的终极难题：菜单场景依旧很硬
文章把最难的 shrinkwrap 用例留给了"导航菜单"：同一行里多个 flex items 一起参与空间分配，空间不足时整体换行、间隙变得很难看。这个场景里，每个 item 的可用宽度取决于其他 items，限制值会动态变化，基础技巧需要一个稳定的 limit 才能成立，因此很难直接套用。(Kizu)
作者目前找到的可行路线是"内容复制"：先渲染一个隐藏版本进行测量，把每个 item 的尺寸同步到可见副本，再把整个菜单作为整体放进另一层 shrinkwrap，让它也能贴合并把空间让给搜索框等控件。(Kizu)
他也明确说这套实现非常脆弱，暂时不提供完整代码，更多像一个"方向指示牌"。
一组很落地的用例：气泡、legend、图片 caption、tooltip
文章后半段很像"设计系统组件目录"，每个例子都击中真实需求：(Kizu)
- 聊天气泡 ：Web 上长期难做得像原生，关键卡点就是换行后的贴合与对齐；新技巧让
text-wrap: balance终于能更稳定地发挥作用。(Kizu) - fieldset/legend ：过去常靠伪元素补边框，新技巧可以让 legend 在换行后依旧贴合，并保留原生行为。(Kizu)
- 图片覆盖 caption ：半透明背景尽量少挡图，文字短没问题，换行就会横向铺满；shrinkwrap 能让背景贴合文本块。(Kizu)
- tooltip/popover ：既要均衡排版又要上限宽度，缺 shrinkwrap 时很容易"宽得难看"，新技巧能把弹层做得更紧凑。(Kizu)
这些例子共同说明了一点：shrinkwrap 不是"为了省几像素"，它直接影响组件的密度、节奏、对齐感，最终影响整个界面的高级感。
未来展望：原生 shrinkwrap 可能先从"简单版"落地
作者最后的判断很务实：原生层面优先解决"最基础的用例"更划算，也就是已知上限的 max-inline-size 场景 。这个能力可以通过新增属性或新增函数提供，可能需要配合 containment 来避免百分比尺寸引入循环依赖。简单版一旦落地，就能覆盖过去十多年里大量真实需求。(Kizu)
菜单这种跨依赖 shrinkwrap 属于更复杂的布局问题，先不追求一步到位。作者计划把文章链接与提案发到 CSSWG 的相关 issue，鼓励有明确用例的人去补充需求，让规范讨论更贴近现实。(Kizu)
给工程落地的判断：这套技巧适合用在什么地方
结合作者的免责声明和这些 demo 的特性，可以得到一个很清晰的落地边界：
这套技巧很适合"增强型体验"的组件：启用后更精致、停用后可用性不受影响，风格与 text-wrap: balance 很接近。(Kizu) 典型场景就是设计系统里的装饰性容器：气泡、徽标、标题标签、图片角标、tooltip。
对于强交互、强一致性要求的核心业务布局，需要更保守：一方面浏览器支持仍在演进，另一方面作者已经遇到过 Safari 崩溃与 chaining 兼容问题。(Kizu) 这类场景更适合把它当成"可插拔的增强层"，用 @supports 控制启用范围，把风险隔离在可回退的层里。
结语：CSS 正在获得"测量与反馈"的闭环
这篇文章真正让人兴奋的点，未必是"终于能做 shrinkwrap 了"，而是 CSS 的能力边界正在发生变化：
Anchor positioning 让元素之间的几何关系变得可引用；scroll-driven animations 让"位置/可见性"变成可计算的连续变量；@property 让变量具备类型与插值语义；容器查询让组件能读取自身所处环境。(Kizu)
当这些能力开始互相咬合，CSS 就出现了一条新的路径：布局不仅能声明，还能推导；样式不仅能描述，还能计算；组件不仅能渲染，还能自适应地回写自身约束。
你可以把这篇文章当成一次"未来 CSS"的预演。它已经能在部分稳定版浏览器里工作，也已经能解决一批非常真实的 UI 痛点。剩下的，就是把这些实验性的组合，逐步沉淀成更朴素、更可靠的原生能力。(Kizu)