Copyright © 2021 W3C® (MIT, ERCIM, Keio, Beihang). W3C liability, trademark and permissive document license rules apply.
This document defines the concept of an "image resource" and a
corresponding WebIDL ImageResource
dictionary. Web APIs can use the
ImageResource
dictionary to represent an image resource in contexts
where an HTMLImageElement
is not suitable or available (e.g., in a
Worker).
This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index at https://www.w3.org/TR/.
This specification is not stable. Implementors who are not taking part in the discussions will find the specification changing out from under them in incompatible ways.
This document was published by the Web Applications Working Group as a Working Draft. This document is intended to become a W3C Recommendation.
GitHub Issues are preferred for discussion of this specification.
Publication as a Working Draft does not imply endorsement by the W3C Membership.
This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress.
This document was produced by a group operating under the W3C Patent Policy. W3C maintains a public list of any patent disclosures made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s) must disclose the information in accordance with section 6 of the W3C Patent Policy.
This document is governed by the 15 September 2020 W3C Process Document.
Web applications often accept developer-provided image resources to be displayed outside of a HTML document (e.g., in the OS, in the browser UI, etc.). This specification defines a WebIDL dictionary that describes an image, and where that image resource can be fetched from. The user agent can then use this extra information to choose an image that is best suited to display on the end-user's device or most closely matches the end-user's preferences or environment.
Fetching an image resource can reveal the user's IP address. It is RECOMMENDED that user agents fetch the chosen image resources when provided by the developer, and store them for re-use if needed. This limits tracking the user's location over time.
An image resource consists of:
link
's sizes
attribute.
In an API, an image resource is represented as an ImageResource
dictionary.
In [JSON], image resource is represented as an object.
ImageResource
dictionary
WebIDLdictionary ImageResource
{
required USVString src
;
DOMString sizes
;
DOMString type
;
DOMString label
;
};
src
member
The src
of an ImageResource
is a URL from
which a user agent can fetch image data.
sizes
member
The sizes
member is equivalent to a link
element's sizes
attribute, and is processed in the same
manner.
When multiple ImageResource
dictionaries are available, a user
agent MAY use the sizes
value to decide which image
is most suitable for a display context (and ignore any that are
inappropriate).
sizes
member allows for multiple
space-separated size values in order to accommodate image formats
(such as ICO) that can act as a container for multiple images of
varying dimensions.
const image = {
src: "path/to/image.ico",
sizes: "16x16 32x32 64x64",
type: "image/vnd.microsoft.icon",
};
some.api.doSomething(image);
type
member
The type
member represents an image MIME Type
for the image resource. A user agent MAY ignore media types it does
not support.
There is no default MIME type for an ImageResource
. The
type
is purely advisory. User agents MUST use the
rules for sniffing images specifically to determine the
computed MIME type of an image resource.
label
member
The label
of an ImageResource
is a string
that provides the accessible name for the associated image.
Implementors MUST derive the accessible name for every
ImageResource
they expose to users.
Authors are strongly encouraged to add a label
unless the ImageResource
’s accessible name can be inferred
from an external label in its context. For example, in the
context of a manifest, the name
(or
short_name
) provides an external label for all
members of the icons
array that don’t have a
label
defined.
If neither an explicit label
nor an external
label is provided, but the type
supports
providing an embedded accessible name, implementors MAY choose to
defer assigning the label
until the
src
has been fetched and processed. If the
src
is found to provide an embedded accessible
name, implementors MUST update the label
to match
that value.
ImageResource
from an API
The steps to process an ImageResource
from an
API are given by the following algorithm. The algorithm takes an
ImageResource
input. It returns an image
resource.
src
and base URL. If
parsing the URL fails, throw a TypeError
.
sizes
member is present:
type
member is present and not the
empty string:
type
is not an image MIME Type, throw
a TypeError
.
type
.
To process an image resource from JSON, given a JSON Object input and a URL base. It returns an ordered map.
The steps for fetching an image resource are given by the following algorithm. The algorithm takes an image resource image, and an optional Request request. It returns a Response.
undefined
:
TypeError
.
The steps to derive the accessible name for an image resource resource are as follows. It returns a string.
Certain graphics formats support the inclusion of an embedded accessible name as part of the image’s contents. Examples include:
As well as sections marked as non-normative, all authoring guidelines, diagrams, examples, and notes in this specification are non-normative. Everything else in this specification is normative.
The key words MAY, MUST, and RECOMMENDED in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in: