图片资源

W3C 工作草案

本版本:
https://www.w3.org/TR/2021/WD-image-resource-20210604/
最新发布版本:
https://www.w3.org/TR/image-resource/
最新编辑草案:
https://w3c.github.io/image-resource/
上一版本:
https://www.w3.org/TR/2021/WD-image-resource-20210426/
编辑:
Aaron Gustafson (微软公司)
Rayan Kanso (谷歌公司 Inc.)
Marcos Cáceres (W3C)
参与方式:
GitHub w3c/image-resource
提交议题
提交历史
拉取请求

摘要

本文档定义了“图片资源”概念及其对应的 WebIDL ImageResource 字典。Web API 可以在 HTMLImageElement 不适用或无法使用的情况下(例如在 Worker 中),使用 ImageResource 字典来表示图片资源。

本文档状态

本节描述了本文档发布时的状态。其他文档可能会取代本文件。当前 W3C 出版物列表及本技术报告的最新修订版可在 W3C 技术报告索引(https://www.w3.org/TR/)查阅。

警告

本规范尚不稳定。 未参与讨论的实现者可能会发现规范发生不兼容的更改。

本文档由 Web Applications 工作组 以工作草案形式发布。 本文档拟成为 W3C 推荐标准。

建议针对本规范的讨论使用 GitHub Issues。

作为工作草案发布并不意味着获得 W3C 会员认可。

本文件为草案版本,可能随时被更新、替换或废止。引用本文档时应只作为进行中的工作。

本文档由遵循 W3C 专利政策 的团体制作。 W3C 维护一份 与团体成果相关的专利公开列表; 该页面也包括披露专利的相关说明。任何个人如果实际知晓某项专利包含 必要声明 信息,必须依据 《W3C 专利政策》第6节 进行披露。

本文件受 2020年9月15日 W3C 流程文档管辖。

1. 引言

Web 应用程序通常会接收开发者提供的图片资源,在 HTML 文档之外进行显示(例如,在操作系统、在浏览器 UI 中等)。本规范定义了一个 WebIDL 字典,用于描述图片以及获取该图片资源的位置。用户代理随后可以利用这些额外信息,选择最适合在终端用户设备显示、或最契合用户偏好或环境的图片。

2. 隐私与安全注意事项

获取图片资源可能会暴露用户的 IP 地址。建议用户代理在开发者提供 图片资源时及时获取所选图片,并在需要时进行存储复用。这有助于限制对用户位置的长期跟踪。

3. 图片资源

一个图片资源包括:

src
一个用于获取图片数据的 URL。
sizes
一个可选的 字符串,表示图片的尺寸,语法与 link 元素的 sizes 属性一致。
type
一个可选的 图片 MIME 类型。
label
一个 字符串,表示图片的可访问名称。

在 API 中,图片资源用 ImageResource 字典表示。

在 [JSON] 中,图片资源用对象表示。

4. ImageResource 字典

WebIDLdictionary ImageResource {
  required USVString src;
  DOMString sizes;
  DOMString type;
  DOMString label;
};

4.1 src 成员

ImageResource 的 src 是用户代理用于 获取图片数据的 URL。

4.2 sizes 成员

sizes 成员等价于 link 元素的 sizes 属性,处理方式一致。

当有多个 ImageResource 字典可用时,用户代理可以使用 sizes 值来决定哪个图片最适合用于显示(并忽略不合适的)。

Note
sizes 成员可以包含多个用空格分隔的尺寸值,用以适配具有多尺寸的图片格式(如 ICO 容器格式)。
const image = {
  src: "path/to/image.ico",
  sizes: "16x16 32x32 64x64",
  type: "image/vnd.microsoft.icon",
};
some.api.doSomething(image);

4.3 type 成员

type 成员表示图片资源的 图片 MIME 类型。用户代理可以忽略其不支持的媒体类型。

ImageResource 没有默认的MIME 类型。其 type 纯粹是建议性的。用户代理必须使用 专门用于嗅探 图像的规则来确定图像资源的 计算所得的 MIME 类型。

4.4 label 成员

label 是 ImageResource 的 字符串,为图片提供 可访问名称。

实现者必须为其向用户暴露的每一个 ImageResource 推导可访问名称。

除非 ImageResource 的 可访问名称 能从其上下文中的 外部标签推断得到,强烈建议作者添加 label。例如在 manifest 场景中,name 或 short_name 就可为 icons 数组的所有成员提供外部标签(前提是没有定义 label)。

如果既没有显式的 label,也没有 外部标签,但 type 支持提供 嵌入式可访问名称,实现者可以选择延迟 label 分配,直到 src 被获取和处理。如果 src 提供了 嵌入式可访问名称,实现者必须将 label 设置为该名称值。

5. 从 API 处理 ImageResource

从 API 处理 ImageResource 的步骤如下。算法接收一个 ImageResource input,返回一个 图片资源。

  1. 令 base URL 为当前使用该字典时相关设置对象的API 基准 URL。
  2. 新建一个 图片资源,命名为 image。
  3. 将 image 的 src 设为 input.src 和 base URL 按 URL 解析 处理的结果。如果解析失败,抛出 TypeError。
  4. 如果 input 的 sizes 成员存在:
    1. 将 image 的 sizes 设为 以 input.sizes 作为一个 sizes 属性、link 元素、并且其 rel 属性包含 token icon 来解析的结果。如果解析失败,抛出 TypeError。
  5. 如果 input 的 type 成员不为空字符串且存在:
    1. 如果 type 不是图片 MIME 类型,抛出 TypeError。
    2. 将 image 的 type 设为 input.type。
  6. 将 image 的 label 设为推导所得的可访问名称的结果。
  7. 返回 image。

6. 从 JSON 处理图片资源

要从 JSON 处理图片资源,给定一个 JSON 对象 input 和一个 URL base。它返回一个 有序映射。

  1. 如果 input 不是 对象 类型,返回失败。
  2. 如果 input["src"] 不是 字符串 类型,返回失败。
  3. 令 src 为以 input["src"] 及 base 作为基准 URL 进行 解析的结果。
  4. 如果 src 为失败,返回失败。
  5. 令 image 为一个新的 有序映射。
  6. 将 image["src"] 设为 src。
  7. 如果 input["sizes"] 类型为 字符串 且长度大于零:
    1. 将 sizes 设为以 input["sizes"] 作为 sizes 属性、link 元素,并且其 rel 属性包含 icon 解析的结果。
    2. 如果 sizes 为失败,返回失败。
    3. 将 image["sizes"] 设为 sizes。
  8. 如果 input["type"] 是 字符串,且长度大于零:
    1. 令 mime 为 解析 input["type"] 的结果。
    2. 如果 mime 为失败,返回失败。
    3. 将 image["type"] 设为 mime 的精华值。
  9. 将 image["label"] 设为推导可访问名称的结果。
  10. 返回 image。

7. 获取图片资源

获取图片资源的步骤如下。该算法接受一个图片资源 image,以及一个可选的 Request request,返回一个 Response。

  1. 如果 request 为 undefined:
    1. 将 request 设为一个新的 Request。
    2. 将 URL 设为 image 的 src。
    3. 将 Destination 设为 "image"。
    4. 将 Client 设为当前上下文对象的 相关设置对象。
  2. 如果 request 的 Client 为 null,抛出 TypeError。
  3. 使用 request 执行一次 fetch 并返回 Response。
Note

8. 推导可访问名称

为 图片资源 resource 推导可访问名称的步骤如下。它返回一个字符串。

  1. 如果 resource["label"] 是 字符串,返回 input["label"]。
  2. 否则,如 image 提供了嵌入式可访问名称,则返回该嵌入式可访问名称。
  3. 否则,如可用外部标签替代,则返回该外部标签。
  4. 返回 ""。

9. 支持嵌入可访问名称的图形格式示例

某些图形格式支持将嵌入式可访问名称作为图片内容的一部分嵌入。示例包括:

10. 一致性

除明确标记为非规范性的章节外,本规范中的所有创作指南、图示、示例和说明都是非规范性的。规范其它内容均为规范性内容。

本文中的 MAY、MUST、RECOMMENDED 等关键字,均应按 BCP 14 [RFC2119] [RFC8174] 的规定解释,仅当其全部大写时才具有本意。

A. 参考文献

A.1 规范性引用

[appmanifest]
Web Application Manifest. Marcos Caceres; Kenneth Christiansen; Mounir Lamouri; Anssi Kostiainen; Matt Giuca; Aaron Gustafson. W3C. 1 June 2021. W3C Working Draft. URL: https://www.w3.org/TR/appmanifest/
[fetch]
Fetch Standard. Anne van Kesteren. WHATWG. Living Standard. URL: https://fetch.spec.whatwg.org/
[html]
HTML Standard. Anne van Kesteren; Domenic Denicola; Ian Hickson; Philip Jägenstedt; Simon Pieters. WHATWG. Living Standard. URL: https://html.spec.whatwg.org/multipage/
[infra]
Infra Standard. Anne van Kesteren; Domenic Denicola. WHATWG. Living Standard. URL: https://infra.spec.whatwg.org/
[JSON]
The JavaScript Object Notation (JSON) Data Interchange Format. T. Bray, Ed.. IETF. December 2017. Internet Standard. URL: https://datatracker.ietf.org/doc/html/rfc8259
[mimesniff]
MIME Sniffing Standard. Gordon P. Hemsley. WHATWG. Living Standard. URL: https://mimesniff.spec.whatwg.org/
[RFC2119]
Key words for use in RFCs to Indicate Requirement Levels. S. Bradner. IETF. March 1997. Best Current Practice. URL: https://datatracker.ietf.org/doc/html/rfc2119
[RFC8174]
Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words. B. Leiba. IETF. May 2017. Best Current Practice. URL: https://datatracker.ietf.org/doc/html/rfc8174
[svg]
Scalable Vector Graphics (SVG) 1.0 Specification. Jon Ferraiolo. W3C. 4 September 2001. W3C Recommendation. URL: https://www.w3.org/TR/SVG/
[url]
URL Standard. Anne van Kesteren. WHATWG. Living Standard. URL: https://url.spec.whatwg.org/
[webidl]
Web IDL. Boris Zbarsky. W3C. 15 December 2016. W3C Editor's Draft. URL: https://heycam.github.io/webidl/