img doesn't seem to handle opaque responses from fetch API

[wanderview]

The img element processing model uses Fetch API to load the image data in step 22 here:

https://html.spec.whatwg.org/#update-the-image-data

It basically just says:

⌛ Fetch request. Let this instance of the fetching algorithm be associated with image request.

The resource obtained in this fashion, if any, is image request's image data. It can be either CORS-same-origin or CORS-cross-origin; this affects the origin of the image itself (e.g. when used on a canvas).

It does reference CORS-cross-origin here, but it doesn't actually say to reach inside the filtered opaque response and extract the nested response's body.

This is kind of a nit at this point, but it would be nice if the body consumption was more explicitly spelled out.

[andreubotella]

This also seems to apply to <link rel="icon"> and <link rel="stylesheet">, even though their response decoding steps are quite underspecified. Though it's odd that fetching /favicon.ico, and the image's "reacting to environment changes" algorithm (see #1643) don't have this issue.

And I don't think this is a nit – the way this is currently spec'd, you'd have <img src="https://some.crossorigin.site/image.png"> failing, even though it's clear it should work.