• 批量抓取功能 - 一次性抓取多个链接中的文档内容
• 可视化元素选择器，在页面上直接选择包含链接的区域
• 智能链接提取，自动识别并预览所有可抓取的链接
• 正则过滤 - 使用正则表达式精确筛选链接
• 匹配目标：URL / 文本 / 两者
• 过滤模式：排除匹配项 / 仅保留匹配项
• 8 个内置预设规则（排除图片、锚点、分页、登录注册、静态资源、媒体；仅保留文档、网页）
• 翻页抓取时自动应用相同的过滤规则
• 分页抓取 - 支持选择"下一页"按钮，自动翻页并收集所有链接
• 三种抓取策略：
• Fetch API：直接获取页面 HTML，速度快但无法处理 JS 渲染
• 后台标签页：在后台标签页中加载页面，支持 JS 渲染和登录态
• 当前标签页：在当前标签页中依次访问，用户可见整个过程
• 实时进度显示，支持暂停/继续/取消
• ZIP 导出 - 将所有抓取结果打包为 ZIP 文件，包含索引文件和单独的 Markdown 文档
• 内容提取功能 - 选择页面元素，提取其内容为多种格式
• 可视化元素选择器
• 多格式输出：HTML / Markdown / 纯文本
• 一键复制到剪贴板
• 模型选择改进，现在支持从 API 获取模型也支持自定义输入模型名称了。

AI 摘要：本文探讨了如何实现一个由等分彩虹色段组成的旋转边框效果。作者指出，当容器的宽高比远离正方形时，单纯使用 CSS 的 conic-gradient() 方法无法保持色段等分，且分隔线难以垂直于边框。因此，文章提出了更优的解决方案：使用 SVG 的 <rect> 元素来精确控制每个色段的形状和动画，从而获得更稳定、更完美的视觉效果。文末提供了可交互的在线演示。

1. 问题与挑战
• 传统 CSS conic-gradient() 方法在实现等分彩虹色段旋转边框时存在局限。
• 当元素宽高比非正方形时，conic-gradient() 无法保持色段大小相等。
• 该方法产生的色段分隔线无法始终垂直于边框，影响视觉效果。

2. 解决方案与技术实现
• 提出使用 SVG <rect> 元素作为更优的替代方案。
• SVG 方法可以精确控制每个色段的形状、大小和位置。
• 通过 SVG 动画实现平滑的旋转效果，确保各色段始终保持等分且分隔线垂直于边框。

AI 摘要：本文是 Node.js 核心贡献者 Joyee Cheung 关于 require(esm) 功能实现细节的深度解析。文章聚焦于该功能在落地过程中，为兼容现有生态系统而必须解决的几个关键互操作性问题：包括如何处理“伪 ESM (faux-ESM)”包的 __esModule 标记、如何通过特殊导出 "module.exports" 支持非对象字面量的 CommonJS 导出、如何引入 "module-sync" 导出条件来支持双包 (dual package) 的平滑迁移，以及如何通过 process.getBuiltinModule() 避免不必要的顶层 await。文章揭示了看似简单的功能背后，为保持生态稳定性和性能所付出的复杂工程努力，并强调了社区协作在推动此类停滞计划中的关键作用。

1. 伪 ESM (Faux-ESM) 的兼容性挑战
• 问题根源：许多为浏览器打包的库在 Node.js 端发布的是转译后的 CommonJS 代码（即“伪 ESM”），它们依赖 __esModule 标记来模拟 ESM 的命名空间行为。
• 兼容性断裂：如果这些包直接迁移到纯 ESM，其现有的转译后消费者通过 require() 加载时将因缺少 __esModule 标记而中断。
• 解决方案评估与选择：在无法直接修改不可变的模块命名空间对象的前提下，评估了多种方案（对象拷贝、Proxy、原型继承、ESM 门面模块），最终选择了通过创建一个内部 ESM 门面模块（使用 export * from 并额外导出 __esModule）的方案，以在保证正确性（保持实时绑定、身份和可枚举性）的同时，将性能开销降至最低（约 2-4%）。

2. CommonJS 特殊导出模式的兼容
• 导出形状不匹配：CommonJS 允许 module.exports 被重新赋值为任何值（如一个类），而 ESM 的默认导出位于命名空间的 default 属性下，这导致迁移后 CommonJS 消费者无法正确获取导出值。
• 特殊导出方案：引入了名为 "module.exports" 的字符串字面量特殊导出。ESM 模块可以通过 export { Klass as "module.exports" } 来显式指定 require(esm) 应返回的值，从而无缝兼容旧的 CommonJS 消费者，而无需改变 ESM 消费者的导入方式。

3. 双包 (Dual Package) 的迁移路径
• 条件导出的演进：为了在支持旧版 Node.js（仅 CommonJS）的同时，为新版 Node.js 提供 ESM，包作者曾使用 "node" 条件指向 CommonJS。
• 新条件的引入：由于生态中已有的 "module" 条件常指向无法在 Node.js 直接运行的打包后代码，Node.js 引入了新的 "module-sync" 条件，专门用于指向可在 Node.js 中同步加载的 ESM 源文件，作为向纯 ESM 包过渡的临时方案。

4. 同步内置模块检测
• 问题背景：在 ESM 中动态检测内置模块（如 node:os ）过去只能通过异步的 import() 实现，这迫使代码使用顶层 await。
• 同步 API 的引入：为解决此问题并方便工具链（如 TypeScript），Node.js 引入了 process.getBuiltinModule() 这个同步 API，允许在 ESM 中同步获取内置模块引用，减少了对顶层 await 的依赖。

5. 底层实现与同步化
• 概念模型：require(esm) 的简化逻辑是同步地获取、链接、评估 ESM 模块，然后返回其命名空间。
• 同步化重构：实际的挑战在于与异步 import 共享的模块缓存和加载流程可能引发竞态条件。随着 Node.js 生态对同步模块加载的坚定依赖，原先为未来异步扩展设计的加载器例程被简化为完全同步，这既消除了竞态，也移除了不必要的异步开销。

6. 模块评估的可重入性保障
• 规范限制：ECMAScript 规范规定，一个正在评估中的 ESM 模块不能被再次评估。
• 循环依赖处理：当模块依赖循环跨越 ESM 和 CommonJS 边界时，Node.js 通过检测并抛出 ERR_REQUIRE_CYCLE_MODULE 错误来防止违规的重入评估。未来的 “Deferring Module Evaluation” 提案可能允许安全地跳过同步重入评估，从而支持此类循环。

AI 摘要：AntV Infographic 是一个专为 AI 时代设计的声明式信息图表渲染引擎。它采用简洁的声明式语法，支持 AI 流式输出（Streaming Output）与实时渲染，并内置了超过 200 种信息图表模板、组件和布局。该框架不仅提供高质量的 SVG 输出，还拥有丰富的主题系统（包括手绘风和渐变色）以及配套的在线编辑器，极大提升了信息展示的效率，让开发者和 AI 能够更轻松地创作专业级别的数据故事。

1. 核心特性（Core Features）
• AI 友好（AI-friendly）：语法与配置专为 AI 生成进行了优化，提供简洁的提示词（Prompts），并支持 AI 流式输出的即时渲染。
• 开箱即用（Ready to use）：内置约 200 个信息图表模板、数据项组件和布局方案，可快速构建专业作品。
• 主题系统（Theme system）：支持手绘、渐变、图案等多种预设主题，并允许深度自定义。
• 内置编辑器（Built-in editor）：提供可视化编辑器，方便对 AI 生成的结果进行二次微调。
• 高质量 SVG 输出：默认采用 SVG 渲染，确保视觉保真度且易于后期编辑。

2. 快速上手与集成（Installation & Quick Start）
• 通过 NPM 轻松安装：使用 npm install @antv/infographic 即可引入项目。
• 声明式语法：演示了如何通过简单的配置项和类 YAML 的文本语法快速渲染出一个带箭头的步骤列表图。
• 极简 API 设计：通过 new Infographic() 实例化并调用 render() 方法即可完成渲染。

3. 流式渲染技术（Streaming Rendering）
• 高容错语法：设计了具备高容错性的信息图表语法，即使在 AI 文本生成的过程中也能实时解析。
• 动态预览：支持将 AI 输出的每个片段（Chunks）实时渲染到界面上，提供丝滑的生成体验。

4. 社区动态与许可（Community & License）
• 社区交流：鼓励通过 GitHub Discussions 和 Issues 进行交流反馈。
• 开源协议：项目采用 MIT 协议开源。

GitHub

GitHub - antvis/Infographic: 🦋 An Infographic Generation and Rendering Framework, bring words to life with AI!

🦋 An Infographic Generation and Rendering Framework, bring words to life with AI! - antvis/Infographic

AI 摘要：Nuxt 近期发布了从 4.0 到 4.2 的一系列更新，重点聚焦于开发体验（DX）和性能优化。在 4.2 版本中，最显著的改进包括支持在 useAsyncData 中使用原生的请求取消信号（AbortController），以及一项能够将预渲染站点的客户端 JavaScript 包体积减少高达 39% 的实验性功能——异步数据处理器提取。此外，新版本还增强了 TypeScript 插件支持，优化了开发环境下的错误处理逻辑，并提供了对 Vite 6 环境 API 的初步支持，进一步提升了 Nuxt 在全栈框架领域的竞争优势。

InfoQ

Nuxt Introduces Native Request Cancellation and Async Handler Extraction for Performance Gains

Nuxt 4.2 elevates the developer experience with native abort control for data fetching, improved error handling, and experimental TypeScript support. With a 39% reduction in bundle sizes and a streamlined app directory, this release enhances performance and…

AI 摘要：本文系统梳理了 CSS 中 Container Queries 的三种类别（包括 Container Size Queries、Style Queries、Scroll-state Queries），重点介绍了已在主流浏览器实现的“尺寸查询”特性如何革新组件级响应式设计，但也提醒开发者——这并非替代 Media Queries 的“银弹”。文章从语法、性能约束、浏览器支持到设计协作与可访问性进行了深入分析，最后指出未来 2026 年 Style Queries 或将迎来实用化拐点。

1. 背景与概念：Container Queries 是什么
• 源自对 Media Queries 局限的反思，核心思想是“基于容器上下文，而非视口”进行样式判断。
• 三种类型：
• Container Size Queries：按父容器尺寸调整样式（目前最成熟）。
• Container Style Queries：根据容器的样式属性触发响应（仍在实验阶段）。
• Container Scroll-state Queries：随滚动状态变化触发样式。
• 支持组件级响应，使组件可在任意布局中自适应。

2. 工作机制与核心语法
• 使用 container-type 属性显式声明容器上下文（如 inline-size）。
• @container 规则用于监听容器尺寸条件。
• 支持逻辑方向单位（inline/block），替代传统 width、height。
• 新增容器单位 (container query units)：如 cqw, cqh, cqi, cqb，与 viewport 单位类似但基于容器。
• 通过 container-name 可命名容器，以便管理嵌套查询。

3. 性能与限制（containment API 的作用）
• Container Queries 得以实现的关键是 Containment API。
• 为避免性能开销，每个容器需“选择加入”（opt-in），阻止布局循环。
• 限制与陷阱：
• 无法查询自身，只能作用于子级。
• 某些布局（如 Flexbox）可能需额外约束尺寸。
• 不支持在查询条件中使用自定义变量（custom properties）。
• 过度嵌套可能导致标记膨胀。

4. 三种 Query 类型的详细分析
• Size Queries：主流实现，支持全面，能显著提升组件自治性。
• Style Queries：基于容器样式或 CSS 自定义属性触发；浏览器支持尚不完善，未来版本（尤其 Firefox）有望实装。
• Scroll-state Queries：根据 stuck、snapped、scrollable 等状态调整布局；适合渐进增强。

5. 与 Media Queries 的关系
• 非替代关系，而是互补：
• Media Queries 仍主导宏观布局与可访问性偏好（如 print、暗色模式）。
• Container Queries 主攻微观层级的组件自适应。
• 建议联合使用，例如嵌套 @media 与 @container 以实现双层响应策略。

6. 可访问性与可维护性
• 需确保布局变化不破坏键盘导航与阅读顺序。
• 避免大幅度 layout shift，必要时使用 aria-live。
• 适度使用 Container Queries，防止性能问题；合理划分 @container 层级。

7. 浏览器支持现状与未来展望（至 2026）
• 2023 起 主流浏览器已全面支持 Size Queries。
• 2025 末 Chrome、Edge、Opera 支持 Scroll-state；Firefox 预计 2026 跟进 Style Queries。
• CSS 社区使用率增长缓慢（2025 调查：仅 7% 使用 Style Queries）。
• 预期 2026 年将成为“容器查询元年”，尤其设计工具（如 Figma）与开发端联动增强后。

8. 实践与工具链建议
• 设计师应从视口（viewport-centric）转向容器思维（container-centric）。
• 前端可在 DevTools 中可视化调试容器边界与查询状态。
• 借助 @supports 可实现渐进增强。
• 结合组件化体系（React、Vue 等）可真正实现“自包含组件”(self-contained components)。

9. 结论：强大但非万能
• 容器查询填补了响应式开发的关键空白，使组件具备上下文感知能力。
• 然而仍需注意性能、兼容性和可访问性。
• 它们不会消灭媒体查询，但将共同构建未来的“模块化响应式设计”范式。

LogRocket Blog

Container queries in 2026: Powerful, but not a silver bullet - LogRocket Blog

Container queries enable truly responsive components. Learn how they work, where they shine, and why they complement rather than replace media queries.

AI 摘要： 作者 Nolan Lawson 在假期挑战自己以 “vibe coding” （即尽量不亲自写代码、主要通过 LLM 助手生成）构建一个供妻子使用的旅行行程管理 Web 应用。项目利用 Claude Code、Tailwind CSS、React、PocketBase 与 Railway 进行快速开发，最终成果稳定且满足需求。但实践暴露出当前 LLM 编码工具的不足：非程序员难以高效运用、可访问性差、性能优化需要人工介入。作者反思 “vibe coding” 的局限，也看到其在轻量、个性化应用中的潜力，并对未来软件开发职业与 AI 协作形态表示复杂的期待与忧虑。

Read the Tea Leaves

An experiment in vibe coding

For the holidays, I gave myself a little experiment: build a small web app for my wife to manage her travel itineraries. I challenged myself to avoid editing the code myself and just do it “v…

Sujen Phea (@sujen_p): Unfurling paper
Demo 👉 https://paper-scroll.sujen.co/
#webgl #threejs
Spinning disco vibes
Demo 👉 https://disco.sujen.co
#webgl #threejs