AI 摘要：Google Chrome 的 Performance Extensibility API （性能扩展 API）允许开发者将自定义的性能标记（performance.mark）和测量（performance.measure）集成进 Chrome DevTools 的性能面板，使自有应用、团队代码与第三方包可实现更细粒度、结构化和可视化的性能剖析。文中不仅介绍 API 的最小可用实践和高级特性（如自定义 track、颜色、分组与元数据），还探讨了如何借助这些新能力更好地组织跨团队、跨模块或第三方依赖的性能数据，以提升前端调优的效率和可读性。

1. 背景与意义
• Google Chrome 推出的 Performance Extensibility API 能让开发者自定义性能分析数据，在 DevTools 性能面板中更清晰展现。
• 适用于关注特定应用片段性能、跨团队协作及 API/第三方包开发者等多类场景。

2. 现有能力回顾（性能.mark 与 .measure）
• 介绍 performance.mark() 与 performance.measure() 的基础用法，展示如何标记重要事件并测量阶段耗时。
• DevTools 能自动捕获这些标记，方便用时长和起止点可视化查看。

3. Extensibility API 的最小实现
• 启用 DevTools 新特性（Show custom tracks）。
• 使用 mark 时 dataType 必填，measure 时 track 必填，其他均为可选。
• mark 实现更明显的“标志”，但缺乏精确时间信息，偏向定位关注点而非精确计时。
• measure 则可直接建立自定义轨道，并展现分时区间。

4. 高级用法与增强能力
• 支持自定义颜色（限定调色板）、显示 toolTipText 与挂载元数据（properties）。
• measure 可作详细事件描述和元数据列举（例如资源加载性能拆解）。
• 所有扩展项 (color、tooltipText、properties) 均适用于 mark 与 measure，但 measure 的实用性更强。

5. track 与 trackGroup 的组织能力
• 支持创建自定义 track（如 CSS、JS、API）以区分不同事件流。
• 支持 trackGroup，将多个 track 归为一个分组（例如 First Party < CSS、JS>），适合团队协作及区分自有与第三方数据流。
• 实现方式简便，极大提升了跨团队、模块性能整理与溯源的效率。

6. 实践建议与最佳实践
• 推荐从最小实现用法入手，不建议对 mark 过度扩展。
• 优先使用 measure 进行自定义 track/trackGroup 的组织管理。
• 针对第三方库或框架，鼓励将自有 Instrumentation 移入单独 trackGroup，以提升定位和用例分析效率。

7. 附录：实用代码示例
• 提供结合 Resource Timing API 的实践 demo，展示如何自动获取和展示资源性能细节。

AI 摘要：本文深入介绍了 Web Components 中 Shadow DOM（影子 DOM）的原理和实际应用。作者不仅阐述了 Shadow DOM 在隔离 HTML 和 CSS、避免组件冲突中的重要性，也详细讲解了如何通过命令式和声明式方式创建 Shadow Root 以及相关配置（如克隆、序列化、焦点委托），并介绍了 slot（插槽）机制以实现内容分发。文章面向希望提升组件封装性、可维护性和安全性的前端开发者提供了清晰的实践指南。

1. Web Components 与 Shadow DOM 概述
• Web Components 由 Custom Elements（自定义元素）、HTML Templates（模板）和 Shadow DOM 等技术组成，三者可单独或组合使用。
• 传统 DOM 架构容易导致样式与脚本污染，难以维护。
• Shadow DOM 可实现 DOM、CSS、JS 的局部封装，提升组件独立性与安全性。

2. 为什么需要 Shadow DOM
• 现代应用常集成来自不同来源的组件，容易出现 ID 冲突与样式覆盖问题。
• 原生 HTML 元素如 video、details 等都标准使用 Shadow DOM 避免全局影响。

3. Shadow Root 的宿主元素与创建方式
• 多数 HTML 元素（如 div、section、span 等）均可作为 Shadow Root 宿主。
• 创建方式分为：
• 命令式（JavaScript）：attachShadow({mode})，可选择 open（开放）或 closed（私有）模式，建议默认使用 closed，以增强安全性。
• 声明式（HTML）：利用 <template shadowrootmode=""> 内嵌 shadow root，可和 Custom Elements 配合使用，支持 open/closed 模式。
• 讨论 open/closed 模式的脚本访问区别与安全考虑。

4. Shadow DOM 配置项
• clonable：允许带有 shadow root 的节点可被完整克隆（包括模板内容），提升组件复用性。
• serializable：能将 shadow root 内容序列化为字符串，便于缓存或跨节点注入，但需注意闭合模式下的数据泄露风险。
• delegatesFocus：启用后，宿主获得焦点时自动将焦点转移到 shadow root 内第一个可聚焦元素，常用于自定义表单组件，增强用户体验。

5. Slot（插槽）与内容分发
• 通过 slot，可实现宿主与 Shadow DOM 之间的内容插入与分发，支持默认与命名插槽，并可定义 fallback（回退）内容。
• slotchange 事件用于监听 slot 内容变化，便于实现响应式组件行为。
• slotted 内容仍属于 light DOM，可在文档级直接操作。

6. 实用建议与局限性
• 推荐以 closed-first 策略增强组件安全性，特殊场景下才使用 open。
• 注意表单与可访问性（ARIA）相关的局限，部分需要借助 ElementInternals 等新 API 进一步处理。

AI 摘要：本文由 Makito 首次在 Project AIRI 的 DevLog 分享，聚焦于如何在前端应用中处理和实现流式 UTF-8 字节流的文本动画，尤其是在聊天或语音转写等实时场景下正确分割和显示「字素簇」（grapheme cluster）。作者深入探讨了 Unicode 编码、多码点合成字符的边界难题，以及利用 Web API，如 TextDecoder、Intl.Segmenter，实现安全高效的字素簇流式提取，并介绍了自己的开源库 Clustr。文章结合了丰富的实例和交互组件，面向希望在项目中实现高质量文本动画及多语言兼容的前端开发者，具有较高参考价值。

1. 背景与动机
• 投稿者首次在 DevLog 发文，介绍参与 Project AIRI 过程。
• 动画文本在现代 UI（如聊天消息）中的作用和实现难点。
• 第三方库（Anime.js, splt, GSAP）在文本动画实现上的进展与现有不足。
• 项目的需求：需实时处理和动画化接收自 UTF-8 字节流的数据。

2. Unicode 基础与「字素簇」难题
• 码点（Code point）与 UTF-8 字节流的对应关系，字节组装所需注意事项。
• Unicode「字素簇」的定义，即多个码点合为视觉整体的最小文本单元。
• 通过实际 Emoji 和南亚文字示例，阐释组合字符的裸数据和视觉表现。
• 传统 Web API 如 TextDecoder 能将字节流还原为码点字符，但不足以分割复杂字素簇。

3. Web API 应用与完善方案
• 利用 TextDecoder.decode（stream选项）实现流式解码，拼接字符串缓冲区。
• 使用 Intl.Segmenter 拆分字符串为字素簇，支持多语言处理。
• 提出解决方案：因为流数据随时变化，需确保不完整的字素簇不被导出，因而采用「丢弃最后一个」策略缓冲输出，避免合成字符的过早显示。

4. 流式字素簇库 Clustr 的诞生
• 市场调研发现缺乏专门处理流式 UTF-8 字节流并输出字素簇的库。
• 作者自研 Clustr，核心代码不到100行，实现了上述需求。
• Clustr 能帮助前端实时渲染流式文本动画，兼容多语言复杂字符。

5. 互动组件与社区交流
• 提供探索字素簇组合和实时代码交互的小组件。
• 鼓励开发者参与 Project AIRI 相关 GitHub 仓库，共同讨论和改进工具。

AI 摘要：本期 Frontend Focus 报道了前端领域的最新动态和趋势，涵盖 CSS 新规范（如无 JavaScript 的走马灯、Masonry 布局、Scroll-Spy）、React/Next.js 开发中的常见陷阱、MDN 发展二十周年纪念，以及一批最新实用工具和开发资源。此外，简要提及了 Safari/Edge 等主流浏览器新特性和业界法规、社区大事件，适合前端开发者了解行业资讯和提升技术能力。

1. 前端社区动态与大事件
• MDN 文档网站庆祝成立 20 周年，目前拥有超 14,000 页内容，是 Web 开发的重要资料库
• 2025 Stack Overflow 开发者调查结果公布，涵盖开发工具、AI 代理、LLM 使用现状等
• W3C 发布关于组织使命与价值观的重要新文档
• HTML Day 活动将举办超 40 场全球盛会，HTML 技术持续推进
• Wikimedia 积极挑战英国在线安全法案，关注数字法规生态

2. CSS 新特性与最佳实践
• CSS Masonry 布局：探讨新规范进展与当前解决方案，兼顾未来性与可用性，附带交互反馈征集
• CSS Scroll-Spy ：Chrome 140 浏览器引入 scroll-target-group 和:target-current，可用两行 CSS 实现目录高亮跟踪效果
•  Responsive Video is (Almost) Easy Now：如何处理垂直和横向视频以适应不同场景，在上下文需要时提供垂直和水平版本。
• “现代 CSS 杀死 SPA”观点：提倡服务器渲染与页面级动画，倡导 CSS 动画和意图性预加载

3. Web 技术深度/创新话题
• The Useless useCallback：React 状态管理与性能相关实践讨论，分析 useCallback、useMemo 潜在问题，展望 React Compiler 与 useEffectEvent 等新工具的改善能力。
• Performance Extensibility API：允许自定义轨迹供 Chrome DevTools 性能面板分析
• WebAssembly（WASM）与 DOM 互操作性进展，工具链提升正降低 WASM 开发门槛
• Liquid Glass ：苹果新一代视觉样式的网页实现尝试
• Web Components 及 Shadow DOM 实践解析

4. 工具、组件与资源推荐
• World Clock Slider：多城市世界时钟组件，支持暗黑模式
• FossFLOW：等距基础架构图形工具，支持丰富图标与数据管理 【这个挺酷炫的】
• StaticSearch：为静态站点增添搜索，无需后端，基于 Javascript，数据存储为 JSON
• Oklchroma：基于 OKLCH 色彩空间的色板生成器，提供基色，使用三角函数生成不同色阶
• difit：使用 GitHub 风格查看器查看和审查本地 git 差异的 CLI 工具，评论还可以作为 AI 提示进行复制。
• 7.css：忠实还原经典 Windows 7/XP UI 的 CSS 设计系统
• 使用 Three.js、WebGPU 和 TSL 进行交互式文本销毁

AI 摘要：本文章批判了将 SPA（单页应用，Single Page Application）作为优先方案的潮流，指出随着现代 CSS 和浏览器（如 View Transitions API、Speculation Rules 等）的进步，实现流畅、原生的页面交互已不再需要复杂的 JS 框架和大量前端代码。作者呼吁开发者回归标准的 HTML + CSS + 浏览器原生能力，构建更快速、可维护、SEO 友好的网站，并强调 SPA 带来的复杂性、性能损耗、可访问性问题，以及与浏览器发展脱节的弊端。

1. “类应用”迷思与 SPA 的错误假设
• 许多项目由于“要像 app 一样流畅”的陈旧要求选择了 SPA 架构，而忽略了是否真的需要。
• 选择 SPA 并非出于真正的技术需求，而是为交互流畅度妥协了架构简洁性。
• 现在的假设已过时，SPA 不再是唯一可实现流畅体验的方法。

2. SPA 的“伪流畅”与性能危害
• SPA 的“无刷新感”常常是假象，实际表现为加载动画、滚动错乱、路由行为不一致等问题。
• 大量 JavaScript 的引入导致性能下降，SEO 变得复杂，体验反而变差。
• 现代 SPA 阈值带来的技术负担，不成比例的为“流畅度”买单。

3. 现代 Web 平台演进（CSS 与浏览器原生特性）
• 浏览器原生已支持声明式页面过渡（View Transitions API），无需 JS 也能实现淡入淡出动画等高级体验。
• 结合 Speculation Rules（预测性预加载），可实现点击即开的导航体验，无需 JS 路由。
• 原生 MPA（多页面应用，Multi-page Application）方案能够通过 CSS 动画实现元素过渡、状态保存、URL 正确性等。
• 示例代码简明说明如何用 CSS 实现页面转场与共享元素动画。

4. 浏览器赋能与简单架构的优势
• 现代浏览器提供诸如 Back/Forward Cache（前进后退缓存）等特性，只要结构易读、无 JS 路由劫持即可天然获得极佳体验。
• 浏览器愿意协助性能优化，但前提是开发者不要人为增加复杂度。

5. 性能现实对比：SPA vs 现代 MPA
• 真实 SPA（如 Next.js 等）JS 体积大，加载慢，SEO 和导航表现不稳定。
• MPA + View Transitions + Speculation Rules 几乎无需 JS，加载极快，自然支持 SEO 和历史管理。
• 原生方法不仅替代 SPA 行为，而且性能和可维护性更佳。

6. 反思：“网站不是 APP”
• 普通网站无需 SPA 的状态管理、复杂路由、大量组件或 hydration。
• 使用过度的 JS 反而增加了网站开发、运维成本和用户负担。
• 理性选择开发手段，应“用网站的方式造网站”，拥抱标准技术栈。

7. 展望与建议：用现代 web 技术构建网站
• 原生 declarative transition（声明式过渡）、预渲染、降级兼容性、易维护架构等已足以满足绝大多数场景。
• SPA 是旧时代局限下的策略，如今实属多余。
• 建议开发者用现代服务端渲染和单纯 HTML + CSS 构建主站，只在必要时合理由加 JS 增强。

本文总结了 ViteLand 生态系统在 2025 年 7 月的主要动态，包括 Vite、Vitest、Oxc、Rolldown 等关键项目的最新进展，以及社区即将举办的线下盛会 ViteConf 的首场线下会议预告。Vite 团队将发布全新产品 Vite+，并聚焦前端开发领域的未来趋势。文章还预告了 Vite 纪录片的上线情况，为开发者提供了丰富的行业洞察和社区信息。

1. 生态系统进展
• 概述了 Vite、Vitest、Oxc、Rolldown 等项目在本月取得的主要更新和迭代。
• 着重强调了团队在提升开发者体验（DX, Developer Experience）方面的持续努力。

2. ViteConf 线下大会预告
• 预告 10 月将在阿姆斯特丹举行的首届线下 ViteConf，此前已有三届线上大会成功举办。
• 届时将首次发布 Vite+，介绍其功能和对团队工作流的提升作用。
• 大会将邀请知名演讲嘉宾，包括 Bolt.new/StackBlitz CEO Eric Simons 和 Netlify CEO Mathias Biilmann。
• 会议主题将围绕下一代开发工具（next-generation tooling）、智能 agent 体验等前端领域热点展开。

3. 社区与纪录片
• 宣布由 CultRepo 出品的 Vite 纪录片即将在活动中全球首映，展示 Vite 团队及 Svelte、Solid、Astro 等明星项目作者的未公开故事。
• 官方预告片已发布，可供提前观看，进一步增强社区凝聚力。

AI 摘要：本文深入探讨了前端开发中主题和颜色命名的设计实践及困惑，从流行 CSS 框架的色板设计现状、手动与程序化生成色板的方法谈起，剖析了颜色变量定义中的“语义命名”混乱，并提出了更灵活与语义化兼容的命名及管理方式，以支持更加多变且有辨识度的 Web 设计系统。

AI 摘要：本文介绍了如何用现代 CSS 新特性（如 shape(), sibling-count(), sibling-index() 等）实现一个无限循环的简洁 Marquee（走马灯）动画，无需 JavaScript，并能自动适配任意数量、任意宽度的图片或元素。作者详细讲解了这一方案相比传统方法（如 <marquee> 或元素克隆）在性能、可维护性和响应式设计上的优势，并提供了完整、紧凑的 CSS 代码实例。相比以往需要繁琐计算或操作 DOM，此方法仅需 10 行 CSS 即可实现高效且灵活的无限轮播动画，同时分析了 shape() 函数的基本用法及其带来的灵活性。

AI 摘要：这篇博文深入探讨如何在纯 CSS 中获取 grid 布局中 auto-fit/auto-fill 自动列的列数，从而实现如高亮首/末列、斑马纹、响应式非矩形网格等复杂交互，无需任何 JavaScript 或媒体查询（breakpoints）。作者提出了通过 container query 单位、CSS 变量和数学函数自动计算列数的方法，并针对不同浏览器支持和 bug（尤其是 Firefox）提出了解决方案，使技巧能够跨浏览器使用。

AI 摘要：Chrome 139 带来了多项面向开发者的重要新功能，包括本地 Web Speech API（语音识别）、CSS corner shaping（角样式）、CSS custom functions（自定义函数）等，进一步提升了 Web 应用的性能、安全性和界面设计能力。本文亮点简要梳理了此次版本中的主要更新和对开发者生态的影响。

1. 本地 Web 语音识别（Web Speech API）
• Web Speech API 现支持在本地进行语音识别，无需将音频数据上传至第三方服务，提升了隐私和安全性。
• 开发者可以检测本地语音识别能力、提示用户安装相关资源，并按需选择本地或云端识别方案。
• 有助于为多语言和对隐私敏感的场景提供更优支持。

2. CSS 角样式（CSS corner shaping）
• 新增 CSS 属性允许开发者自定义角的形状与曲度，超越传统的 border-radius。
• 支持创建如 squircles（圆角矩形）、notches（凹口）、scoops（挖口）等更为丰富的视觉样式，并可实现动画切换。
• 拓宽了 Web 设计在 UI 形状表现上的空间。

3. CSS 自定义函数（CSS custom functions）
• 引入 @function 规则，使开发者可像自定义属性一样定义函数，实现基于参数、条件的动态样式生成。
• 支持函数内调用变量，显著增强了 CSS 的可复用性与逻辑性，推动 CSS 向编程化发展。
• 这一特性属于 CSS Custom Functions and Mixins（函数与混入）规范的一部分。

4. 其他新特性与改进
• web app manifest 新增 scope_extensions 字段，方便多子域、多顶级域的站点整合作为单一应用呈现。
• Chrome 现在识别 WHATWG mimesniff 规范中定义的所有有效 JSON MIME 类型，提升兼容性。
• request-close 调用已集成至声明式 invoker commands API，优化 JavaScript 的事件处理模型。

AI 摘要：作者系统性批判当代 Web 前端栈：DOM 与 HTML 停滞且臃肿、CSS 默认“自内向外”的布局心智与现代应用需求脱节，SVG 与 CSS 相互羡慕却难以统一；“HTML in Canvas”方向治标不治本。作者主张打开更低层的布局、文本与渲染原语，重构视图树与渲染树，以更小更清晰的数据模型拥抱多线程、多来源与异步的新时代，WebGPU 等新基建可成为更简洁的 UI 基元。

1. DOM/HTML 的困境与技术债
• DOM 膨胀失控：仅 Chrome 的 document.body 就有 350+ 键，style 内还有 660 个 CSS 属性；属性/方法边界模糊，部分 getter 触发布局抖动，遗留 onevent 成堆。
• 字符串类型负担：源自 SGML/XML 的“stringly typed”设计让 Web Components 等原生组件 API 笨重，Shadow DOM 引入额外嵌套/作用域，生态接受度低。
• 语义 HTML 的失约：十多年无实质演进，ARIA 兜底本应由语义标签承担的职责；常见结构（如 thread/comment）缺位，WHATWG 更多是边角“本轮加一圈”而非愿景驱动。
• 可编辑性鸡肋：contentEditable 实用化困难重重，富文本编辑器团队“血泪史”常谈。
• 应用现实的“拼装学”：为了做应用 UI，团队被迫以 HTML/CSS/SVG 套娃，承担滚动吸底、虚拟化列表/表格、右键菜单、查找等重复造轮子；UI 与“流式内容”的早期融合如今反成负担。

2. CSS 的本质：自外向内 vs 自内向外
• 正确心智模型：CSS 本质是“两次约束传播”——先自外向内分配可用空间，再自内向外回收实际尺寸；默认是文档导向的“自内向外”，需要手动从 body{height: 100%} 开始把约束往下传，所以“垂直对齐难”并非错觉。
• Flex 的代价与补药：Flex 通过测“自然尺寸”再伸缩，导致递归式“猜测布局”；深度嵌套和未知内容可能引发不可预期放大。可用 contain: size、明确 flex-basis、will-change 等打断全局约束，避免连锁反应。
• API 设计反思：理想的布局系统应把“容器行为”（自外向内）与“放置模型”（自内向外）作为可组合的正交维度提供，而非在单一语法下不断加“抑制/隔离”开关。

3. “好部分”与跨模型错配
• 可用但不优雅：Flexbox、Grid 在理解边界条件后“够用”，但语法“很 CSS”；若从零设计，不会做成今天这种减法式 API。
• 两种系统被硬绑：CSS 同时承担“文本样式的继承系统”和“盒模型布局系统”，前者需继承（如字体），后者主要是包含关系，级联语义不一致，合在一起是历史事故。
• 单位与像素：相对 em 的早期理念已式微，逻辑像素 vs 设备像素更符合用户预期。
• 与 SVG 的“互相羡慕”：SVG 既非 CSS 子集也非超集，变换模型等细节不同；CSS 想要曲线、遮罩、渐变、滤镜，却远不如 SVG 强；开发者在 HTML/CSS 与 SVG 间反复取舍。
• 三个“卡点范例”：
• 文本省略号 text-ellipsis 仅能裁单行不换行文本，段落裁切/检测截断与文本测量 API 皆孱弱。
• 粘性定位 position: sticky 想实现“无条件吸附”需多层荒诞嵌套，本应易如反掌。
• z-index 战争：绝对层级导致“+1/-1 拼数值”，缺少相对 Z 定位的语义。

4. “HTML in Canvas”的误区
• 设计目标错位：为“可编程渲染”而把 HTML 绘进 canvas，结果依旧被 DOM 裹挟（需作为 <canvas> 子树参与布局/样式/无障碍），离真正的可编程 UI 还很远。
• 交互负担转嫁：为了自定义外观，被迫全权接管命中测试 (hit-testing) 与事件，且仅有 2D 命中测试；在已有 CSS 3D 变换环境下显得荒诞。
• Reactivity 风险：让 canvas 回写/观察同一文档树，带来循环依赖与观察者复杂度。
• 文本与字体的“原罪”：Canvas 缺少系统字体、文本布局 API、Unicode 分词/换行等基础能力——真正的难题没有开放正确的底层原语。
• 本质诉求：不是“把 DOM 截图画出来”，而是要打开文本测量、命中测试、可编程布局、统一滤镜/着色器等低层 API；用 DOM 当黑盒无法解决 1990 年代 UI 水平的缺口。

5. 向下开口：重塑视图树与渲染树
• 方向样例：Use.GPU 的“类 HTML 渲染器”在 WebGPU 上实现 X/Y Flex，垂直居中与定位直观，无语义 HTML 或级联，仅“一级公民”的布局；给“div”挂着色器，90% DOM 功能以少量清晰原语重做可达。
• 核心问题重问：视图树应长什么样？如何降解成渲染树？当下是如何被“历史包袱”强行降解的？
• 新引擎机会：Servo、Ladybird 等新浏览器实现轻装上阵，更适合提出新提案；大厂亦可为之，但“品味与自小做起”的工程哲学重要。
• 进程/线程与安全现实：因 Spectre 等 CPU 攻击，SharedArrayBuffer 与 Web Worker 的多线程之路受阻；DOM 若重塑，可与多进程、跨来源隔离、结构化并发、所有权语义、函数式效果 (FP effects) 等现代模型同频共振。
• 最小第一步：以更小更干净的数据模型替换当前“每节点 350+ 属性”的怪物；别误以为问题不可解，关键在于抽丝剥茧、回到正确的内核抽象。

AI 摘要仅供参考和导读和索引，其中可能有失实部分，推荐自行阅读原文。

AI 摘要：本文详细介绍了如何利用新兴的 CSS 滚动驱动动画技术，以纯 CSS 的方式重新实现经典的视差滚动 (Parallax) 效果。与传统的 JavaScript 方案相比，这种新方法将动画移出主线程运行，从而显著提升了性能和流畅度。文章通过实例讲解了 animation-timeline 属性的两种核心时间轴函数 scroll() 和 view() 的使用场景与区别，并进一步介绍了如何使用 animation-range 属性精确控制动画的触发时机与范围，最后还探讨了针对运动敏感用户的无障碍设计和浏览器兼容性的回退方案。

AI 摘要：Chrome 140 Beta 版为 Web 开发者带来了一系列重要更新。在 CSS 与界面方面，新增了类型化算术 (Typed Arithmetic) 以增强 calc() 的能力，引入了 scroll-target-group 属性改进滚动导航，并对视图过渡 (View Transition) 进行了多项功能增强。Web API 方面，提供了 Uint8Array 与 Base64/十六进制的内建转换方法，并通过权限提示限制本地网络访问以提升安全性。此外，还为独立式 Web 应用 (IWA) 引入了 Controlled Frame API，并开启了 clipboardchange 事件、来电通知等新的源试验 (Origin Trial)。此版本也为提升无障碍性而弃用了一些历史性的 <h1> 字号规则。

1. CSS 类型化算术 (Typed Arithmetic)：允许在 calc() 函数中进行带单位的数学运算，如 calc(10em / 1px)，方便排版和单位转换。
2. 滚动与视图增强：scroll-target-group 属性：用于定义滚动标记组容器，配合 :target-current 伪类可高亮当前视图内的目标锚点。
3. ScrollIntoView 容器选项：新增 container: 'nearest' 选项，可仅滚动最近的祖先滚动容器。
4. 视图过渡 (View Transition) 增强：伪类可继承更多动画属性，并支持嵌套视图过渡，以实现更复杂的过渡效果。
5. overscroll-behavior 传播修复：该属性现在从根元素 (<html>) 而非 <body> 传播，与其他浏览器行为保持一致。
6. 排版与无障碍性：在 content 属性的替代文本中支持 counter() 和 counters() ；支持在 @font-face 规则中使用 font-variation-settings 描述符。弃用 <h1> 元素在特定容器内的特殊字号规则
7. API 与交互改进：caret-animation 属性允许开发者手动控制光标动画，避免与默认闪烁行为冲突；highlightsFromPoint API 允许通过坐标点检测自定义高亮区域；ToggleEvent 新增 source 属性，可获取触发该事件的源元素；修复 SVG foreignObject 污染画布 (Canvas) 的问题，使其在使用 blob 网址时行为与其他浏览器一致。

AI 摘要：本文为前端开发者提供了一份全面的 CSS 面试准备指南，精选了 10 个从易到难的典型面试题。文章不仅给出了每个问题的建议回答方向和代码示例，还深入探讨了其背后的核心概念，内容涵盖响应式设计、CSS 预处理器、性能优化、现代布局技术以及 CSS-in-JS 等关键知识点，旨在帮助求职者系统性地巩固 CSS 技能，并自信地应对技术面试。

AI 摘要：本文以头像菜单为例，系统介绍了锚点定位（Anchor Positioning）如何让元素基于另一元素进行纯 CSS 定位，涵盖锚点与目标的关联（anchor-name、position-anchor、position），两种定位思维模型：基于九宫格的 position-area 与基于边缘的 anchor()（仅用于 inset 系列），并演示了使用逻辑方向、溢出切换（position-try）与 calc() 的实战技巧，帮助开发者在无需 JavaScript 的情况下实现响应式菜单、气泡与工具提示。

1. 基本概念与关联关系
• 角色定义：被依附的元素为锚点（anchor），需要定位的元素为目标（target）。
• 建立关联：在锚点上声明 anchor-name（如 --profile-button），在目标上使用 position-anchor 指向该锚点名。
• 定位前置：目标需设置 position: absolute 或 fixed 才能启用锚点定位。

2. position-area：基于九宫格的定位模型
• 九宫格心智模型：以锚点为中心，在其包含块（containing block）上选定九宫格中的区域放置目标。
• 优先使用逻辑方向：以 block-start/block-end、inline-start/inline-end 与 center 取代物理方向（top/right/bottom/left），以适配不同书写模式与语言。
• 对齐与溢出：当目标比锚点宽时，使用 block-end span-inline-end 可实现“下方左对齐且向行尾延展”；类似地，可用 block-end center、block-start inline-end 等组合控制位置。
• 响应式回退：通过 position-try 指定备选位置，当首选位置空间不足时自动切换（如窄屏从向右溢出改为向左溢出）。

3. anchor()：基于边缘的精确定位
• 使用范围：仅可用于 inset 系列属性（物理：top/right/bottom/left；逻辑：inset-block-start/end、inset-inline-start/end；以及 inset-block、inset-inline 简写）。
• 边缘对齐：例如让菜单左边与头像左边对齐、菜单顶与头像底对齐，可写为 left: anchor(left), top: anchor(bottom)；逻辑等价为 inset-inline-start: anchor(start), inset-block-start: anchor(end)。
• 指定锚点：anchor() 可接收可选的锚点名（如 anchor(--profile-button left)），默认使用 position-anchor 指定的锚点。
• 配合 calc()：可将 anchor() 与 calc() 组合做细粒度偏移（如对齐去除内边距影响：inset-inline-start: calc(anchor(start) + 1.25em)）。

4. 实战场景与模式选择
• 导航头像菜单：点击头像（可结合 Popover API）后，菜单基于头像精准定位且纯 CSS 控制。
• 桌面与移动自适应：桌面可向 inline-end 溢出，移动端通过 position-try 切换为 inline-start 溢出，减少遮挡与视口溢出。
• 心智模型选型：喜欢“区域网格”可用 position-area；偏好“边缘数值”可用 anchor()。两者都能完成相同目标。

5. 规范与资源指引
• 推荐实践：优先使用逻辑属性与方向，增强无障碍与国际化适配；目标元素需 absolute/fixed 定位。
• 学习与实验：文中提供了 CodePen 示例用于自由尝试；更多详细属性与值可参阅 MDN 文档；还有教学游戏 Anchoreum。
• 反馈与社区：作者与 WebKit 福音师在 BlueSky/Mastodon 等渠道互动；遇到问题可提交 WebKit Bug 报告。

AI 摘要：这是一篇 PostCSS 12 年演进的复盘：从 Autoprefixer 的诞生到 PostCSS 成为被 Google、Wikipedia、Tailwind 等采用、月下载量 4 亿的开源基础设施。作者围绕产品定位、插件策略、性能架构、版本演进、社区与生态、与竞品相处以及维护者防止倦怠的实践，给出一套贯穿前端工具链建设与开源运营的可复用方法论：以用户可用为先、以架构赢性能、以默认值减少配置、以人情味促协作、以渐进式变更稳生态。

1. 历史与定位：从 Autoprefixer 到 PostCSS
• 痛点出发：不想手写厂商前缀，于是做了 Autoprefixer，并需要一个更强的 CSS 解析器与 API（应用程序接口）。
• 启发与决策：Rework 无法满足“保留原始空白”等需求，遂自研 PostCSS；教训“−1”：对大用户更合作，给原项目提交原型的机会。
• 推广与文档同等重要：投入与写代码相当的时间做 README 与对外沟通，主动向 Webpack 推荐用 PostCSS 做解析器，带来关键增长。
• 定位转变：原打算做“幕后”框架，但终端用户对新工具敏感、对插件友好，因此把 PostCSS 做成对用户可见的“插件平台”，帮助新 CSS 工具降低接入阻力。

2. 产品形态与插件策略（Lesson 1）
• 默认可用优于“纯插件”：PostCSS 默认“无作为”导致用户被插件选择淹没；对比 Lightning CSS 内置常用能力与 Vite 的“开箱即用”，体现“约定优于配置”。
• 插件架构的收益：小内核易维护；拆分团队各司其职；利于做 CSS 工具实验（如 easing 渐变转为 CSSWG 草案）；满足项目定制；开发工具需要灵活性。

3. 时机与竞争：不怕“来得晚”，要快验真（Lesson 2、Lesson 7）
• “太晚”的误判：Chrome 停增前缀与 CSS Houdini 的宣布，都未让 Autoprefixer 与 PostCSS 失去价值；实际落地速度与有效性才是市场检验。
• 行动原则：尽快做原型、看真实结果，不被“新技术将取代一切”的叙事带偏。
• 与“竞品”为友：与 Sass 协作、统一术语与基准；公开推荐 CSSTree、Lightning CSS 等新工具；在开源中，“竞争者”可以分担你的免费支持压力。

4. 性能与架构：架构比语言更重要（Lesson 3）
• 关键洞见：PostCSS 用 JS（JavaScript）比 C++ 的 Sass 快 4 倍，原因在于架构与内存管理，而非语言本身。
• 架构实践：采用令牌化-解析器（tokenizer-parser）拆分，80% 解析时间在令牌化，便于聚焦优化；用正则快速跳转定位结束符等微优化。
• 内存优化：CSSTree 通过对象复用减少垃圾回收（GC）次数，曾快于 PostCSS ≈1.5 倍；避免“Rust/C++ 一定更快”的二元迷思。

5. 维护者健康：防止问题复发，避免倦怠（Lesson 4）
• 问题“闭环”：用户误用导致的 issue，要加类型与运行时校验、警告与文档澄清，防止重复踩坑；文档常是最后手段，但 FAQ 有效减压。
• 实例：用户把 parser 当插件使用，直接在代码里给出警告信息，显著降低重复问题。
• 反内耗机制：尽快响应、邀请提问者补文档或提修复 PR；开源是协作，不是单向免费支持。被忽视的感觉才是用户最大挫败。

6. 版本演进与迁移策略（Lesson 5）
• “跳-合”节奏：首个大版本标记废弃，下一个大版本再移除；尽量提供迁移指南（如 PostCSS 8），并维护生态迁移进度 Wiki。
• 重大变更前置沟通：提前发布变更提案、开反馈通道，协调 Webpack、Vite 等生态构件的配合升级。

7. 塑形生态：用最佳实践驱动一致性（Lesson 6）
• 统一模板与规范：插件脚手架强制“输入/输出”示例，制定插件与运行器指南；文档示例会塑造社区习惯。
• 学习路径清晰化：提供从零到一的分步指南，甚至涵盖“如何对抗开发挫败”的内容。

8. 社区运营与人情味（Lesson 8）
• 人的纽带：给插件作者寄明信片/贴纸、出差拜访活跃贡献者，建立真实连接。
• 品牌风格：Autoprefixer 的“骑士”与 PostCSS 的“炼金术”主题，让项目更有趣、更易形成文化认同。

9. 开源维护小贴士
• 尽量无构建：库用原生 JS 源码配合手写 .d.ts 或 TypeDoc，方便直接安装分支测试与 node_modules 内即时调试复制。
• 静态站点别用 React：项目文档与官网用 Astro 或纯静态 HTML，维护成本更低、更稳。

你知道你现在可以在 CSS 使用 height: stretch 吗？也适用于 width。

AI 摘要：本文介绍了 CSS attr() 函数的进阶用法，包括通过类型声明（如 <color>、<length>）将 HTML 属性值动态应用于网格布局、颜色和字体大小等场景，并提供了实际代码示例和设计系统中的应用思路。目前该功能仅在 Chrome 中支持，但未来将逐步普及。

1. 功能概述与背景
• 历史限制：传统 attr() 仅返回字符串，仅适用于 content 属性等简单场景。
• 新特性：现在可通过类型声明（如 type(<length>)）将属性值解析为数字、颜色等，扩展了应用范围。
• 兼容性：目前仅 Chrome 支持，但其他浏览器将跟进（参考 Can I Use）。

2. 核心用法示例
• 基础语法：

attr(data-font-size type(<length>));
attr(data-color type(<color>), black);

• 支持的类型：包括 <color>、<integer>、<length-percentage> 等 11 种 CSS 数据类型。

3. 实际应用场景
• 网格控制：通过 data-columns 设置元素跨越的列数，或 data-column-start 定义起始位置。
• 动态颜色：结合 color-mix() 或 oklch() 调整亮度，确保可读性（如 max(l, 0.9)）。
• 字体大小：使用 round() 限制字号为设计系统的固定增量（如 5px 倍数）。

4. 扩展思路与其他用途
• 设计系统工具：如 data-gap 控制间距，或 data-border 定义边框样式。
• 层叠传递：通过自定义属性（如 --button-color: attr(...)）向子元素传递值。
• 命名空间建议：推荐使用 data-* 前缀避免与未来标准冲突，并兼容 dataset API。

5. 参考资料与社区动态
• 推荐阅读：Una Kravets、Bramus Van Damme 的相关文章。
• MDN 文档 已更新新特性说明。

AI 摘要：这篇文章深入探讨了 SVG 的 <path> 元素，详细介绍了如何使用该元素绘制各种形状，尤其是 Bézier 曲线和弧形。文章通过示例和解释帮助读者建立对路径语法的直观理解，适合希望提升其 SVG 绘图技能的开发者。

1. 基本概念
• SVG <path> 元素类似于矢量图形软件中的“笔”工具，可以连接多个绘图指令。
• d 属性定义了一系列绘图指令，每个指令通过不同的命令（如 M、L）来实现。

2. 基本命令
• 移动命令 (M)**：用于将笔移动到画布的特定位置，不会绘制任何线条。
• 直线命令 (L)：用于绘制从当前点到指定点的直线。
• **Bézier 曲线: 包括二次 (Q) 和三次 (C) Bézier 曲线，分别使用一个和两个控制点绘制平滑曲线。

3. 弧形 (Arcs)
• 弧的复杂性：弧的绘制涉及到多个参数，掌握其用途对于理解如何连线至关重要。
• 半径控制：水平和垂直半径影响着绘制的椭圆形状的深度和外观。
• 弧形路径选择：通过大弧标志和扫掠标志选择路径方向。

4. 动画与额外功能
• 提到了动画技术的学习课程，并介绍了路径闭合命令 (Z) 和相对命令 (小写字母形式)。
• 文章总结了一些常用的命令和其语法，帮助开发者更轻松地创建复杂的 SVG 图形。