```suggestion ```

It would be nicer I think to restructure this a bit so we periodically schedule a task to check (or do this as part of "update the rendering") as the current setup with invoking this from in parallel and then that algorithm having a note saying not to do that is rather weird and self-contradictory.

```suggestion otherwise.</p></li> ```

```suggestion <li><p>Let <var>delay load event</var> be true if the <code>img</code>'s <span>lazy loading ```

```suggestion ```

```suggestion ```

Maybe say "early" or "when layout is known" or so. In my mind it still loaded lazily.

Maybe we should find a more general location for the definition of "intersect the viewport", but I don't have strong opinions on where this should go, so I'll defer to others.

I don't fully know the reasoning for providing _both_ forms of width/height (via CSS & HTML attrs), so I mostly ripped this from your comment @annevk let me know if it's OK

Should we add an example, here or elsewhere?

Indentation here is slightly wrong. It needs to be aligned with the `<li>`.

This algorithm talks about an observer, what's the observer here? Perhaps they should add some high-level primitive we can use here? Also, since `<p>` is the only child of the `<li>`, there's no need for newlines before and after. Same for the next item.

I would drop 'auto' for now. That is a major interoperability concern. Just have lazyload to default to eager for now and then let pages to use lazy if wanted.

Please remove this newline and one newline between `</dt>` and `<dd>` as well as the one before `</dl>`.

I thought one of the major features of lazy loading was to not delay the main load event (aka body/Window load event)?

It would be easier to read if this returned a boolean.

This does not actually explain why that needs to be done.

```suggestion influence their behavior differently, sites might be able to more-easily identify specific user ``` Avoid RFC 2119 keyword here.

Calling the "compute the intersection" algorithm here seems wrong. It means that the next paragraph only applies for images that intersect according to this requirement. The point here is to differentiate between "obtain images immediately or on demand", which is now more like "follow the processing model for obtaining images immediately or follow the processing model for obtaining images on demand". That is, the "on demand" business is when you disable all images, but still want to be able to load some images by right clicking them and select "Load this image". (The spec only allows such a mode when scripting is disabled.)

The "Auto" state indicates the UA should choose which state out of "Eager" or "Lazy" to resolve to, so here I'm just calling it out explicitly, which I think is OK.

Why was this removed?

Why is there a requirement to enqueue a task to call this algorithm, if the first thing the algorithm does is enqueue a continuation task?

This seems to assume that the `auto` behavior is / will always be the same as `eager`, but the check a few lines before seems to assume `auto` is like `lazy`. Perhaps it's better to wait for the attribute to _change_ from its current setting?

This seems like it would eagerly load all disconnected images, which doesn't seem desired (see https://github.com/whatwg/html/pull/3752#issuecomment-484177815 ).

FWIW, I think we shouldn't have auto state at all, at least not if its behavior isn't clearly defined and not left to UA to decide. And it is super risky to have it as the default behavior (suddenly by default UAs can start to load iframes and images etc later).

I don't understand how going in parallel here is compatible with the processing model when this attribute is not present.

I don't understand how this works if we're in parallel.

It's unclear from the description how this vector is more unique than the `User-Agent` header. If they're equivalent, that's probably worth noting.

user agents should not*

defer fetching*

This needs rewording, an element does not load.

This isn't referenced, are we no longer doing range requests? Perhaps someone can point me to an up-to-date description of this feature?

Needs updating?

To save needing to fetch image metadata, could we first check if the `width` and `height` attributes are specified and assume the image dimensions from that?

Typo 🙂 ```suggestion user agent determines is reasonable to retrieve metadata.</p></li> ```

This isn't a dfn; it should be a link to another spec's definition. See https://github.com/whatwg/wattsi/blob/master/Syntax.md#cross-specification-cross-references

Don't use may here

Don't use must here

These steps should only run "If the full image is returned by this fetch". Probably also you need a guard like "If the resource type and data corresponds to a supported image format, as described below" (see step 24 of updating the image data").

You want to remove "it should be used and not refected" since that's not clear.

What if the element _does_ use srcset or picture? What are selected source and selected pixel density set to? In the next step you parse selected source, so your code will "crash" in that case currently.

Just noticed: you should wrap "fetch image metadata" in a `<dfn>`, so that it's easy to link to.

"should be rejected" is not very precise. Maybe "must not be used as metadata"?

"it should be used and not refetched" needs to be formalized, in terms of the "list of available images". In particular it seems like you'd want a nested series of steps that creates a cache key and stores it in the list. Cf. steps 6.2 and other usages of "key" in the "update the image data" algorithm.

This should just be element's node document's relevant settings object; see https://whatpr.org/html/3752/images.html#updating-the-image-data step 19.

urlString is not a defined variable at this point. Probably you need to copy a step similar to https://whatpr.org/html/3752/images.html#updating-the-image-data steps 4 and 6.1. (Although, you can use "return" instead of "abort this inner set of steps".) However, this raises an interesting and tricky question: how do you handle this for images with srcset, or images inside a picture? Maybe we need more extensive surgery :(. E.g. maybe we need to factor out more of that algorithm. Curious how this maps to Blink's implementation.

"the CSS boxes those" -> "the CSS boxes of those"

Should we be explicit that this mustn't happen if the primary fetch for the resource has begun?

I'm not sure how much hand-waving is ok here, but this seems pretty hand-wavey. We plan to use the metadata to lay out the image, right? Is that worth documenting as a possible consequence? ~~What happens if the response is a 404 or 500? Feels like we could call the image a failure at that point. We should probably do that for all not-ok responses, unless it looks like a consequence of making the range request (416).~~ What happens if the response is a 200? We'd download the whole image, would we download it again? Perhaps we'd add it to the image memory cache in that case? Or maybe terminate the fetch after fetching the metadata bytes? What happens if the response is a 206, but we fail to parse the start? Again, we could call the image a failure, and not bother fetching any more. What happens if the response is a 206, but the range starts at a point other than 0. It's pretty important to reject the response in this case, as reading it as if it were the start of the resource could leak data. What happens if the response is a 206, starts at 0, but returns fewer bytes than requested?

I don't think this works for `about:blank` and such, does it? What does this map to in say Blink's C++?

@jakearchibald could you please review this?

Shouldn't this be kept and something equivalent be added for lazyLoad?

You'll want to explicitly refer to and use https://fetch.spec.whatwg.org/#concept-request-add-range-header here

The first sentence here is good, but the others are not. This is not the image request, so it should not be associated as such. Instead, I'd say something like "Fetch request, and use the metadata contained in response as appropriate for the image."

No need for the `&#x231B; ` parts here and elsewhere.