#优质博文 #CSS #前端 #坑
sticky 踩坑大全（
The Weird Parts of position: sticky

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

[以下是方便搜索索引的大纲(AI 生成)，请读原文]

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 行为的根本。

author Chris Coyier

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.

#优质博文 #CSS #SVG #前端 #course #动画
pathLength 属性可以直接在 SVG 标签上定义路径的理论总长度
pathLength makes makes SVG path animations easier to manage

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

[以下是方便搜索索引的大纲(AI 生成)，请读原文]

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。
• 作者总结自己对新方法的偏爱并鼓励读者试用。

author Stefan Judis

Stefanjudis

pathLength makes makes SVG path animations easier to manage

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

#优质博文 #浏览器 #Chrome #前端 #新动态
前阵子就看到了这消息，不过今天再发一遍。
Chrome supports split views (behind a flag)：Chrome 也终于能左右分屏啦，打开实验性功能 chrome://flags#side-by-side 就能体验新功能。

Stefanjudis

Chrome supports split views (behind a flag)

Turn on the experimental tab split views via a Chrome flag.

#优质博文 #开发流程 #Git #工程化 #开源
其实是之前的看到的文章里看到的，觉得有用，Mark 一下。
The stacking workflow

AI 摘要：本文介绍了一种名为 “Stacking” 的开发工作流，用于优化传统的 Git 分支与代码评审流程。它通过将大型改动拆分为多个相互依赖的、小而独立的 PR，实现并行开发与评审，显著减少等待时间与合并冲突。文章还提及多种自动化工具，可帮助开发者轻松管理 Stacked PRs，从而在团队协作中显著提高代码质量与生产效率。

[以下是方便搜索索引的大纲(AI 生成)，请读原文]

1. 开发与评审的痛点
• 传统代码评审流程耗时长，对开发者与评审者都是负担。
• 分布式团队受时区影响，沟通与迭代周期延长。
• 在等待评审期间，作者被迫停滞，影响特性迭代与开发效率。

2. 为什么需要 Stacking
• Stacking 将开发和评审流程并行化，可在上一个 PR 尚未合并前继续开发下一步工作。
• 通过拆分大型改动为多个小型、依赖性的 PR，减少复杂度，使每次评审更聚焦。
• 改动间的依赖关系清晰，能更安全地选择性合并各 PR，保持项目演进的灵活性。

3. 手动 Stacking 的困难
• 每个分支都需递归 rebase（再基化），遇上上游改动时需层层同步，极为繁琐。
• Git 原生命令行（CLI）对该流程支持有限，手动处理冲突成本高，容易出错。

4. 支持 Stacking 的工具生态
• GitHub 集成方案：具有 CLI、VS Code 插件与 Web UI，可同步管理栈式 PR。
• 开源 CLI 工具：如 ghstack、git-branchless 等，提供抽象化的 stack 操作流程。
• Meta 的新版本控制系统含原生 Stacking 支持。
• Git 新选项 --update-refs 为 stacking 流程带来更多便利。

5. 采用 Stacking 的价值
• 推动开发者以更模块化的思维进行编码，提升代码可读性与长期可维护性。
• 有助于团队快速理解、学习或回滚更改。
• 不论语言、架构、仓库结构（polyrepo/monorepo），Stacking 均可适用。
• 一旦熟悉该模式，多数开发者会主动维护 5–10 个 PR 栈，形成高效的持续开发节奏。

www.stacking.dev

The stacking workflow

Stacked PRs. Stacked diffs. Stacked changes. A better workflow to manage pull requests.

#优质博文 #AI #生产力
很好的 AI 辅助开发实践总结，安利了 OpenSpec 感觉挺不错的～
OpenSpec 使用心得

AI 摘要：本文记录了作者在 AI 辅助开发中的经验演进，从早期的代码补全，到通过 OpenSpec 实现规范驱动的团队协作。OpenSpec 以“提案 + 规范”的模式，把每一次改动都变成可追溯的结构化流程，AI 不再仅是执行命令的工具，而能成为能理解上下文、可协作的开发伙伴。作者通过完整示例展示了 OpenSpec 的安装、初始化、提案、审阅与归档过程，强调“规范文件”才是项目的核心资产。

[以下是方便搜索索引的大纲(AI 生成)，请读原文]

1. AI 工具有机演进
• 从“补全时代”进化到“智能时代”，AI 角色由被动助手变为主动协作者。
• “洪荒—集成—增强—智能”四个阶段反映了工具从 Copilot、Cursor 到具备 MCP（Model Context Protocol）能力的 AI Agent 的演变。

2. 团队协作的痛点与 OpenSpec 的出现
• 团队在长对话中易出现上下文串台与信息丢失问题。
• OpenSpec 通过结构化的 proposal.md 让每次变更有清晰的 Why / What / How / Impact 记录。
• 规范驱动的文档体系保证项目约定可持久化，AI Agent 与新成员都能即刻理解项目背景。

3. 开发者角色的转变
• 开发者不再在指令层面操作 AI，而转为扮演“产品经理”或“团队 Leader”。
• 人负责提需求与审核，AI 负责起草与执行，实现工作分层与效率最大化。

4. OpenSpec 实践全流程
• 安装与初始化：通过 npm 安装并生成 openspec 项目结构（含 project.md、AGENTS.md、specs/、changes/ 等）。
• 创建提案：AI 根据指令生成 proposal.md、tasks.md、spec.md，记录需求、任务与标准。
• 提案打磨：人机协作循环评审，持续优化内容与规范。
• 实施与归档：AI 自动执行 openspec apply / archive 命令，所有过程留痕，形成项目知识库。

5. 实践心得与优势
• 使用者只需掌握 OpenSpec 流程，具体命令和实现由 AI 代劳。
• 项目文档成为最核心资产，使团队协作与知识传递更高效、透明、可靠。
• OpenSpec 提供了开发团队与 AI 共建标准化流程的现实范例。

author 4Ark

GitHub

GitHub - Fission-AI/OpenSpec: Spec-driven development for AI coding assistants.

Spec-driven development for AI coding assistants. Contribute to Fission-AI/OpenSpec development by creating an account on GitHub.

#优质博文 #前端 #AI #MCP #工程化 #nextjs
Next.js DevTools MCP: Your Development Server Just Got Smarter

AI 摘要：本文介绍了由 Vercel 提供的 next-devtools-mcp 套件，它利用 Next.js 16+ 的内置 MCP (Model Context Protocol) 端点 /_next/mcp，让 AI 编码助手（如 Claude、Cursor、Gemini 等）直接访问开发服务器的实时运行数据，包括构建错误、运行错误、TypeScript 类型检查、页面路由、Server Action 定义、日志与配置，从而显著提升调试与代码生成的智能化水平。

[以下是方便搜索索引的大纲 (AI 生成)，请读原文]

1. Next.js 16+ 的内置 MCP 支持
• 自 Next.js 16 起，框架内置 /_next/mcp 端点，可暴露实时的项目状态信息。
• 该端点支持 next-devtools-mcp 包进行自动发现与对接，无需额外配置。

2. 安装与集成方式
• 针对不同 AI 编辑器（Claude Code、OpenAI Codex、Google Gemini）提供简易的 npx 安装命令。
• 其他编辑器可通过在项目根目录添加 .mcp.json 文件实现集成。
• 重启开发服务器后，next-devtools-mcp 自动发现并连接 MCP 端点。

3. 实时错误访问与改进
• 在传统环境中，开发者只能复制错误日志手动传给 AI；
• 使用 MCP 后，Claude 等助手能自动获取错误堆栈、类型及关联代码文件；
• AI 可即时分析、修复并验证结果，大幅减少人工往返操作。

4. 内置工具与功能说明
• get_page_metadata：返回路由、组件与页面结构信息。
• get_project_metadata：暴露项目配置与依赖。
• get_server_action_by_id：查询特定 Server Action 定义。
• get_logs：访问开发服务器日志。
• nextjs_docs：查询官方文档并提供版本相关代码参考。
• upgrade_nextjs_16：运行 Next.js 16 升级代码改造。
• enable_cache_components：配置缓存组件并执行预检。
• browser_eval：通过 Playwright 集成运行浏览器测试。

5. 版本兼容与限制
• Next.js 16+ 获得完整支持，包括实时错误、状态与日志访问。
• Next.js 15 及更低版本仅支持部分功能，如升级脚本与文档查询。

author Trevor Lasn

trevorlasn.com

Next.js DevTools MCP: Your Development Server Just Got Sm...

The Next.js DevTools MCP connects Claude and Cursor to your running dev server. I use it every day.

#Newsletter #前端 #周刊更新
周刊第 13 期！多图警告～
九寨归来不看水
FE Bits Vol.13 ｜TypeScript 首次成为 GitHub 最常用语言、VoidZero A 轮融资 1250 万美元

#优质博文 #CSS #前端 #响应式 #容器查询 #布局 #course
Solved By Modern CSS: Section Layout

AI 摘要：本文作者 Ahmad Shadeed 通过一个常见的「版块布局」案例，展示了如何应用现代 CSS 技术（包括 :has()、container query、style query、clamp()、cqw 单位与 display: contents 等）解决传统响应式设计中无法灵活检测状态、复杂媒体查询以及无流畅排版的问题。文章从基础布局入手，逐步迭代到智能响应的组件结构，并探讨了 Safari 实验性支持的 random() 随机函数，以展现 CSS 的动态潜力。

author Ahmad Shadeed

Ishadeed

Solved By Modern CSS: Section Layout

Building a typical section design with modern CSS.

#优质博文 #前端 #JavaScript #标准化 #框架设计 #API #CSS #react
好文，No Directive！
Directives and the Platform Boundary | TanStack Blog

AI 摘要：本文由 Tanner Linsley 撰写，分析了当代 JavaScript 框架中兴起的 “use server”、“use client” 等自定义指令 (Directive) 趋势。这些指令表面上像平台特性，却缺乏标准规范，模糊了语言与框架的界线，引发生态混乱、工具负担与可移植性风险。作者主张：指令应保持极少且标准化，用于语言层；而具参数化、策略性或扩展需求的功能应采用显式 API（具来源 import、可组合与可版本化），以维持平台边界清晰和生态长远健康。

author Tanner Linsley

Tanstack

Directives and the Platform Boundary | TanStack Blog

A Quiet Trend in the JavaScript Ecosystem For years, JavaScript has had exactly one meaningful directive, "use strict". It is standardized, enforced by runtimes, and behaves the same in every environm...

#优质博文 #CSS #前端 #layout #容器查询 #新特性
Super Simple Full-Bleed & Breakout Styles

AI 摘要：本文详细介绍了如何在单栏布局中，通过现代 CSS（如 Grid、Container Query Units、border-image、伪元素等）创建“满屏延展”与“宽度突破”元素。作者比较了旧式 100vw 方法与基于 Grid 的新式做法，指出前者因滚动条计算问题较为落后，并展示了一个简单、可扩展的 Grid 结构可同时实现全宽元素、局部扩展元素，以及带全宽背景的局部内容。文章还讨论了细节问题如 box-sizing、负 margin、嵌套结构、浮动兼容性以及是否必须使用 Grid 等，最终总结：最佳方案依情景而定，但现代 CSS 已能极大简化此类复杂布局。

[以下是方便搜索索引的大纲(AI 生成)，请读原文]

1. 背景与问题定义
• 起因来自 Reddit 讨论：如何实现内容区中部分元素「全宽（full-bleed）」或「突破（breakout）」布局
• 对比老方法（100vw+偏移）与新方法（基于 Grid 中央列与左右对称列）
• 旧方法缺陷：100vw 不计滚动条，易引发水平滚动条
• 新方法更现代、更具弹性

2. 基础布局（The Base Grid）
• 在 body 上设定单列 Grid，最大宽度限制为 min(100%, 60em)
• justify-content: center 居中内容
• 保留 content-box 内边距空间以确保文字留白
• 所有子元素（如标题、段落、图片）自然落入此单列结构

3. 实现 Full-Bleed 元素
• 将 html 设为 container-type: inline-size ，元素用 width: 100cqw 获取可用宽度（不含滚动条）
• 使用 justify-self: center 居中
• 注意：html 上不能有 margin、padding，否则影响计算基准
• 若中间有容器层级，可通过 var(--full-w) 传递容器宽度
• 对非图片元素设置 box-sizing: border-box; padding: .5em；对图片则避免 padding
• 替代方案：用负 margin（calc(50% - 50cqw)）调整横向位置

4. 实现 Breakout 元素
• 比主栏宽，但未满屏，宽度公式为 min(100cqw, 100% + 2*4em)
• 或使用负 margin 实现，适合文本类内容
• 可通过自定义属性 --dx 调整突破值（正为扩展，负为收缩）
• 实例展示诸如 .break-elem--mini、.break-elem--maxi 等不同宽度的组合

5. Full-Bleed 背景处理
• 使用 border-image 扩展背景至全屏，如 border-image: var(--img) fill 0/ / 0 50cqw
• 支持颜色填充、渐变、图像背景等
• 针对带角度渐变或复杂背景，可通过计算 50cqw - .5*var(--grid-w) 精确控制延展范围
• 针对窄屏问题，利用 max() 考虑边距，保证背景元素真正全宽
• 实图背景的更优方案：使用伪元素 ::before 绝对定位配合 inset 实现，可支持 background-size: cover

6. 组合使用与分离视觉样式
• 可组合类 .break-elem + .full-bleed-back 实现“突破+全宽背景”效果
• 视觉样式与布局样式分离（例如 .box 仅用于颜色与边框）
• 避免边框或背景与 full-bleed 背景冲突的示例

7. 嵌套与兼容性
• figure 与 img 示例：图片全宽但说明文字保持正常列宽
• 确保 img.full-bleed-elem { display: block } 可正确工作
• 为了跨浏览器兼容 justify-self 可作用 block 元素，暂时让 figure 定义自身为 Grid

8. 浮动元素兼容性
• 若需在同一布局支持浮动（float）图片等，可增加内容包装容器
• 替代 justify-self 为 margin-left: calc(50% - 50cqw) 以保持结构适应性

9. 最后思考：Grid 是否必要
• 若布局需求简单，可用 body 的 padding/margin + limited main 替代 Grid
• 若需要间距控制、自动对齐等特性，Grid 仍具优势
• 结论：取决于上下文，现代 CSS 为设计师提供了灵活的选择空间

author Ana Tudor

#优质博文 #前端 #AI #新动态
Octoverse: A new developer joins GitHub every second as AI leads TypeScript to #1：2025 年 GitHub 的年度报告，比较有意思，摘了其中几个点看看：

1. GitHub 总用户达 1.8 亿，年增 3600 万，创下历史最高增长率。每秒新增 1 名开发者，印度贡献 500 万以上新用户，占全球新增 14%。

2. 生成式人工智能如今已成为开发中的标准配置。超过 110 万个公共代码库正在使用 LLM SDK，其中仅过去 12 个月就新增了 693,867 个项目（同比增长 178%）。开发者们还合并了创纪录的 5.187 亿个拉取请求（同比增长 29%），80% 的新开发者在第一周就开始使用 Copilot。

3. TypeScript 首次成为 GitHub 最常用语言，超越 Python 和 JavaScript。即便如此，Python 在人工智能和数据科学工作负载方面仍然占据主导地位，而 JavaScript/TypeScript 生态系统的整体活跃度仍然高于 Python 本身。

4. 总计 3.95 亿个公共存储库托管了 11.2 亿次贡献和 5.187 亿次合并拉取请求。

还有很多很多数据，感兴趣的建议阅读原文。

The GitHub Blog

Octoverse: A new developer joins GitHub every second as AI leads TypeScript to #1

In this year’s Octoverse, we uncover how AI, agents, and typed languages are driving the biggest shifts in software development in more than a decade.

#优质博文 #CSS #前端 #新特性
Detect fallback positions with anchored container queries from Chrome 143

AI 摘要：本文介绍了 Chrome 143 支持的 anchored container queries，它解决了 CSS Anchor Positioning Level 1 规范中无法识别元素使用了哪种回退定位的问题。通过 container-type: anchored 和 @container anchored(fallback: …) 的新语法，开发者可以在纯 CSS 中检测锚定元素（如 tooltip 或 popover）使用的最终定位方式，并进行样式调整，无需借助 JavaScript。

[以下是方便搜索索引的大纲(AI 生成)，请读原文]

1. 现有问题与功能背景
• CSS Anchor Positioning API 允许元素与锚对象绑定，并定义多个回退 (fallback) 定位方案。
• Level 1 规范中，浏览器自动调整位置但 CSS 本身无法得知采用了哪种回退方式。
• 导致样式无法自适应最终的显示状态（如 tooltip 箭头方向错误），过去常需借助 JavaScript 解决。

2. 新特性：Anchored Container Queries
• 来自 CSS Anchor Position Level 2 规范的新机制，引入 container-type: anchored。
• 该属性让定位元素成为可感知锚定状态的容器 (container)。
• 使用 @container anchored(fallback: …) 查询语法，可检测当前被应用的回退选项。
• 示例展示 tooltip 根据最终定位方向自动切换箭头符号与位置，实现完全基于 CSS 的适配。

3. 应用方式与优势
• 无需监听器或手动逻辑，即可通过 CSS 自主响应布局变化。
• 对 Popover API 的支持更自然，可隐式创建锚点。
• 扩展应用包括：动态改变菜单背景色、移动边框位置、调整圆角、根据回退位置触发动画。
• 极大提升组件的鲁棒性、上下文感知能力和可维护性。

4. 相关资源与规范
• Chrome Platform Status
• Spec: CSS Anchor Positioning Level 2

author Una Kravets

Chrome for Developers

Detect fallback positions with anchored container queries from Chrome 143  |  Blog  |  Chrome for Developers