说到这里，肯定会有朋友提出质疑：「我毕竟没有退休，上班已经够累了，下班只想躺着刷刷手机，怎么可能再去做这些事？」。然而，刷手机很难说是有效的休息。App 的推荐算法通过调动人的情绪，使用户在开心与悲伤、得意与焦虑之间反复横跳，进而抓住用户的注意力。这样的方法有利于延长使用时间，但却无益于用户的心理健康。在情绪的拉扯中，用户的劳累、焦虑只会不断加剧。等到几个小时过后，只剩下雪上加霜的虚无感。相比起来，爱好与工作对大脑的调用有所区别，投入自己的爱好虽然看起来比较费劲，但只要能专注在其中，很快就会忘记烦恼和疲劳，工作大脑也能得到充分的休息。

仔细地审视人心，会发现很多惊人的矛盾。现实中，爱别人或爱物品似乎都要比爱自己常见得多。人们把自己的感情付出给爱人、付出给偶像、宠物、喜爱的品牌，或者付出给组织和国家。偏偏忘了，其他无论什么都是生命里的过客，从起点到终点，一直陪伴自己的始终只有自己。爱，尤其是无条件的爱，原本在自己身上最简单，最「合理」。「莫向外求」是有道理的，许多人为了能够被爱，起早贪黑，奋不顾身，就像沙漠中的人长途跋涉寻找甘泉，却忘记了绿洲就在自己出发的地方。

我自己常常经历或大或小的失衡。虽说都是我想要或需要做的事，但长期专注于一件事，总会变得索然无味，或者导致生活中实际的问题。比如说学习哲学固然快乐，然而抽象的知识学习久了容易脱离生活，甚至在心中贬低美食、美景这样直接的乐趣，给自己的生活平添烦恼；和朋友聚会固然快乐，可把时间全部消耗在社交上，缺少了独处时间，便很难澄清思想、实践爱好、发挥创造力，最终变得空虚。生活大概也和做菜差不多，需要五味俱全、荤素搭配。努力让自己的不同侧面和谐共处，不是把它们都按在一个房间里正襟危坐，而是要让它们从座位上起来，友好地交谈、游戏、逗乐。这样的生活，才算得上生机和趣味。

AI 摘要：本文通过多个实例（如艺术作品集和定价卡等）讲解了 CSS Subgrid 的基础概念、进阶用法与常见陷阱。Subgrid 允许嵌套元素继承父级网格结构，实现跨层级的布局一致性与响应性，从而简化复杂 UI 的构建。作者展示了它如何解决兄弟元素互不联动、语义化结构打破布局等老问题，并警示了行数预留、索引重置和兼容性等细节，同时提供了实用的 Fallback 策略。

1. Subgrid 基础与语义化改进
• 传统 CSS Grid 仅支持直接子元素参与布局，嵌套结构会破坏网格定位。
• Subgrid 通过继承父网格行列定义，让子元素（如 <ul><li>）复用父结构，从而保持语义化 HTML 与视觉布局同步。
• 基本用法：display: grid + grid-template-rows: subgrid + grid-template-columns: subgrid。
• 对比方案包括使用 Flexbox 嵌套 Grid，但 Subgrid 更能保持整体一致布局。

2. 新的布局可能性与动态响应
• 示例中展示了艺术作品卡片在不同屏幕下的两列布局问题，Subgrid 可让列宽动态适配内容。
• 通过共享父网格的列定义，兄弟 <article> 间可以互相影响，实现内容驱动的响应式调整。
• Subgrid 的计算方式可让布局在标题长度等内容变化时自动调整。
• 这种“跨组件感知”的能力是传统 CSS 无法实现的。

3. 实践陷阱（Gotchas）解析
• 行空间预留问题：Subgrid 默认只占一行，需明确声明 grid-row: span n 避免元素重叠。
• 索引重置：Subgrid 内行/列线号会重新编号，非父级的延续 ID。
• 流式网格不兼容：auto-fill, auto-fit 等自动列数写法与 Subgrid 不完全兼容，需要显式定义列。
• 旧版浏览器支持：截至 2025 年仍未达 90%，推荐通过 @supports 编写单列垂直 fallback 布局。

4. 实战与兼容性策略
• 用 Subgrid 搭建灵活的定价卡（Pricing Card）示例，实现不同卡片内容的行高完全对齐。
• 介绍 Feature Query (@supports) 实现优雅降级。
• 讨论如何平衡“视觉一致性”与“用户体验优化”；Fallback 不追求完美复刻，而是保持最佳体验。

5. 背景与应用前景
• Stripe Developer Site 是 Subgrid 的大型示范：多层 Subgrid 构建超大布局。
• 但作者更看重 Subgrid 在小范围 UI 调整、组件层布局优化的价值。
• Subgrid 可逐步引入项目，提高代码语义与一致性，而非一次性重构全站。

Joshwcomeau

Brand New Layouts with CSS Subgrid • Josh W. Comeau

Subgrid allows us to extend a grid template down through the DOM tree, so that deeply-nested elements can participate in the same grid layout. At first glance, I thought this would be a helpful convenience, but it turns out that it’s so much more. Subgrid…

AI 摘要：回顾了 <details> 与 <summary> 元素自 2018 年以来的演进，重点介绍了新引入的 ::details-content 伪元素，使得内容展开收起可实现平滑动画；同时讲解了内容锚点（hash）自动展开机制，以及 scroll-margin-block-start 的可用技巧。

1. HTML <details> 元素的演进
• 从 2018 年起 <details> 结构不断完善，三角箭头改为 ::marker，与列表元素标记统一。
• 新增 name 属性，支持手风琴式（accordion）互斥展开。
• 支持内容区域 hash 匹配自动展开，实现无 JS 的动态交互。
• 引入 ::details-content 伪元素，为内容区域提供 Shadow DOM 层级的样式控制。

2. ::details-content 实现动画展开效果
• 通过 transition 联合 content-visibility、height 等属性实现收展动画。
• 详细解释 allow-discrete 特性，使离散属性如 display 支持过渡动画。
• interpolate-size: allow-keywords 让 auto 尺寸参与动画计算。
• 属于渐进增强（progressive enhancement）方案，浏览器不支持也不会出错。

3. 锚点匹配与自动展开机制
• 当 details 内容的元素被 URL hash 定位时，details 自动展开。
• 该行为与 hidden="until-found" 类似，由 content-visibility 支持。
• 通过样式调整滚动定位：scroll-margin-block-start 设置元素滚动停留位置，提升体验。

4. 浏览器支持与语法参考
• 现代浏览器几乎在同一时间点全面支持 ::details-content。
• 使用语法为 selector::details-content，适用所有常规 CSS 属性。
• 由于支持良好，可放心在生产环境渐进式增强。

yousa (@y0usali): 我把前几天在Trae的分享整理成了文字稿
「https://yousali.com/posts/20251124-how-to-coding-with-ai/」
这篇文章写给已经在或准备在真实生产项目里用 AI Coding 的后端 / 全栈工程师和技术管理者。
它不会教你「按钮在哪里」「哪个 prompt 最神」，而是想在大约 15 分钟里，帮你搞清楚三件事：
哪些任务交给 AI 最「划算」；
怎么让项目本身变得更「AI 友好」，提高一次命中率；
当生成不再是瓶颈时，工程师应该如何设计验证流程，把时间花在真正值钱的地方。

AI 摘要：作者总结三年 AI 编程经验，指出 AI 写代码的时代关键不在「准不准」而在「值不值」。文章从个人与团队两个视角分析了 AI 生成代码的最佳使用场景（高重复、低风险、易验证）、如何构建「AI 友好」项目，以及工程师心态从「写代码」到「验代码」的转变。核心结论是：生成已不再是瓶颈，验证才是新的核心；AI 的上限取决于给它的上下文（Context）。标准化与自动化是让 AI 值得信赖的关键，而工程师应成为定义任务与设计验证系统的「总工程师」。

1. 两种声音与早期弯路 —— 从试验到思考
• AI 编程存在两极化认知：「神迹」与「玩具」并存。
• 初期盲目尝试，成功靠运气，暴露问题在于目标定义不清。
• 结论：关键在于明确「让 AI 干什么」，而非讨论「准不准」。

2. 从关注准确率到计算性价比 —— 「甜点区」的发现
• 引入「效率增益」公式衡量 AI 协作的价值。
• 四类高性价比任务：高重复、高耗时、低风险、易验证。
• 案例：模块化模板 + few-shot 示例提升生成质量。
• 心态转变：接受 AI 错误，注重系统级可靠性。
• 工程协作比喻：把 AI 当成「聪明但不熟悉项目的实习生」。

3. 团队视角的优化 —— 让项目更「AI 友好」
• 数据显示企业中 20%–30% 新代码由 AI 生成，但效率提升有限。
• 关键差异在于：项目是否标准化与自动化。
• 标准化**：统一接口规范、术语表、文档说明，让人机共享上下文。
• 自动化：降低验证成本，AI 助力 pre-commit、自动测试、CI/CD 等流程。
• 实践公式：讲清规则 → AI 辅助执行 → 人专注高价值审查。

4. 工程师的心理负担与注意力管理
• 高频切换任务使「注意力成本」爆炸，人类像「上下文很小的 LLM」。
• 心流（flow）被碎片化交互打断，导致疲惫与效率下降。
• 自救方法：时间分层、AI 时分复用、三分钟原则、沟通卫生与单线专注。
• 重点转移：保护注意力等于提升系统整体吞吐。

5. 稳定的两条工程原则
• 原则一：生成已非瓶颈，验证是核心
• 聚焦测试、监控、回滚机制。考核应基于 Bug Lead Time 而非代码量。
• 原则二：上下文为王（Context is King）
• 上下文完整度决定 AI 产出质量。
• 推广路径：统一规范 → 写进仓库 → 自动化验证。
• 单句箴言：AI 写代码的水平 = 你提供上下文的水平。

6. 给三类读者的建议
• 新手：从小型任务切入，先找「值不值」感受。
• 重度用户：从优化上下文与验证流程入手。
• 管理者：亲自尝试，引导从「个人提速」走向「团队工程化」。

AI 摘要：Ant Design v6 正式发布，以技术升级和未来兼容性为核心，全面支持 React 18+，引入纯 CSS Variables 模式、全量组件语义化结构，并新增 Masonry、可拖拽 Drawer、模糊蒙版等实用功能。此次升级保持对 v5 的完全兼容，带来更轻盈的打包体积与更灵活的定制体验。Ant Design X 也同步发布 2.0，聚焦 AI 场景的 UI 体验，预示着生态的又一次跃进。

1. 版本背景与发布说明
• Ant Design 自开源以来积累超 96K Star、2K+ 贡献者，社区生态庞大。
• v6 聚焦技术优化与未来 React 版本兼容，标志进入新阶段。
• 与 v5 之间为平滑迁移，v5 进入一年维护周期。

2. 技术升级与核心变化
• React 版本提升：最低要求 React 18，推荐使用 React 19，移除旧版兼容逻辑。
• 启用 React Compiler：在构建产物中优化性能，开发者可自行选择是否开启。
• 纯 CSS Variables 样式架构：全面弃用 IE 兼容逻辑，样式实现零运行时（zeroRuntime）模式，支持实时多主题切换。
• 组件语义化结构：所有组件 DOM 结构优化，支持函数式类名配置 (classNames) 与内联样式 (styles)，提升定制能力与可维护性。
• 移除废弃 API：彻底移除 v4 遗留逻辑，统一 API 命名，同时兼容 v5 的使用方式。

3. 新组件与功能增强
• Masonry 瀑布流组件：优化图片展示与卡片排布体验。
• Tooltip 支持平移切换：多内容提示实现滑动过渡。
• InputNumber spinner 模式：交互式加减按钮布局更直观。
• Drawer 支持拖拽：用户可调整抽屉大小。
• 模糊蒙版背景：所有弹层默认使用模糊特效，可按需关闭。

4. 升级指南
• v6 可直接从 v5 升级，无需 codemod 或兼容包。
• 项目需运行在 React 18+ 环境。
• 不再支持 IE，建议替换废弃 API。

5. 未来计划
• 聚焦移动端交互体验与可访问性（Accessibility）增强。
• 跟进 React 新特性，持续优化性能。
• 持续推出新组件，拓展生态边界。

6. One More Thing —— Ant Design X 2.0
• 面向 AI 场景的组件库同步升级，提供更智能的交互能力。
• 新版本强化渲染性能与灵活性，是探索 AI 驱动界面的关键工具。
• 更多详情可参考 🎉 Ant Design X 2.0 正式发布了 🎉。

7. 致谢
• 官方感谢 2000+ 贡献者的支持与共创。
• 十年开源历程，秉持「因为你们的参与，开源才美好」的初心。

AI 摘要：本文介绍了通过将动画关键帧 (@keyframes) 设计为可重用的 Keyframes Tokens，来实现动画系统的标准化与可维护化。作者说明了动画重复定义与全局作用域冲突带来的问题，提出以集中式样式表、命名空间、可定制的 CSS 自定义属性（custom properties）和设计 tokens 的方式来统一所有动画。文中展示了 fade-in、slide-in、zoom、spin、pulse 等动画的动态实现，并讨论了动画叠加、组合 (animation-composition)、可访问性 (prefers-reduced-motion) 与实际项目实施策略。核心思想是：让动画像颜色、字号、间距一样成为可管理的系统资源。

1. 动画混乱的根源
• 各组件独立创建重复的 @keyframes，导致代码冗余。
• CSS keyframes 属于全局作用域，容易被后加载样式覆盖。
• 修改或统一动画需全局搜查，影响维护效率。

2. 统一的解决方案：Keyframes Tokens
• 将动画关键帧集中存放在共享样式表中，形成唯一数据源。
• 利用命名空间（如 kf- 前缀）避免命名冲突。
• 借助 CSS 自定义属性实现动态参数化，支持多场景适配。
• 使动画定义与其他 design tokens（颜色、间距等）协同管理。

3. 构建基础动画库
• Fade In：定义基础淡入动画并统一调用。
• Slide In：通过自定义属性 --kf-slide-from 控制入场方向。
• Zoom：用 --kf-zoom-from/to 实现双向缩放。
• Spin/Pulse：封装连续动画，可控制旋转幅度、脉冲强度。
• Bounce/Elastic：展示复杂缓动（easing）动画封装方法。

4. 动画组合与冲突处理
• 可将多种动画组合，如 fade+slide 或 zoom+pulse。
• 对同一属性冲突时使用 animation-composition: add; 合并动画效果。
• 适当使用动画时间错位（stagger）提升视觉节奏。
• 说明 transform 与单独变换 (translate/scale) 的执行顺序差异。

5. 无障碍与减弱动效（Reduced Motion）
• 利用 prefers-reduced-motion 提供无动画或柔和过渡版本。
• 对需要仍然变换属性的动画定义瞬时完成（instant-in）版本。
• 保留必要动效但平滑化运动，提升可访问性。

6. 实施策略与最佳实践
• 渐进引入：从常见动画（fade、slide）着手。
• 命名规范：统一前缀标识 token 动画。
• 文档化：在 token 文件添加注释说明用途与参数。
• 灵活性与简洁性：仅暴露必要自定义属性。
• 融入设计体系：将 keyframes tokens 视为 design language 的一部分。

Smashing Magazine

Keyframes Tokens: Standardizing Animation Across Projects — Smashing Magazine

Animations can be one of the most joyful parts of building interfaces, but without structure, they can also become one of the biggest sources of frustration. By consolidating and standardizing keyframes, you take something that is usually messy and hard to…

AI 摘要：本文由 Rachel 撰写，灵感来自 TechBash 会议中 Mike Rapa 的讲座，介绍了 6 个鲜为人知的 Chrome DevTools 技巧。本篇是 Part 1，涵盖前三个内容：用 console.time() 和 console.timeEnd() 精准计时函数执行、利用 DOM Breakpoints 实时捕捉元素变化，并自动暂停脚本运行、以及用 monitor() 在控制台监听任意函数调用。

1. 文章背景与启发来源
• 作者参加 TechBash 会议，受到 Mike Rapa 的 DevTools 演讲启发。
• 本文专注于 Chrome DevTools 的 3 个隐藏功能，Firefox 部分功能支持略有不同。
• 计划分上下两篇，本篇为 Part 1，介绍前三个功能。

2. 计时函数性能监控
• 介绍 console.time() 与 console.timeEnd() 的使用，可精确测量代码块执行耗时。
• 提及 console.timeLog() 用于中间打印时间进度。
• 举例说明结合 React Hook 使用场景，展示暂停与超时逻辑的时间追踪方案。
• 来源：Mike Rapa 的演讲及 Github 仓库。
• 支持情况：原生 JS 特性，各浏览器均可使用。

3. 通过 DOM Breakpoints 检测元素变化
• 介绍如何在 Chrome Elements 面板中为任何 DOM 元素设置 "Break on" 断点。
• 当该元素属性、子树或节点被修改时，自动暂停脚本执行。
• 可快速定位导致页面 UI 异常的脚本。
• 提供 Stack Overflow 示例，展示实际操作方法。
• 支持情况：主流浏览器支持，Firefox 行为略有差异。

4. 使用 monitor() 监听任意函数调用
• 在控制台中可用 monitor(functionName) 监控任意函数调用及其参数。
• 帮助调试第三方脚本或不易插入 console.log() 的代码。
• 示例：sum(1,2) 会在控制台输出调用信息。
• 来源：Google DevTools Utilities 文档。
• 支持情况：仅支持 Chrome。

5. 预告与后续主题
• 作者计划在 Part 2 中讨论剩余三项：可视化编辑网页（WYSIWYG）、记录与重放用户操作、按需限速网络请求。
• 鼓励读者关注后续更新、尝试在实际项目中运用这些技巧。

AI 摘要：本文介绍了如何通过 CSS 3D transform 与 “layered pattern（分层模式）” 创建栩栩如生的 3D 图片效果。作者从 HTML 结构设计、CSS 3D 场景设置、层间位移计算、亮度与饱和度调节到交互控制面板（含 JavaScript）完整展示了创建流程。文章强调了分层视觉的本质是在二维平面中利用透视与光影制造立体幻觉，并通过 perspective、translateZ()、filter 等技巧实现动态的 3D 效果。

1. 3D CSS 概念与分层模式简介
• 概述 CSS 3D 的发展历史，从 2009 年起被 W3C 规范化
• “layered pattern（分层模式）”通过多个图层叠加制造立体幻觉
• 提示需理解 CSS perspective 与坐标系 (x, y, z) 概念

2. HTML 结构设计
• 使用 <div class="scene"> 包裹整个 3D 场景
• 建立多层重复图像 (.layer) 并以自定义属性 --i 标识层级
• 通过 aria-hidden="true" 处理无障碍可访问性问题
• 提及未来可通过 sibling-index() 和 sibling-count() 优化层索引

3. CSS 构建 3D 场景
• 设置 .scene { perspective: 1000px } 以控制深度
• 启用 transform-style: preserve-3d 让所有层在三维空间可见
• 通过 --layers-count 和 --layer-offset 控制层数与间距
• 利用 translateZ(calc(var(--i) * var(--layer-offset))) 实现纵深位移
• 计算标准化变量 --n 以动态调节亮度与饱和度实现光影变化
• 使用 filter: brightness() 与 filter: saturate() 增强立体层次
• 布局上将 .layer 与 .layers 设为 position: absolute; inset: 0 覆盖叠加

4. 动画与交互控制
• 通过 @keyframes rotate3d 添加旋转动画模拟立体旋转
• 创建交互控件（input range 滑块与按钮）控制 perspective、层间距与旋转角度
• 使用 JavaScript 监听输入事件动态更新 CSS 自定义属性与图像内容
• 示例函数 updateRotation() 绑定 X/Y 旋转值，支持图片更换

5. 附加功能与扩展
• 控制面板提供图像切换与参数调节体验
• JS 实现与视觉绑定，删除原有动画以改为实时控制
• 结尾展示延伸案例 “3D CSS steak”，说明同一技术可应用于更复杂视觉模型

6. 小结与启示
• 3D CSS 的核心在于“二维模拟三维”的视觉幻象
• 有效结合 transform、perspective 与 filter 可获得高性能的 3D 效果
• 分层模式可扩展用于文字、图片、UI 元素等多种设计

"这个按钮在监视你"。从 Jon Kantner 这款俏皮的按钮下面探出头来，你会发现一双卡通眼睛正在跟踪你的一举一动👀。

AI 摘要：介绍了由 Paul Smith 制作的 Classic Mac OS System 1 背景图案，这些极小尺寸的复古像素图案可通过 CSS background-repeat 实现无限平铺效果。尽管源自经典的 Mac OS 设计风格，但它们在现代网页中依然有独特的美感和实用价值。

AI 摘要：文章介绍了 Chrome 144 对 CSS 锚点定位（Anchor Positioning）机制的改进：从这一版本起，锚点定位将基于元素的“变换后”边界框（transformed bounding box），而不是此前的“未变换”状态，这让拥有 CSS transform 的元素上浮层、提示框等组件能够准确定位。该更新遵循 CSS 工作组（CSSWG）的最新规范决议，修复了长期存在的视觉错位问题。

1. 功能更新背景
• Chrome 144 将 Anchor Positioning 改为对 transform 变换敏感（transform-aware）
• 之前版本锚点计算基于未变换的边界框，导致定位错误

2. 技术细节与实现变化
• 新行为参考 CSSWG 规范修订（见相关 issue 链接）
• 更新后 tooltip、浮层等会根据元素的变换后位置进行定位

3. 实例与视觉演示
• 作者通过两个锚点的对比演示了旧版与新版定位差异
• Chrome 144 截图中两个 tooltip 均能正确跟随 transform 后的锚点

Bram.us

Anchor Positioning is transform-aware in Chrome 144+

Starting with Chrome 144, Anchor Positioning is going to be transform-aware. From then on, anchoring will resolve against the bounding box of the transformed ancho

 /* https://github.com/parcel-bundler/lightningcss/issues/887 */
  .scroll-feather-mask {
    container-type: scroll-state;
  }
  @container scroll-state(scrollable: bottom) {
    .scroll-feather-mask::before {
      content: '';
      background: linear-gradient(to bottom, transparent 0%, var(--gradient-bg-start) 70%, var(--gradient-bg-start) 100%);
      position: absolute;
      left: 0;
      right: 0;
      bottom: 0;
      z-index: 10;
      display: block;
      height: 5rem;
    }
  }

AI 摘要：文章主张 <Tooltip> （提示框）组件在设计系统中不应独立存在，因为它常被误用，导致可访问性和一致性问题。作者认为应通过更高层级的组件（如带有 title 属性的 <Button>、<IconButton>、<InfoIcon> 等）来统一提示行为。这种做法能确保键盘操作可达性、用户体验一致性，并减少错误使用的可能，是“限制创造力反而带来更好设计”的典型案例。

1. 问题背景：为什么 Tooltip 容易被误用
• Tooltip 在网页中常被视为简单组件，但其实现需兼顾可访问性（Accessibility）与交互性（Interactivity）。
• 很多设计系统提供 <Tooltip> 组件，却被开发者误用或滥用。
• 根因在于这是一个抽象层级过低的组件，不易强制正确实践。

2. 键盘交互问题（Keyboard Interactivity）
• 非交互元素（如纯图标或徽章）包裹 Tooltip，导致使用键盘导航的用户无法触发提示。
• 举例：Material UI 的 <Tooltip> 示例在非交互元素上无法聚焦。
• React Aria 提供更佳方案：不为非交互元素显示 Tooltip，并通过 <Focusable> 组件确保焦点可达。

3. 用户体验一致性（Least Surprise Principle）
• Tooltip 容易出现在不合适的位置，如句中词语或无法预测的界面处。
• 缺乏一致性会让用户预期混乱、有的图标无说明、有的却多余提示。
• 结论：Tooltip 使用应可预测且统一。

4. 替代方案与系统设计（Higher-level Pattern Components）
• 不提供通用 Tooltip，而是通过更高层级组件统一规则：
• <Button> 或 <Link> 增加可选 title 属性。
• <IconButton> 强制要求 title 属性，保证含义明确。
• <InfoIcon> 明确显示“更多信息”图标，内部控制提示逻辑。
• <InfoText> 组件强调文字说明，可聚焦且视觉可区分。
• 通过这些约束可提升一致性与可访问性。

5. “限制反而带来创造力”的思考
• 限制 Tooltip 的使用让团队重新思考信息展示方式。
• 空间不足时，应改进界面而非“藏信息”。
• 设计系统的目标：减少误用、提升用户体验。

tkdodo.eu

Tooltip Components Should Not Exist

A look at why tooltip components are often the wrong abstraction in design systems, leading to accessibility issues, misuse, and inconsistent user experiences.