优先使用 WebP 版本的图片

[neveler]

优先使用 WebP 版本的图片

Note

本 PR 并不包含实际的 webp 文件，可以配合 #350

介绍

插件在构建时会扫描所有 src 以 /assets/ 开头的 <img> 标签，并在存在 WebP 版本时将其改写为 <picture> 以优先使用 WebP 格式的图片。

若图片路径为 /assets/test/a.png，则对应的 WebP 版本路径应为 /assets/test/a.png.webp。

<picture><source srcset="/HMCL-docs/PR16/assets/img/docs/about-questions/img.png.webp" type="image/webp"><img src="/HMCL-docs/PR16/assets/img/docs/about-questions/img.png" alt=""></picture>

Closes #318

[Glavo]

自 GitHub 今年 8 月的更新后，GitHub 现在对 WebP 有良好的原生支持。而且我们也更新了 HMCL 主页，现在仅使用 WebP 图片。我觉得没有必要在 HMCL-docs 中使用 PNG 图片了。

[neveler]

自 GitHub 今年 8 月的更新后，GitHub 现在对 WebP 有良好的原生支持。而且我们也更新了 HMCL 主页，现在仅使用 WebP 图片。我觉得没有必要在 HMCL-docs 中使用 PNG 图片了。

在生产图片时 WebP 似乎并不是主流的图片格式。无论是常见的截图工具、设计工具，还是系统级的截图快捷方式，默认产物几乎都不会是 WebP。这意味着贡献者在创建文档或提交图片时，大概率仍需先在本地进行格式转换，增加了额外步骤和潜在阻力。

基于这一点，我仍计划提交一个基于 GitHub Action 实现的自动为非 WebP 图片生成对应的 WebP 版本的 PR 这样既能保持网站的图片优先 WebP 以节省网络流量又能避免社区贡献者可能的手动处理格式转换的负担。

[Glavo]

基于这一点，我仍计划提交一个基于 GitHub Action 实现的自动为非 WebP 图片生成对应的 WebP 版本的 PR 这样既能保持网站的图片优先 WebP 以节省网络流量又能避免社区贡献者可能的手动处理格式转换的负担。

我还是觉得意义不大，这种自动 PR 也可能会给贡献者带来困扰。我觉得 PR 开发过程中外部贡献者完全可以使用 PNG/JPEG/GIF 等图片，在合并前由有权限修改 PR 的贡献者转换一次就行了。

[neveler]

这种自动 PR 也可能会给贡献者带来困扰。

可以具体说说是什么困扰吗？

[burningtnt]

这种自动 PR 也可能会给贡献者带来困扰。

可以具体说说是什么困扰吗？

自动转换会创建一个不小的 commit。此外，#350 引入的手动触发系统实际上并不能正常运行 ———— 对主仓库有 write 权限的人不能手动触发位于其他仓库中的 workflow。

我希望能够在当前 PR 中将全部 PNG 图片一次转换为 WEBP，并在单独的 PR 中支持通过 '/preview normalize images'（具体命令待后续讨论）来主动将 PNG 图片转换为 WEBP。

[neveler]

自动转换会创建一个不小的 commit。

这里的 不小 指的是提交体积吗？实际上，只有首次转换时生成的提交体积会比较大。如果原始图片未发生变化，那么其对应生成的 WEBP 文件也不会改变，因此之后的自动转换提交通常不会太大。

此外，#350 引入的手动触发系统实际上并不能正常运行 ———— 对主仓库有 write 权限的人不能手动触发位于其他仓库中的 workflow。

这个手动触发机制最初的设计目的是为了在合并该 PR 之初，对当前仓库中的所有图片进行一次性批量 WEBP 转换。因为默认情况下，转换流程只会在 PR 中包含指定资源目录下的图片变更时才会触发。

我希望能够在当前 PR 中将全部 PNG 图片一次转换为 WEBP

我希望这类转换由工作流在固定环境中统一完成，而不是由用户在本地手动处理。由于工具链、运行环境等因素可能产生细微差异，导致同一张图片生成的 WEBP 文件出现不完全一致的情况，因此本 PR 中并未直接提交转换后的 WEBP 文件。

并在单独的 PR 中支持通过 '/preview normalize images'（具体命令待后续讨论）来主动将 PNG 图片转换为 WEBP。

当时确实考虑过这种方案，但这似乎需要要求工作流修改贡献者分支，存在一定安全隐患。因此 #350 最终采用了创建新 PR 的方式来自动转换图片。