Warning: Undefined array key 0 in /var/www/tgoop/function.php on line 65

Warning: Trying to access array offset on value of type null in /var/www/tgoop/function.php on line 65
- Telegram Web
Telegram Web
#碎碎念 #美食
饭小俏的石板鸡蛋,好吃,惦记。
是石锅鸡蛋的代餐(确信)
数了一下,六个蛋,20块钱,比不上以前学校里的吃的石锅鸡蛋和缘味先,但是作为广州商场里的店来说还算划算
5🤩3
#优质博文 #性能优化 #CSS #Lighthouse #前端 #移动端适配
How to Optimize Viewport for Mobile for Faster Interactions | DebugBear

AI 摘要:文章围绕 Lighthouse 的新性能洞察 “Optimize viewport for mobile” 展开,分析移动端点击延迟 (300 ms) 的成因及对用户体验与核心网站性能指标 (Core Web Vitals) 的影响。通过剖析 Qatar Airways 的示例,作者说明 JavaScript 覆盖 viewport 设置会导致移动端性能劣化,并给出优化建议:应使用 <meta name="viewport" content="width=device-width, initial-scale=1"> 与 CSS 媒体查询来实现响应式布局,而非固定宽度或 JS 动态改写,从而避免延迟、提升 INP (Interaction to Next Paint)。最后介绍如何利用 DebugBear 持续监测网页性能与真实用户数据 (RUM)。

[以下是方便搜索索引的大纲(AI 生成),请读原文]
1. 概述:Lighthouse 新洞察“Optimize viewport for mobile”
• 取代旧的 <meta name="viewport"> 静态检查,采用动态分析判断页面是否真正移动友好
• 若检测失败,用户点击将产生高达 300 毫秒延迟,严重影响 INP

2. 300 毫秒点击延迟的背景与机制
• 浏览器历史上为保留“双击放大”功能而引入延迟
• 当网站非移动优化时,为兼顾可访问性,浏览器继续保留延迟
• 若 viewport 固定宽度(如 desktop 模式缩小版),则自动启用此延迟

3. 案例分析:Qatar Airways 官网 viewport 问题
• HTML 中声明了标准 viewport:width=device-width, initial-scale=1.0
• 但随后被 JS 在两个断点下改写为固定宽度 width=480
• 因此反过来触发非移动优化逻辑,导致交互延迟、INP 崩溃
• 使用 window.screen.width 而非 window.innerWidth,使得问题在 DevTools 模拟测试中难以察觉

4. 优化方案与最佳实践
• 使用标准 viewport 配置:<meta name="viewport" content="width=device-width, initial-scale=1">
• 避免使用固定宽度或在 JS 中修改 viewport
• 采用 CSS media queries 管理不同尺寸布局
• 通过 viewport 宽度进行断点分布,避免依赖物理屏幕宽度

5. 持续监测与性能保障
• 借助 DebugBear 可设定定期性能测试与性能预算 (performance budgets)
• 提供 Lighthouse 集成、图形对比、阈值报警等功能
• 支持真实用户监控 (RUM),捕获真实点击延迟与 INP 细节
• 推荐结合模拟测试与生产环境监控,确保页面长期稳定


author DebugBear
👍2
POLEBUG - WHAT ARE YOU THINKING?
刷到自由职业者适合旅居城市的测评,我发现这些测评都缺少一个我很看重的点:咖啡厅聚集的地方,是否有好的风景

因为工作日不太能走来走去,如果能边办公边欣赏美景,就是最棒的。

我目前体验最棒的城市:大理和清迈,这俩几乎是完美的旅居城市。

1️⃣ 大理

电动车就可以到达景区附近,苍山+洱海+古城,且咖啡厅很多,随处可以办公。

但大理对远程工作者并不是特别友好,很难找到有桌子的民宿。

以及有些地方不好打车,便利店少,美食的种类少、容易吃腻,等等小缺点。

2️⃣ 清迈

因为在这有很多远程办公的人,所以民宿几乎都有工作区,或者是大桌子,这一点我超级喜欢!!!

咖啡厅很多,虽然没有大理这样的自然风景,但是咖啡厅都很宽敞,有一些自带院子,办公的体验都很棒。

城市不大,同样是电机可在市中心随便转悠的程度。

美食种类多,因为清迈偏国际化,除了泰国的几种菜系,还有韩料、日料等,可以选择。

从远程办公体验的角度来说,找不到啥缺点 😄 硬要说的话,就是东南亚比较热。

3️⃣ 青岛

青岛其实也还不错,我会打 3/5 分。

市区去海边并不算太远,也有许多咖啡厅,风景挺不错。

民宿性价比高,也基本带有桌子可以办公。

但是青岛有点太大了,打车去不同的地方,单程大概在 20 分钟以上,就有点麻烦。

/

P.S. 好想清迈和大理,等忙完这阵子打算再去一次
#碎碎念
感觉去过大理的或多或少都会想再去几次,我又想去了呜呜呜。
但是订了月底去成都的机票,打算去看看九寨沟(一直想去)
听说10月底~11月初是九寨沟最好看的时候。
#优质博文 #CSS #font #前端
Targetting specific characters with CSS rules

AI 摘要:作者通过实验发现,虽然 CSS 无法直接为特定字母(如 "E")单独设置样式,但可以借助 @font-face 的 unicode-range 特性,为某些 Unicode 字符指定不同的字体,实现“伪定向”样式。这种方法能让部分字符使用不同字体或通过字体文件的多彩功能(如 OpenType 的 COLR 表)来实现颜色变化,从而在不添加额外标记的情况下,产生有趣的视觉效果。尽管样式控制有限,但仍展现了 CSS 与字体技术结合的创造潜力。

[以下是方便搜索索引的大纲(AI 生成),请读原文]
1. CSS 与字符定向样式的限制与突破
• 通常看来,CSS 无法直接选择文字中的某个具体字符进行样式修改。
• 作者提出一种“秘密方法”,利用字体层面实现针对字符的视觉差异。

2. @font-face 与 unicode-range 的创新用法
• 定义自定义字体 "Different",并指定某些 Unicode 码位(如 a, e, i, o, u)。
• 使用 font-family 优先级让目标字符采用不同字体,其他字符保留默认样式。
• 在视觉上形成“部分字符变异”效果,而无需额外 HTML 标记或包裹元素。

3. 可扩展技巧与字体特性应用
• 利用 size-adjust 属性可微调字体尺度,使字符外观稍有变化。
• 利用 WOFF2 格式中的 COLR 表(彩色字体表),可为字体字符添加颜色图层。
• 举例引用多彩像素字体 Street Fighter II Large 1,实现大写字符的彩色展示。

4. 结论:CSS 与字体结合的创造空间
• 尽管 CSS 本身不支持字符级定向样式,但字体技术为前端视觉设计提供了可能。
• 此实验启发开发者通过字体文件与 CSS 结合,实现独特、微妙的文本艺术效果。


author Terence Eden
1
#优质博文 #后端 #工程化 #架构
Stop writing REST APIs from scratch in 2025 - LogRocket Blog

AI 摘要:本文指出传统手动编写 REST API 的方式存在重复、易错和效率低等问题,建议开发者在 2025 年采用基于 schema 的声明式 (declarative) API 架构。文章通过对比 Express + yup 的旧式流程与 tRPC + Zod 等现代框架的 schema 驱动方案,展示了后者在类型安全、自动文档生成和开发效率上的明显优势。文末总结,这一趋势代表了 API 开发范式的转变:不再从零搭建 REST,而是借助框架实现「单一事实源 (Single Source of Truth)」的自动化、类型安全和可维护性。

[以下是方便搜索索引的大纲(AI 生成),请读原文]
1. 传统 REST API 的问题
• 以 Express + yup 为例,展示编写一个 POST /users 接口的流程需要多次定义相同结构(TypeScript 接口与验证 schema),违反 DRY 原则。
• 手动设置中间件、类型转换、错误捕获、更新文档等步骤繁琐且易出错。
• 代码重复导致类型不同步、文档过时等潜在风险。

2. 基于 schema 的声明式解决方案
• 引入 tRPC + Zod:仅需定义一次 schema,即可自动推导类型、内建验证、生成文档。
• 省去中间件与显式类型转换,错误由框架统一处理。
• 实现「一份定义,三方同步」:类型、安全与文档共用同一 schema。

3. 行业框架的趋势与示例
• Hono:以标准 Web API 语法结合 zValidator 内置验证,简化 Express 式编写。
• Fastify:通过 schema 改进性能,将类型安全转化为运行时效率,并生成 JSON Schema。
• NestJS:通过装饰器 (decorator) 方式实现 declarative 验证与类型推断,无需手动配置。

4. 对比与优势总结
• 开发速度:传统方案冗长且易同步出错,schema 驱动模式定义一次即可。
• 安全性与可靠性:旧式依靠手动转换,schema 模式实现端到端类型安全。
• 文档维护:旧方式需手写 OpenAPI,schema 模式可自动生成实时文档。

5. 结论与未来趋势
• 手工编写 REST API 已成为反模式,schema 驱动的 declarative 模型是未来标准。
• 关键价值在于「写更好的代码」,而非「写更少的代码」。
• 单一 schema 即为验证层、类型系统与文档源,使开发更快、更安全、更可维护。


author Ikeh Akinyemi
#优质博文 #CSS #前端 #新特性 #course
Modern CSS Round-Out Tabs

AI 摘要:本文探讨了如何利用现代 CSS 的 shape() 函数与 clip-path 属性,构建出带有圆角、延展弧线的标签 (Tabs) 样式。文章从早期依赖多元素遮罩的实现方式出发,逐步演示如何使用 shape() 绘制可响应的标签形状,并通过变量 (CSS Variable) 优化灵活度。后续还包含兼容性 fallback、单方向滚动控制 overflow-inline/overflow-block 的技巧,以及对可访问性 (Accessibility) 实现的反思。

[以下是方便搜索索引的大纲(AI 生成),请读原文]
1. 背景与旧方案
• 作者回顾早期制作“round-out tabs”的方案,需要为每个标签使用四个额外元素来模拟圆角连接效果。
• 这种方法复杂、难维护且受限于层叠遮罩实现。

2. 使用 shape() 实现圆角标签
• 介绍 shape() 函数与 clip-path 的结合,能直接以绘图指令定义形状,无需额外 DOM 元素。
• shape() 的指令包含 from、curve、vline、hline 等步骤,用以绘制从矩形裁剪出的弧线标签外形。
• 每一步演示曲线、直线和坐标计算,使形状既可固定又可相对灵活。
• 最终实现完整闭合形状,只显示实际的标签区域。

3. 参数变量化与可动态调整
• 将固定数值(如 10px、20px)抽象为自定义属性 (--tabGirth),以便根据变量调整标签厚度。
• 使用 Knobs 等交互工具实时修改变量值以测试视觉效果。

4. 外观与行为增强
• 添加 hover 与 active 效果,通过 translate 实现微动。
• 解决非换行标签的滚动问题,利用 overflow-inline: auto 与 overflow-block: clip 控制单方向滚动。
• 使用 filter 为 clip 后的形状添加阴影效果。

5. 浏览器兼容性与 Fallback
• 当前仍有浏览器未完全支持 shape()。
• 提供 @supports 条件判定,未支持时以 border-radius 提供圆角退化方案,保证视觉一致性。

6. 可访问性 (Accessibility) 讨论
• 使用 anchor 作为基础标签实现,并在有 JavaScript 时补上 aria 属性。
• 承认目前键盘导航功能不足,提醒开发者参考更完善的无障碍 Tabs 模式。

7. 相关与延伸参考
• 提到 Temani Afif、Ana Tudor 的圆角或内凹标题组件为现代 CSS 造型提供灵感。


author Chris Coyier
#demo #codepen #WebGL #Shader
写着色器的真的很 NB,每次看到都很佩服。
Juicy:Matthias Hurrle 的又一次关于次表面散射(subsurface scattering)的实验,模拟水果糖果风格的魔方。
This media is not supported in your browser
VIEW IN TELEGRAM
#demo #codepen #动画 #CSS #SVG #设计
404 Error Face:Jon Kantner 基于 Camo Creative 的设计,将 404 错误页转为纯 CSS 和 SVG 的循环动画,用趣味视觉缓解用户体验挫败感。
#优质博文 #vite #工程化 #前端 #开源 #新动态
VueConf 上说的 Vite+,介绍文章也来了(
Announcing Vite+

AI 摘要:Vite+ 是在 ViteConf 上发布的全新统一工具链(unified toolchain),旨在整合构建、测试、格式化、代码规范检查和库打包等开发环节,解决 JavaScript 工具碎片化与性能瓶颈问题。它在 Vite 基础上新增 vite new、vite test、vite lint、vite fmt、vite lib、vite run、vite ui 等命令,并基于 Rust 实现完整编译链以实现极致性能。Vite+ 将采用 “source-available” 的商业许可策略,对个人及开源用户免费,对企业采取付费订阅模型,目标是构建可持续的前端生态。

[以下是方便搜索索引的大纲(AI 生成),请读原文]
1. Vite+ 简介
• 来源于 Vite,同样可从 npm 安装;作为简体升级版,整合更多开发命令。
• 目标是提供统一的前端工程体验,使复杂项目的开发、测试与构建更加高效。
• 与 React、Vue、SvelteKit 等框架无缝兼容,并可直接用于单体或 monorepo。

2. 核心特性与命令集
• vite new:生成新项目或为 monorepo 生成代码模块。
• vite test:由 Vitest 驱动,兼容 Jest API,支持浏览器测试、分片和可视化回归测试。
• vite lint:集成 Oxlint,支持类型感知检查,性能比 ESLint 快百倍。
• vite fmt:即将发布的 Oxfmt 格式化工具,兼容 Prettier,提供更多换行与格式控制能力。
• vite lib:用于构建库,集成 tsdownRolldown,自动生成类型声明。
• vite run:智能缓存的任务执行器,无需显式配置即可获得细粒度缓存。
• vite ui:图形化开发工具,展示模块解析、打包与摇树分析等信息。

3. Rust 驱动的底层实现与性能优化
• 全链路由 Rust 重构实现,包括 parserresolvertransformerminifierbundler
• 高度性能调优,并被 Framer、Linear、Atlassian、Shopify 等公司采用。
• 暴露 parse 和 transform API,便于二次开发。

4. 解决的问题:JavaScript 工具生态的碎片化
• 多项目多团队导致依赖不一致、安全审核复杂与工具迁移成本高。
• Vite+ 旨在提供统一、协同的工具基础架构,减少配置、调试与迁移成本。
• 通过一致的命令与生态整合,提升开发协作效率。

5. 商业化与开源策略
• 将采用 “source-available” 策略:个人、开源、小型团队免费使用;企业需订阅授权。
• 收费部分将反哺 Vite+ 及其基础开源项目(Vite、Vitest、Rolldown、Oxc)。
• 承诺上述基础项目始终保持 MIT 开源许可。
• 目标是在维持社区信任与生态创新的前提下,探索开源项目的可持续商业模式。

6. 计划与参与方式
• 预计 2026 年推出公开预览版。
• 招募早期试用用户,可访问 viteplus.dev 参与测试。
• 官方希望社区共同塑造 Vite+ 的发展方向。


author Evan You
👍1
#优质博文 #V8 #性能优化 #JavaScript
CF 不愧是赛博活菩萨捏,大气的。
@DIYgod: 一周前 Vercel 发了篇博客指责竞争对手 Cloudflare Workers 性能差,今天 Cloudflare 回应了篇博客承认错误,解释了造成问题的各种技术细节,现在把性能也追上来了 太佩服这种在竞争对手面前勇于承认错误的勇气和快速透明解决问题的态度了,现在倒是显得 Vercel 小肚鸡肠了...

https://fixupx.com/DIYgod/status/1978461834731512072

Unpacking Cloudflare Workers CPU Performance Benchmarks

AI 摘要:本文由 Cloudflare 首席架构师 Kenton Varda 撰写,针对独立开发者 Theo Browne 公布的基准测试结果展开调查与回应。原测试显示 Cloudflare Workers 在 CPU 密集型 JavaScript 任务中比 Vercel(基于 AWS Lambda)慢至 3.5 倍。Cloudflare 分析后发现,性能差异主要源自调度算法、V8 垃圾回收参数旧配置、OpenNext 框架实现低效及测试方法偏差。经过多项修复与调优,Workers 性能已与 Vercel 持平甚至超越。文中还披露了 Cloudflare 对 V8 与 Node.js 性能改进的贡献,证明其优化不仅服务自家平台,更惠及广泛的 JavaScript 生态。

[以下是方便搜索索引的大纲(AI 生成),请读原文]
1. 基准测试背景与问题调查
• 独立开发者 Theo Browne 公布测试,显示 Cloudflare Workers 明显落后 Vercel
• 两者皆基于相同的 V8 引擎,理论上应相近性能
• 性能差异达到 3.5 倍,引发 Cloudflare 团队深入分析
• 指出测试方法主要反映“等待时间”而非“实际 CPU 使用”

2. 平台调度算法与运行时优化
• Workers “warm isolate routing” 策略导致 CPU 密集型请求排队
• 调整调度算法,让系统更快检测并扩展新 isolate,避免阻塞
• 改进后大幅降低延迟波动,提高自动扩展效率

3. V8 (JavaScript 引擎) 垃圾回收 (Garbage Collector, GC) 调优
• 发现旧参数设定限制了“young generation”空间大小
• 放宽 GC 配置让 V8 自调内存区间,性能提升约 25%
• 改进已全球部署,影响所有 Workers

4. 优化 OpenNext 与 Next.js 性能
• 识别大量不必要的内存复制与 Buffer 分配
• 对流式响应 (Streaming) 做性能补丁,减少冗余数据操作
• 提交多个 PR 改进 OpenNext,包括缓存优化、流管道调度、正则重用等
• 针对 JSON.parse reviver 函数的低效执行向 V8 上游提交补丁,提升约 33% 性能

5. Streams 适配与数据传输改进
• Node.js 与 Web Streams API 转换时存在重复缓冲问题
• 改用原生 ReadableStream.from(chunks) 避免多层拷贝
• 调整 ReadableStream highWaterMark,使字节流读取更高效

6. Node.js 三角函数性能修复
• Node.js 未启用 V8 trig 函数快速路径
• Workers 已默认启用,因此跑分更好
• Cloudflare 提交 PR 修复 Node.js 构建配置,使全生态受益

7. 对基准测试方法的反思与改进
• 本地测试中网络延迟影响 CPU 计算评估
• Cloudflare 与 Vercel 所用硬件代际不同,会引入性能噪声
• Next.js 与 React SSR 测试中存在 force-dynamic 与 NODE_ENV 配置错误导致性能偏差
• 建议未来基准采用可控环境与更准确指标(TTLB 而非仅 TTFB)

8. 后续计划与开放协作
• 所有平台级修复已上线,无需用户手动更新
• 将继续优化 OpenNext 与 V8,推动上游框架改进
• Cloudflare 鼓励社区提交性能测试,团队会分析并修复问题
• 长期目标:通过改进开放源代码基础设施提升整个生态性能


author Kenton Varda
😁2
#碎碎念
广州 3 号线这阴间线路,每次看都有点难蚌。
我在深圳没见过这世面啊🌚
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
#优质博文 #Git #版本控制
好看,爱看。
从零开始理解 Git|纯手工打造 Git 仓库|太长可以不看 - 小众软件

AI 摘要:本文从零开始手工实现 Git 仓库的内部结构与命令逻辑,解释了 git init、git commit、git cat-file 等操作背后发生的机制。作者通过亲手创建 .git 目录与对象,展示 Git 的核心原理如内容可寻址存储(Content Addressable Storage, CAS)、树对象与提交对象、打包与垃圾回收(garbage collection)机制等,帮助读者摆脱“命令黑箱”的依赖,以理解 Git 的本质优雅与简洁设计。
#优质博文 #React #前端 #工程化
React Folder Structure in 5 Steps (2025)

AI 摘要:本文详解了作者多年实践总结出的 React 项目结构化思路,以「逐层演进」为主线,从单文件组件到分页驱动(Page-driven)架构,展示了如何通过结构分层与命名规范,实现 React 应用在复杂度与团队协作下的平衡。文章强调不存在唯一正确方案,读者应根据项目规模与团队习惯灵活调整。

[以下是方便搜索索引的大纲(AI 生成),请读原文]
1. 单文件阶段(Single React File)
• 初始项目通常包含一个 src/App.js 文件。
• 所有组件起初可写在单文件中,便于快速原型开发。
• 随项目增长,应将可复用组件拆分,以减少冗余和嵌套复杂度。

2. 多文件阶段(Multiple React Files)
• 抽离可重复使用的组件为独立文件,如 List 和 ListItem。
• 通过文件导出(export)定义组件的“公共接口”(API)。
• 使用文件扩展名策略(.js/.jsx/.ts/.tsx)统一文件规范。
• 建议仅对可复用组件拆分,不要过早抽象。

3. 文件夹化阶段(From Files to Folders)
• 随组件复杂度增加,将相关技术关注点(测试 test、样式 style、类型 type、工具 utils)集中在组件文件夹。
• 采用“一个组件一个文件夹”的结构,如 src/list/ 或 src/app/。
• 使用 index.js 作为模块对外出口(即“barrel 文件”),控制组件的公共 API。
• 讨论命名规范(如 .spec.js、.module.css)与层级深度(避免超过两级嵌套)。
• 建议尽量避免过深目录,用功能聚合代替结构嵌套。

4. 技术型文件夹(Technical Folders in React)
• 当项目达到中等规模,应区分“组件类”与“技术类”逻辑。
• 在 src/ 中增设按技术职能划分的文件夹:
• components/:组件逻辑
• hooks/:自定义 React Hooks
• context/:应用全局状态
• services/:通用服务(格式化、错误追踪、请求封装等)
• 服务示例通过 Intl API 实现日期格式化并由模块封装暴露。
• 推荐使用路径别名(alias,如 @/services/...)避免相对路径混乱。
• 指出 barrel 文件的利弊——简化导入但可能削弱 tree-shaking。

5. 功能型文件夹(Feature Folders in React)
• 大型项目中,按“业务领域(Feature)”划分文件夹,以聚合其内所有组件与逻辑。
• 结构区分:
• feature/:业务特定代码(如 user、post、payment)
• components/:跨 feature 可复用的 UI 组件
• services/hooks/context:依旧保留为全局可重用逻辑
• 每个 feature 内可包含对应 components/、services/ 等子文件夹以划分技术关注点。
• 帮助团队并行开发、限域依赖,提高可维护性与灵活性。

6. 页面驱动结构(Page Driven Structure)
• 当应用存在多页面(特别是 Next.js 或 Vite + React),建议围绕 pages/ 或 app/ 文件夹组织。
• 每个页面对应入口点 (page.tsx),并链接相关 feature。
• 在同页面内是否嵌套 feature/取决于其复用度与作用域;鼓励保持一致的目录结构。
• 比较 Next.js 的文件路由与客户端路由在结构设计上的差异。
• 最终形成具有多层抽象但一致规则的工程化结构,支持扩展与团队协作。

7. 总结与启发
• 无绝对正确的文件结构,应随项目自然演化。
• 遵循“按复用程度而分层”,“按技术职能而归类”,“按业务边界而划分”的原则。
• 五步推进法可帮助开发者在项目复杂化时保持组织清晰。


author Robin Wieruch
#优质博文 #CSS #动画 #前端 #course
Sequential linear() Animation With N Elements | CSS-Tricks

AI 摘要:本文通过一个简洁的示例与完整讲解,展示了如何仅用几行现代 CSS 代码实现 N 个元素的顺序动画。作者利用 CSS 的 linear() 函数自定义时间曲线(timing function),结合 sibling-index() 与 sibling-count() 自动计算每个元素的动画时间段,使所有元素依次播放动画而不需复杂的 keyframes 管理。该方法具有可扩展性和可维护性,为 CSS 动画提供了新的编程式思路。

[以下是方便搜索索引的大纲(AI 生成),请读原文]
1. 背景与问题定义
• 多个元素需要依次执行相同的动画,传统方法需手动定义复杂 keyframes 与延迟。
• 目标:用纯 CSS,在不修改 keyframes 的前提下让动画顺序执行、可循环、可扩展至任意元素数量。

2. CSS linear() 函数解释
• linear() 是一种新的时间函数(easing function),支持自定义多个控制点(control points)。
• 通过定义输入进度(input progress)与输出进度(output progress)来构造任意变化曲线。
• 相较于传统 ease 或 cubic-bezier(),linear() 可精确定义不同阶段的动画输出。
• 可用百分比或数值型进度表示时间点,省略值会自动插补为中间点。

3. 利用 linear() 构造延迟(animation delay)
• 通过重复定义相同输出值(如 linear(0 0%, 0 50%, 1 100%))可制造“暂停”效果。
• 表示动画前半段不变化、后半段才执行。
• 可灵活组合多个时间段,无需修改 keyframes 即可调整节奏。

4. 构建顺序动画逻辑
• 多元素顺序动画思想:每个元素仅在自己的时间段(range)内动画,其余时间保持静止。

• 对于 N 个元素,将总时间分为 N 等份,每个元素依次占一个区间。

• 变量定义:
• S = 起始点 = (i - 1) × 100% / N
• E = 结束点 = i × 100% / N

• 关键 CSS 实现:
--_s: calc(100%(sibling-index()-1)/sibling-count());
--_e: calc(100%
(sibling-index())/sibling-count());
animation: x calc(var(--d)*sibling-count()) infinite
linear(0, 0 var(--_s), 1, 0 var(--_e), 0);

• 使用 sibling-index()/sibling-count() 自动计算索引与总量,无需额外 JS。

5. 浏览器兼容性与注意事项
• 目前主要支持 Chromium 内核(Chrome、Edge),Firefox 与 WebKit 尚在推进中。
• 某些变量可能需通过 @property 注册以解决兼容性问题。

6. 扩展与变体
• 可设计多个重叠区间(N+1 ranges)使动画出现过渡重叠(overlapping)效果。
• 原理一致:通过调整控制点范围改变动画逻辑,可产生更复杂的节奏模式。

7. 总结
• linear() 函数原为实现复杂缓动曲线而生,但结合现代 CSS 特性(变量、siblings 函数)可实现可编程化动画逻辑。
• 提供一种无需 JS、结构清晰、可扩展的纯 CSS 动画新范式。


author Temani Afif
1
#优质博文 #前端
50 Reasons to Build a Website
以 50 个生活化的理由,回答 “为什么在 2025 年仍然要建网站” 这个问题,我喜欢这些理由。
「你的乐队需要有一个网站,这是肯定的」
「你刚开始接触观鸟,你想要一个网站来发布你看到的酷鸟」
「你认为网络技术可以像油画和画布一样,成为艺术家的工具。你制作网站就像画家作画一样」

author Chris Coyier
👍1
#优质博文 #JavaScript #前端
太深入了 orz
Why typeof null === object

AI 摘要:本文系统回顾了 typeof null === "object" 的历史与技术背景,从现代 JavaScript 引擎的内存标记机制 (pointer tagging) 到最初的 Netscape 实现原理,解释了这一“bug”如何产生并延续至今。作者复原了早期 C 语言实现及源码宏定义,揭示 null 被识别为对象的根本原因是早期 32 位系统的对齐与标记约定。尽管这一问题可轻易修复,但考虑到巨大的兼容性影响,标准委员会选择保留这一行为,使它成为语言历史上的经典遗产。


author Piotr Zarycki
#优质博文 #HTML #WCAG #前端 #语义化
HTML’s Best Kept Secret: The output Tag
本文介绍了 HTML 中一个鲜为人知但功能强大的 <output> 标签,它能在网页上自然地显示计算或用户操作结果,并具备天然的无障碍(Accessibility)支持,但却一直被忽略。

author Den Odell
👍2
#优质博文 #AI #MCP #GitHub #MCP #开源
Accelerate developer productivity with these 9 open source AI and MCP projects

AI 摘要:GitHub 携手 Microsoft OSPO、Copilot 与 VS Code 团队,赞助了九个基于 Model Context Protocol (MCP) 的开源项目,以促进 AI 工具与开发平台的深度结合。这些项目聚焦三大主题:框架与平台集成、AI 增强的开发体验、以及自动化与编排。

[以下是方便搜索索引的大纲(AI 生成),请读原文]
1. 框架与平台集成
• fastapi_mcp:将 FastAPI 端点暴露为安全的 MCP 工具,提供统一基础设施与认证机制。
• nuxt-mcp:面向 Nuxt 应用的调试与路由工具,帮助模型理解 Vite/Nuxt 架构代码。
• unity-mcp:连接 Unity 引擎 API,赋予 AI 管理游戏资产、场景和脚本的能力,实现智能自动化游戏开发。

2. 开发者体验与 AI 增强编码
• context7:提取项目中与版本关联的文档与示例,直接嵌入 LLM (Large Language Model) 提示上下文。
• serena:提供语义检索与代码编辑功能,支持面向代理(agent-driven)的编程流程。
• Peekaboo:分析 Swift 代码界面,为 AI 助手提供可操作的 GUI 自动化上下文。
• coderunner:让 LLM 能在本地沙盒中自动执行与安装依赖,实现即时代码运行与结果反馈。

3. 自动化、测试与编排
• n8n-mcp:为 n8n 平台注入 AI 驱动的工作流自动化,优化节点理解与流程创建。
• inspector:测试与调试 MCP 服务器的工具,支持协议握手检查、OAuth 流程追踪与安全评估模拟。
2025/10/19 14:29:30
Back to Top
HTML Embed Code: