还搜到了这个，小破站其实早就全面切换到 AVIF 了：
https://www.bilibili.com/opus/775386423432839251

结论可以直接拿来用：
2022 年以前，B 站主流图片格式为 WebP，在对基础设施成本做回顾的过程中，定位到静态资源 CDN 成本是重要的组成部分。随着业界技术的逐渐成熟，经过相关调研，我们认为 AVIF 在 B 站大规模落地存在可行性。

在相同格式相同编码器下，可以简单的认为编码速度、图像质量与图片体积构成一个不可能三角，需要通过调整编码速度参数（下称 speed）与图像质量参数（下称 quality），在三者之间做取舍。

我们选取了三百万线上真实的缩略图请求，于实验环境进行回放，尽可能贴近 B 站实际使用场景。对同一个缩略请求，我们会使用线上现有编码参数，生成 PNG 和 WebP 两个版本，并用几个不同档位的 speed 和 quality，生成若干个 AVIF 版本，其中 PNG 被认为是无损格式，用作比较基准。

PSNR 可以被用于衡量原图与编码后图片的差异大小，一般大于 30 dB 即可认为人眼较难察觉出图像差异，大于 20 dB 被认为人眼观感差异不明显。PSNR 不能代替人类主观评价，但定量实验中，我们需要一个客观指标。无特别描述的前提下，下文提及 WebP/AVIF 的图像质量时，指的是 PSNR ( PNG → WebP ) 和 PSNR ( PNG → AVIF ) 的数值大小。

经过持续数天的流量回放实验，我们有以下定性结论：

1. speed 对编码耗时影响显著，对图像质量与图片体积影响不大。

2. 相同 speed/quality 的前提下，图片越大，AVIF 相对 WebP 的体积优势越明显。

3. 相同 speed/图片大小 的前提下，质量(quality)越高，AVIF 相对 WebP 的体积优势越明显。

对齐图像质量（PSNR 差值不超过 1）的前提下，我们有以下定量结论：

1. B 站主流缩略图场景下，AVIF 相比 WebP 平均体积优化在 35% 左右。

2. B 站主流缩略图场景下，AVIF 相比 WebP 耗时增长 4 ~ 5 倍，图片越大，耗时增长越明显，视频预览图等超大图场景，耗时增长 20 倍以上。

B 站主流缩略图场景下，AVIF 4 线程编码耗时约为单线程的 73%，CPU 开销是单线程的 115%，且进一步增大并发度的收益不高。

karminski-牙医@karminski3: HuggingFace 上了一个新功能，只要之前在 "个人设置->本地APP和硬件" 中添加了硬件。就能在新模型的模型卡下面看到自己的硬件能不能运行这个模型。特别方便。
图1是我的M2Ultra 128G，可以看到能运行这个模型的各种量化版本。图2则是我的3080Ti，可以看到哪个都不能运行哈哈哈哈。

AI 摘要：本文详细阐述了一种创新的 CSS 技术，通过单个自定义属性（如 --lqip:192900）实现低质量图像占位符（LQIP），无需额外标记或 JavaScript。作者对比了现有 LQIP 方案（如 BlurHash、Gradify 等），指出其依赖复杂标记或脚本的缺点。核心方案是将图像信息压缩为 20 位整数，通过 CSS 解码并渲染为 3×2 网格的径向渐变叠加，模拟模糊效果。文章还探讨了 CSS 数值限制、位操作实现、颜色空间选择（Oklab），以及通过二次插值优化渐变平滑度。最后提供了替代方案（如单色填充）和未来 HTML 属性 attr() 的展望。

1. CSS-only模糊图像占位符（LQIP）技术

• 方法：通过单一CSS自定义属性（--lqip）实现模糊占位符，无需额外标记或JavaScript。

<img src="…" style="--lqip:192900">

• 优势：
• 极简：仅需一个整数属性，不污染HTML结构。
• 非侵入性：无需包装元素、长数据字符串或复杂脚本。
• 即时渲染：纯CSS方案在加载时立即显示。

2. 与其他LQIP方案的对比
• 传统方案：
• 低分辨率图片（如WebP/JPEG）、SVG形状优化（SQIP）、BlurHash（需JS解码）。
• 纯色/渐变占位符：如Canva/Pinterest的纯色填充，或Gradify的CSS渐变近似。
• 缺点：
• 其他CSS方案常需冗长内联样式或数据URL，增加标记复杂度。
• BlurHash需JS解码，牺牲了纯CSS的即时性。

3. CSS整数编码与解码
• 编码限制：
• CSS整数值范围受限（-999,999至999,999），有效信息量约20位（2^20种配置）。
• 编码方案：
• 基础颜色（8位）：使用Oklab色彩空间（2位亮度+3位a/b坐标）。
• 6个灰度组件（12位）：3×2网格布局，每个组件2位。
• 解码技术：
• 通过CSS的calc()、mod()和round(down)模拟位操作（移位和掩码）。

--bits: mod(round(down, calc(var(--packed-int) / 64)), 4);


4. 渲染实现
• 径向渐变网格：
• 6个径向渐变覆盖3×2网格，叠加基础颜色。
• 使用二次缓动模拟双线性插值，避免硬边，实现平滑模糊效果。

background-image:
radial-gradient(50% 75% at 16.67% 25%, var(--lqip-ca-clr), transparent),
linear-gradient(0deg, var(--lqip-base-clr), var(--lqip-base-clr));


5. 备选方案与未来改进
• 早期尝试：
• 四角色混合（因混色效果差放弃）。
• 单一纯色占位符（简单但缺乏细节）。
• 未来方向：
• 使用HTML属性（如lqip="192900"）替代CSS变量，依赖attr() Level 5规范。

6. 局限性
• 视觉粗糙：相比BlurHash等方案，模糊效果较基础。
• 兼容性：依赖CSS图像的RSS阅读器可能不支持。

AI 摘要：本文全面讲解了 TanStack Table —— 一款支持多框架（如 React、Solid、Vue 等）的无头表格库。文章首先介绍了 TanStack Table 的概念、背景以及由 React Table 演变而来的历史，强调其完全自定义的 UI 与轻量优势。接着，文中详细描述了在 React 项目中使用 TanStack Table 的各个环节，包括基本功能（如远程数据获取、排序、分页、过滤）与高级功能（如内联编辑、分组、列扩展、列缩放等）的实现步骤，并通过代码示例演示了如何构建简单表格、实现自定义样式组件以及添加全局与列级搜索功能。最后，文章对比了 TanStack Table、Material React Table 与 Material UI Table 的异同，并解答了常见问题，为开发者在定制化与预制组件之间做选择提供了参考建议。

1. TanStack Table 简介
• 定义与特点：介绍 TanStack Table 的概念，说明其无头设计、跨框架兼容以及完全自定义 UI 的特性。
• 发展历程：说明 React Table 如何演变为 TanStack Table，强调 TypeScript 重写后的性能和功能提升。

2. React 中使用表格的场景
• 用途说明：举例说明表格在展示结构化数据（如财务报告、排行榜、定价对比）中的应用场景。
• 案例介绍：提及 Airtable、Asana、Google Sheets、Notion 等产品以及大厂的使用实例。

3. TanStack Table 核心功能解析
• 基本功能：包括自定义 UI、远程数据请求、搜索、列过滤和排序。
• 高级功能：涉及自定义排序和过滤、分页、行编辑、扩展行视图、固定表头、响应式设计、列缩放等。

4. 快速上手与迁移指南
• 迁移步骤：详细列出从 React Table v7 升级到 TanStack Table v8 的步骤，指出关键改动（如 Hook 名称、属性名称修改）及代码调整。
• 安装与示例：提供从零开始的安装命令和基础表格实现的完整代码示例。

5. 动态数据展示与 API 调用
• Axios 请求示例：展示如何利用 Axios 从 TVMAZE API 获取数据，并结合 useReactTable 构建动态表格。
• 组件拆分：通过创建独立的 Table.tsx 文件详细讲解数据与列配置的交互实现。

6. 自定义样式与增强功能
• 样式定制：通过示例介绍如何使用自定义组件（例如徽章展示 genres、时间格式转换）来改造单元格显示效果。
• 搜索、排序、分组：分别介绍添加全局搜索、列级搜索、排序功能的实现原理与代码示例。
• 列缩放：详细说明如何通过 API 添加列宽调整功能，并展示实际效果。

7. TanStack Table 与 Material 系列表格库对比
• 对比表格：从类型、UI 框架、自定义程度、依赖关系、功能丰富度等角度对比 TanStack Table、Material React Table 和 Material UI Table。
• 选择建议：根据需求灵活选择适合项目的表格解决方案。

8. 常见问题解答 (FAQ)
• 针对 React Table 历史变更、各表格库的区别和创建 React 表格的最佳实践等问题提供解答。

9. 结论
• 总结如何利用 TanStack Table 构建高效定制化的表格 UI，并鼓励读者在合适的场景下避免重复造轮子，提升开发效率。

LogRocket Blog

A complete guide to TanStack Table (formerly React Table) - LogRocket Blog

Discover how to use TanStack Table, formerly known as React Table, to build a table UI for a variety of use cases.

紡ぐ四季に彩りを
#ブルアカ #Bluearchive

AI 摘要：本文详细介绍了在网页中嵌入透明视频的技术挑战与实现方法。尽管透明视频在网页设计中具有巨大潜力（如叠加内容、动态形状变化等），但由于浏览器兼容性问题（Chrome 支持 VP9 格式，Safari 支持 HEVC 格式），开发者需提供多格式视频并动态适配。文章提出两种方案：
• 简易方案：通过合成视频与背景颜色模拟透明效果（如 Typeform 的案例），适用于背景抽象的场景。
• 真实方案：分别导出 HEVC（Safari）和 VP9（Chrome）格式的透明视频，通过 <video> 标签的多源加载实现跨浏览器兼容。
此外，文章还提供了视频转换工具（如 Rotato Converter、FFmpeg）的具体操作指南和代码示例。

1. 透明视频在网页中的应用潜力
• 透明视频（带Alpha通道）可实现创意效果，例如：
• 在HTML内容上方叠加视频
• 在另一个视频上叠加播放
• 动态改变视频形状
• 打破传统视频的“方框”外观，与页面内容自然融合

2. 当前技术挑战
• 浏览器兼容性问题：
• Safari支持HEVC/H.265格式的透明视频，但不支持VP9/WebM的透明通道。
• Chrome支持VP9/WebM的透明视频，但不支持HEVC的透明通道。
• 需同时提供两种格式以覆盖主流浏览器。

3. 实现透明视频的两种方法
• 简易方法（“障眼法”）：
• 适用于背景为纯色或抽象动态的场景。
• 将前景视频与背景视频合并为单一文件，通过颜色匹配模拟透明效果（如Typeform的案例）。
• 标准方法（真实透明通道）：
• 需分别导出HEVC（.mov）和VP9（.webm）格式的视频文件。
• 使用HTML5 <video>标签嵌套多个<source>，让浏览器自动选择兼容格式。

4. 视频转换工具与步骤
• 工具推荐：
• Rotato Converter：免费工具，一键转换HEVC和VP9格式。
• FFmpeg：命令行工具，支持高级参数调整（如CRF控制质量/大小）。
• 转换步骤：
1. 从编辑软件（如Rotato、Premiere）导出带Alpha通道的原始视频（建议720p）。
2. 转换为HEVC（Safari兼容）和VP9（Chrome兼容）。
3. 调整参数（如-crf控制压缩质量，-preset影响编码速度）。

6. 关键注意事项
• 文件大小优化：透明视频文件较大，需平衡质量与加载速度。
• 测试验证：在不同浏览器中检查透明效果是否生效。

AI 摘要：本文深入分析了 Web 和 EPUB 环境下数学公式渲染的常见问题，如浏览器兼容性差、EPUB 阅读器限制（如不支持 JS/SVG）、字体对齐困难等。作者提出了一种基于 Typst 的解决方案 Gladest，强调其“通用性”、“便利性”和“兼容性”三大设计原则。文章详细剖析了排版中的核心问题（如基线对齐、字体参数差异），并解释了 Gladest 如何通过 Typst 的轻量化工具链和 Rust 的高性能实现高效渲染。此外，作者呼吁字体厂商提供更友好的 Web Font 支持以改善排版体验，并分享了 Gladest 在解决多系统单位不一致性（如 em 单位标准化）和边距调整上的技术细节。

1. Web 与 EPUB 公式渲染的痛点
• 数学公式在 Web 和 EPUB 中的渲染存在兼容性问题，尤其在 EPUB 环境中（如电子墨水屏设备）表现更差，缺乏 JavaScript 和 SVG 支持。
• 主流工具（如 MathML、MathJax、KaTeX ）在特定场景下存在局限性，如字体兼容性、无 JS 环境支持等。

2. Gladest 的设计目标与实现
• 通用性：统一不同场景（博客、EPUB）的公式渲染工具，减少工具链碎片化。
• 便利性：基于 Typst（Rust 生态）开发，避免 LaTeX 的复杂性和历史包袱，支持LaTeX语法兼容层（mitex）。
• 高性能：利用 Rust 多线程能力，渲染速度显著优于传统方案（如 GladTeX ）。

3. 排版对齐的核心挑战
• 字体与基线对齐：图文混排时需处理不同字体的基线、x 字高、大写高度等参数差异，CSS 现有属性难以完美解决。
• 跨系统单位统一：通过 em 单位协调 Typst 与 Web 的渲染尺寸，确保公式在不同分辨率设备下的清晰度。
• Typst 的边距问题：Typst 硬编码的边距需通过 CSS 反向调整（如margin: -0.455em）以避免布局异常。

4. 行业呼吁与解决方案
• 提倡字体厂商提供分块优化的 Web Font（如WOFF2格式），以改善跨平台渲染一致性，IBM Plex Sans CJK 字体为范例。
• 强调开发者需主动适配字体参数，确保垂直对齐的精准性。

5. 未来计划
• 完善 Gladest 的自定义字体功能，增强基础稳定性后扩展字体元信息解析能力。

螺莉莉的数据中心

聊聊 Web 与 EPUB 的公式渲染问题 | 螺莉莉的数据中心

如果你曾经尝试写过有大量数学公式的博客文章，那我相信你一定因为数学公式渲染的问题而略微痛过。而如果你尝试在 EPUB 里面排大量数学公式，额……朋友，你现在还好吗……
如果你只是单纯想在浏览器里面把一个公式渲染出来，其实这并不难。一方面我们有
MathML 这样的标准，另外一方面像是 MathJax、KaTeX 这类渲染库都能把事情做好。但如果你稍微有那么一丢丢额外的追求，那么事情就会变得无比麻烦。
比如：Chromium 的 MathML 兼容性其实没你想象当中的好，Firefox 这边如果你把数学公…