AI 摘要：本文讲述了如何仅使用 CSS（不依赖 WebGL 或 Canvas）创建三维等距地形，通过层叠网格（stacked grids）与 3D 变换（3D transforms）构建出一个像素风的生成式世界。作者介绍了从镜头视角（perspective）设置，到多层网格架构、地形单元（flat、ramp、wedge、spike）的几何定义，再到噪声生成高度图和性能优化等完整技术路径。

jhey ʕ•ᴥ•ʔ (@jh3yy): hook this 3D CSS card up to device rotation? sure! 👨‍🍳

tip: use the DevTools "Sensors" emulator with "Custom Orientation" to debug/refine before taking it to a real device 👇

在 Jhey Tompkins 设计的这款可配置 Pen 中，将鼠标悬停在加号网格上，即可观看它们变换颜色和旋转。您还可以通过顶部的控制面板调整网格大小和主题颜色。

AI 摘要：本文介绍了 CSS 中新引入的 sibling-index() 和 sibling-count() 两个函数，它们让我们可以直接通过纯 CSS 计算元素在兄弟节点中的相对位置，实现无需 JavaScript 的 “错位动画（staggered animation）”。通过结合这些函数与 :has() 伪类、transition 延时变量等技巧，作者演示了如何在选中某个卡片时，让它左右的卡片以时间递增或递减的顺序逐个消失，完整地展示了纯 CSS 动画逻辑与可替代 JS 的思路。

1. 新函数简介与基础概念
• sibling-index() 返回元素在兄弟节点中的序号，从 1 开始计数；
• sibling-count() 返回兄弟节点的总数（包含自身）；
• 二者结合可实现基于结构位置的样式或动画计算，例如递增宽度或动画延时。

2. 示例布局与核心结构
• 使用 .cards-wrapper 包裹多张 .cards 卡片，通过 flexbox 横向排列；
• 每个 .cards 内部含有覆盖整个卡片的 input[type="checkbox"]，点击后触发交互。

3. 主要的选择器逻辑

• .cards:has(:checked)：选中状态的卡片，用于高亮；
• .cards-wrapper:has(:checked) .cards:not(&)：当有选中卡片时，让其他卡片消失；
• & ~ .cards 与 .cards:not(&) 分别控制右边与左边卡片的延迟方向（递减或递增）。

4. 样式声明解析
• 高亮选中卡片：添加虚线边框；
• 让未选卡片消失：透明度降为 0，宽度缩为 0，并在动画结束后设置 display: none；
• 过渡动画：transition-behavior: allow-discrete 保障 display 的离散变化；
• 时间递减／递增：
• 右侧卡片使用 --n: calc(sibling-count() - sibling-index() + 1)；
• 左侧卡片使用 --n: sibling-index()；
• 最终延时计算：transition-delay: calc(var(--n) * 0.2s)。

5. 动画示例与完整规则组合
• 当某张卡片被选中时，其它卡片依序向外逐个消失，形成错位延迟动画效果；
• 所有规则组合后实现纯 CSS 版本的交互过渡，无需额外脚本支持。

6. 兼容方案（Fallback）
• 对不支持 sibling-* 函数的浏览器，通过 JavaScript 动态计算 --n 值；
• JS 逻辑基于监听 change 事件手动设置左右两侧卡片的延时变量；
• 保持与 CSS 核心机制一致的动画行为。

7. 扩展示例与实践思路
• 使用 sibling-index() 实现类似手风琴（accordion）式开合动画；
• 即便不带延时，也可通过该函数控制显示隐藏的顺序与方向；
• 展示纯 原生 CSS 实现复杂交互效果的潜力。

Frontend Masters

Staggered Animation with CSS sibling-* Functions

The CSS functions sibling-index() and sibling-count() return an element’s position relative to its siblings and the total number of siblings, including itself. This is useful for styling elements based on their positions.

AI 摘要：本文系统解析了 JavaScript 中 Source Map 的内部机制，从 TypeScript 构建流水线到 Source Map 的 JSON 结构与 Base64 VLQ 编码，作者逐步展示了浏览器如何通过这些映射信息，将压缩后的生产代码还原回开发者可读的源文件位置。

1. 引言：Source Map 的作用
• 解释 Source Map 如何连接构建后的 “生产代码” 与原始源文件
• 举例说明浏览器在 DevTools 中如何利用 Source Map 还原源码位置

2. TypeScript 构建管线（Build Pipeline）
• 概述现代 JavaScript 构建的三个阶段：转译 (Transpilation)、打包 (Bundling)、压缩 (Minification)
• 展示原始 TypeScript 源文件示例（add.ts / fibonacci.ts / main.ts）
• 强调每个阶段 Source Map 保持了源代码映射关系

3. Source Map 文件结构
• Source Map 为 JSON 格式，通常以 .js.map 结尾
• 字段详解：
• version：版本号（通常为 3）
• file：对应的生成后文件名
• sourceRoot：源文件路径前缀
• sources / sourcesContent：原始文件路径和内容
• names：标识符数组（变量与函数名）
• mappings：压缩映射字符串（核心内容）
• 指出 mappings 字段使用 VLQ 编码进行空间压缩

4. 理解映射机制：VLQ 编码 (Variable Length Quantity)
• mappings 字符串由逗号与分号组成，分号分行、逗号分列表示段（segment）
• 三种 segment 格式：
• 单值：仅表示生成列位置
• 四值：完整的源映射
• 五值：包含原始名称索引（变量或函数重命名时使用）
• 说明相对位置编码（delta encoding）原理——通过存储偏移量而非绝对位置实现高压缩率

5. VLQ 编码的工作原理
• 每个数字通过以下步骤编码为 Base64：
1. 编码符号位（sign bit）区分正负数
2. 拆分成 5 位数据块+1 位延续标志 (continuation bit)
3. 使用 Base64 字符表映射（A–Z, a–z, 0–9, +, /）
• 举例说明数字 7 如何被编码为 “O”
• 总结其节省空间与高效解析的优点

6. 实例解读与调试意义
• 通过 add.js.map 的 decode 过程展示行列映射
• 演示如何由压缩代码精确反查到原始 TS 源文件行列
• 强调 Source Map 在前端调试、错误定位和代码回溯中的核心地位

Do more with less. | Polar Signals

The Inner Workings of JavaScript Source Maps

A deep dive into how JavaScript source maps work under the hood, with examples showing how all the pieces fit together.

AI 摘要：自 2025 年 11 月 5 日起，npm 将正式禁用新建经典 (classic) token，并强化细化 (granular) token 的安全策略，包括强制启用双重验证 (2FA) 及限定有效期为 90 天。现存的经典 token 将在 11 月 19 日彻底失效，用户需尽快迁移至新的 granular 权限模型。

1. 更新背景与总体说明
• 本次更新是 npm 提升安全策略的重要阶段，意在统一令牌 (token) 管理机制。
• 仅 npm 注册表使用的 token 受影响，GitHub 自身的 token 不受波及。

2. 主要变更：经典 token 停用
• 自 2025 年 11 月 5 日起，无法通过网站、CLI 或 API 再创建 classic token。
• 现有 classic token 可继续使用至 11 月 19 日，之后将全部失效。
• npm token create 不再生成 classic token。

3. granular token 改进措施
• 新建具有写权限的 npm granular token 默认强制要求启用 2FA。
• 针对 CI/CD，可设置 “Bypass 2FA” 选项（默认关闭）。
• 所有具写权限的 granular token 有效期上限调整为为 90 天，原定于 2026 年 2 月 3 日之后到期的现有 token 已调整为在该日期到期。

4. 用户应对与迁移步骤
• 用户须在截止日前迁移 classic token 至 granular token。
• 迁移流程需通过 npm 账户设置页面 完成，选择 “Generate New Token → Granular Access Token”。
• 依工作流需求配置权限，CI/CD 可启用 Bypass 2FA 或使用 OIDC。
• 目前 granular token 仅可通过网站生成，CLI 支持将在后续添加。

5. granular token 用户的注意事项
• 定期检查 token 过期时间并规划轮换 (rotation)。
• 对非交互式发布需求，可能需启用 Bypass 2FA。

6. 不受影响的范围
• GitHub classic 个人访问 token、fine-grained 个人访问 token、GitHub Actions secret 以及 GITHUB_TOKEN 均无须变更。
• 但若内含 npm 凭证，应相应更新。

7. 接下来的关键节点：2025 年 11 月 19 日
• npm 将彻底吊销 classic token，并引入 2 小时有效的动态 session token 取代长期本地发布凭证。

8. 支持与参考资源
• npm token migration guide 提供迁移指引。

The GitHub Blog

npm security update: Classic token creation disabled and granular token changes - GitHub Changelog

Editor’s note (November 5, 2025): We’ve updated this post to explicitly clarify that the affected tokens are npm tokens. Today marks another milestone in our ongoing effort to strengthen npm’s…

AI 摘要：作者以在写书时想展示一个简单的 Elm 与 JavaScript 交互的例子为起点，却发现实现“复制文本到剪贴板”这一任务远比想象复杂。从浏览器支持、权限、各版本 Safari 到移动端兼容问题，现代 Clipboard API 充满意外。由此引出反思：Web 平台为兼容历史与安全性付出的代价是越来越厚重的复杂层。最终，作者选择一个可用的示例，提醒开发者：有时候要接受现实的混沌与妥协。

1. 起因与动机
• 作者在写一本面向 React 开发者的 Elm 书，想找一个简洁、通用的浏览器 API 示例。
• 选择了实现一个“复制到剪贴板”的小功能，却意外发现这是 Web 平台的一个“大坑”。

2. 寻找方案与初步尝试
• 作者在 npm 搜索时，发现竟有上千个剪贴板相关包。
• 表面上使用 navigator.clipboard.writeText() 非常简单，但实际上问题重重。

3. 现实中的各种问题
• 浏览器支持：仅在安全上下文（HTTPS/localhost）可用，HTTP 环境失效。
• 权限机制：不同浏览器策略不一，有的需用户交互，有的静默失败。
• Safari 特例：行为不可预测，有时 API 存在但无效。
• 传统方案重新上场：通过隐藏的 <textarea> 加 document.execCommand('copy') 方法，虽然过时，却更稳定。
• 移动端挑战：iOS、Android 各有怪癖，需在真实设备上测试。

4. 为什么有 1000+ npm 包
• 每个包都是在调和这些兼容性问题的尝试。
• 从 polyfill、fallback，到各框架（React/Vue）的封装，最终形成生态的“碎片化复杂性”。

5. 深层反思：复杂性在何处
• Web 平台无法移除旧 API，只能持续叠加新接口。
• 浏览器行为微妙差异导致“只想复制文本”都需多层抽象。
• 开发者的“临时解决方案”又进一步催生新复杂。

6. 结语：接受不完美
• 作者在书中只展示了一个工作的例子，并指出“这事复杂，但这不是重点”。
• Elm 通过 port（端口）层与 JavaScript 保持距离，体现了设计上对混乱生态的隔离思路。
• 对开发者而言，重要的不只是解决问题，而是理解复杂系统背后的现实与妥协。

cekrem.github.io

The Clipboard API: How Did We Get Here?

Or: why there are 1000+ npm packages for copying text to clipboard

AI 摘要：本文系统介绍了 CSS 属性 text-wrap 的功能、可选值及其对文本可读性与界面美观度的影响，重点对比了 text-wrap: balance 与 text-wrap: pretty 两种排版策略在不同场景的使用。

1. 属性综述与支持现状
• text-wrap 于 2024 年进入“新增可用”(Newly available) 基线状态，最新版本主流浏览器支持，旧版本不兼容。
• text-wrap 控制文本如何换行，并允许开发者关闭或自定义换行行为。
• 支持的值包括：wrap、nowrap、balance、pretty、stable。

2. 各个属性值解析
• wrap：默认行为，按合理点换行，确保可读性。
• nowrap：禁用换行，文本溢出容器。
• balance：通过调整行长平衡视觉比例，提升排版对称性。
• pretty：避免“孤字行”(orphans)，平衡段落末行排版，Safari 上该属性避免出现“排版河”(typographic rivers)。
• stable：理论上用于编辑文本时防止换行重算，但目前表现与 wrap 一致，不稳定。

3. text-wrap: balance 与 text-wrap: pretty 深度比较
• 共同点：均改善可读性、排版平衡度和视觉流畅性。
• 差异：
• balance 专注行长平衡。
• pretty 注重避免孤字与断词问题，更复杂但视觉自然。
• 性能考量：两者都较为耗费计算资源。
• balance 在 Chrome 中受 6 行限制，Firefox 限 10 行，Safari 不限。
• pretty 性能影响更大但无行数限制。

4. 浏览器兼容与前瞻
• text-wrap: pretty 在当前（2025 年 9 月）仍未被 Firefox 支持，可作为渐进增强使用。
• 新值 text-wrap: avoid-short-last-lines（前称 avoid-orphans）尚无浏览器支持。
• 各浏览器在算法实现上各异，未来或将进一步优化。

5. 应用与实践建议
• 小段文本（标题、卡片内容）适合 balance。
• 段落性文字可尝试 pretty 以优化阅读体验。
• 注意性能评估与浏览器兼容性，可使用 @supports 检测。
• 结合 ch 单位设定文本宽度并不直接影响 text-wrap 效果，但两者可配合。

6. 用户体验与设计意义
• 平衡行长与避免孤字行能显著提升可读性与整体 UI 美感。
• 优化排版对可访问性 (Accessibility) 和可用性 (Usability) 均有积极效果。
• 排版优化是现代前端设计中提升用户体验的重要环节。

LogRocket Blog

When to use CSS text-wrap: balance vs. text-wrap: pretty - LogRocket Blog

Compare and contrast two CSS components, text-wrap: balance and text-wrap: pretty, and discuss their benefits for better UX.

AI 摘要：本文系统梳理网页动画性能的分级标准，从浏览器渲染管线（render pipeline）的底层原理出发，解释为何某些动画（如 transform、opacity 等）能高效运行于 GPU 的 compositor 线程，而另一些（如涉及布局、重绘的动画）则极为耗费资源。作者将动画按性能分为 S 到 F 六个等级，指出各层级的触发条件、适用场景及典型陷阱，并给出实践经验（如 will-change 的使用、CSS 变量的潜在灾难、“thrashing”问题等），帮助开发者建立动画性能直觉与优化策略。

1. 渲染管线与性能基础
• 解释浏览器渲染的三个阶段：Layout、Paint、Composite，并指出触发一个阶段会引发其后所有阶段。
• 区分主线程（main thread）与合成线程（compositor thread）的运行逻辑，说明主线程阻塞将导致动画卡顿。

2. 分级体系（Tiers）总览
• S-Tier：完全运行于 compositor 线程的硬件加速动画，性能最佳。
• A-Tier：在主线程驱动但仅触发 compositor 操作的动画。
• B-Tier：含有一次性 DOM 测量成本的动画。
• C-Tier：触发 Paint 的动画。
• D-Tier：触发布局（Layout）重新计算。
• F-Tier：存在频繁读写 DOM 的“thrashing”灾难级动画。

3. S-Tier：硬件加速动画策略
• 可在 compositor 线程执行的属性有 transform、opacity、filter、clip-path。
• 借助 CSS、Web Animations API（WAAPI）或 Motion 等库实现流畅动画。
• 滚动动画的性能优势源于滚动本身在 compositor 线程执行。
• “去优化”风险：Safari 等浏览器可能丢失硬件加速。
• GPU 图层（layer）太大易耗尽内存，滤镜（尤其是 blur）成本高昂。

4. A-Tier：主线程驱动的合成动画
• 动画触发合成层更新而非重绘，前提是元素已成为图层（如 will-change）。
• JS 动画库（如 GSAP）或 requestAnimationFrame 实现的动画多属此类。
• 利用 IntersectionObserver 可节省主线程资源并暂停不可见动画。
• 提及 Shader 动画性能超强但仍受主线程同步影响。

5. B-Tier：带有预处理的高效布局动画
• Motion 的 layout 动画使用 FLIP（First, Last, Invert, Play）技术，通过 transform 模拟尺寸变化，减少重排。
• 初始测量存在成本，但整体能显著优化动画流畅度。

6. C-Tier：触发重绘的动画与陷阱
• 改变颜色、圆角等属性触发 Paint，相比几何变化轻一些。
• 警惕 CSS 变量（CSS Variables）导致不可预测性能开销：尤其全局继承时全树样式重算。
• 优化策略：缩小变量作用域或用 @property 禁止继承。
• SVG 属性动画与 View Transition API 动画的性能权衡与实践改进。

7. D-Tier：布局驱动的高成本动画
• 改变 width、margin、grid-template-columns 等属性会引发重布局。
• 使用 position: absolute/fixed 或 contain CSS 属性可减少布局范围。

8. F-Tier：性能“地狱”——样式与布局 Thrashing
• 反复读写 DOM 尺寸（如 offsetWidth）导致强制同步布局。
• 建议通过批量化读写（如 Motion 的 frame API）避免 thrashing 问题。

9. 结论
• 动画性能优化不止是“黑魔法”，而是一门平衡内存、渲染步骤与硬件加速的艺术。
• 理解渲染管线可让开发者具备判断性能瓶颈的直觉，S 级动画不代表无代价，关键是为实际体验做正确取舍。

motion.dev

The Web Animation Performance Tier List - Motion Blog

Learn what makes web animations fast, slow, and everything in between with our 2025 web animation performance tier list.

AI 摘要：本文详细讲解了 CSS 中 position: sticky 的工作原理及常见失效原因。作者通过多个代码示例展示了粘性定位受容器尺寸、父元素溢出属性、Flex/Grid 对齐方式等多重因素影响的微妙机制，并结合实际开发经验提供了解决思路：理解“包含块”(containing block) 与 align-self 的行为是调试 sticky 效果的关键。文章最后提出通过合理设置元素尺寸与滚动策略，可以避免粘性元素“失灵”或“溢出”的问题。

1. 粘性定位基础与预期行为
• 简介 position: sticky 的作用：元素在滚动到指定位置后固定。
• 通过最简示例展示 sticky top-0 的典型效果。
• 提醒常见误区：overflow: hidden 会阻断粘性效果。

2. 当事情出错时：粘性元素尺寸与容器关系
• 若粘性元素高度超过滚动容器，粘性效果部分失效。
• 浏览器会强制展示完整内容，导致“脱粘”现象。
• 实战提示：检查粘性元素与滚动容器的尺寸匹配。

3. 失效原因二：粘性元素的包含上下文过小
• 引用 CSS 规范，解释“粘性视口矩形”(sticky view rectangle) 概念。
• 说明粘性约束受到父容器边界限制，不能“突破”祖先容器。
• 举例当粘性元素嵌套于非滚动父层时如何导致“无法粘住”。

4. Flex / Grid 子元素场景下的典型陷阱
• Flex 子元素默认 align-self: stretch 会撑满交叉轴，破坏粘性条件。
• 解法：将父级和粘性元素设为 self-start，避免强制拉伸。
• 讲解 Grid 布局中相同现象与对应修复思路。

5. 优化方案与进阶技巧
• 若导航面板内容过长，可通过 max-height + overflow: auto 实现内部滚动。
• 结合实际项目经验，推荐为容器加 padding 时考虑剩余高度计算。
• 通过 CSS 变量或逻辑视口单位（如 100dvh）提升布局稳定性。

6. 总结与思考
• position: sticky 核心原则：不能突破容器边界、必须在正确的滚动上下文中。
• align-self 和容器尺寸管理是让粘性布局正常工作的关键。
• 理解规范、调试实际场景，是掌握 sticky 行为的根本。

Frontend Masters

The Weird Parts of position: sticky;

Using position: sticky; is one of those CSS features that’s incredibly useful, seemingly simple, and also, frequently frustrating.

AI 摘要：这篇文章介绍了如何利用 SVG 的 pathLength 属性简化路径动画管理流程。作者先讲解一个常见的“签名动画”，传统方法需用 JavaScript 计算路径长度 (getTotalLength)，再展示通过手动设置 pathLength，可以让 CSS 动画以固定比例管理 stroke-dasharray 和 stroke-dashoffset，从而更直观地控制动画节奏，减少依赖 JS 的复杂度。

1. SVG 路径动画的常见方法
• 介绍一种常见的“签名动画”效果，用 stroke-dasharray 和 stroke-dashoffset 实现路径绘制。
• 讲解 stroke-dasharray 如何将路径“切割”为可见段与间隔。
• 通过调整 stroke-dashoffset 实现路径显现动画。

2. 路径总长度的计算与问题
• 在未指定 pathLength 前，需要从 JavaScript 中调用 getTotalLength() 获取路径总长度。
• 此过程为实现动画添加了额外步骤，且维护成本高。

3. pathLength 属性的妙用
• 介绍 pathLength 属性：可直接在 SVG 标签上定义路径的理论总长度。
• 设置 pathLength="100" 后，可以将动画参数基于此比例统一规划。
• 配合 CSS 的 transition，让路径动画以百分比方式更易管理。

4. 优化效果与开发体验
• 使用 pathLength 后的代码更简洁、可读性更强。
• 动画更容易调节且不需依赖 JavaScript。
• 作者总结自己对新方法的偏爱并鼓励读者试用。

Stefanjudis

pathLength makes makes SVG path animations easier to manage

Use the "pathLength` attribute to make animating "stroke-dasharray" and "stroke-dashoffset" easier.