The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the props-bot label.

If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message.

Co-authored-by: westonruter <westonruter@git.wordpress.org>
Co-authored-by: mukeshpanchal27 <mukesh27@git.wordpress.org>
Co-authored-by: joemcgill <joemcgill@git.wordpress.org>
Co-authored-by: swissspidy <swissspidy@git.wordpress.org>

To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook.

Thanks for this, @westonruter. I assume that making use of OD functionality directly when enabled is needed because there is not a better way to make sure that the auto-sizes functionality runs late enough that any alterations that OD makes to the loading attribute can be taken into account before we add auto to the front of the sizes attribute?

@joemcgill Here OD is being leveraged as a way to make modifications to the output-buffered page, which Image Prioritizer may have also modified to add/remove loading=lazy from img elements based on whether they appear in the initial viewport or not. So yeah, Auto Sizes may be missing opportunities to add sizes=auto since it doesn't know for sure whether an image should be lazy-loaded or not, since the server-side heuristics are limited. With the URL metrics in hand, Image Prioritizer can be more accurate about adding or removing lazy-loading, and then this integration here follows up to amend sizes=auto where appropriate.

@westonruter, thanks for clarifying. I think there is a slight by important difference between:

a) This plugin uses OD when available to more accurately apply sizes=auto, and
b) This plugin uses OD to fix a potential bug when Image Optimizer (or another OD dependent plugin) modifies the lazy loading attribute of an image after sizes=auto has been applied.

I assumed that the goal of this was to address the latter, which is why I was asking about wether there is an alternate way that this plugin could account for any cases (including but not limited to OD) where the loading attribute is modified later than we currently apply sizes=auto.

@joemcgill actually it's both, isn't it? It does more accurately add sizes=auto, while at the same time it will fix up any sizes=auto being applied to images which have had their lazy-loading updated after initial template rendering with server-side heuristics.

@joemcgill I fixed the merge conflict. (Difficult to do on mobile!)

@joemcgill actually it's both, isn't it?

Right now this PR is addressing both, but what I'm trying to better understand is what the primary objective of this PR is, since it isn't related to an open issue.

While I see OD being very valuable tool in potentially fixing various types of bugs where third party plugins (like Image Prioritizer) modify the loading attribute of an image after we've applied sizes=auto, I want to avoid having OD be a dependency of this functionality so we can keep the auto-sizes improvements decoupled from OD while working towards including that functionality directly in WP Core.

The two ways that I'd prefer to address the Image Prioritizer issue would be to either:

1. Find an OD agnostic fix that would make sure we're modifying sizes late enough where the Image Prioritizer modifications run first.
2. Handle the compatibility issue in Image Prioritizer, since it is the plugin that would be responsible for the incompatibility if auto-sizes were in Core.

@joemcgill

Right now this PR is addressing both, but what I'm trying to better understand is what the primary objective of this PR is, since it isn't related to an open issue.

Oops. I failed to link this PR to the open issue. See #1099.

1. Find an OD agnostic fix that would make sure we're modifying sizes late enough where the Image Prioritizer modifications run first.

Since Image Prioritizer always applies changes to lazy-loading (either adding loading=lazy or removing the loading attribute) after the template has rendered during output-buffer processing, I don't see how there is any alternative to introducing a new OD tag visitor as this PR proposes.

I want to avoid having OD be a dependency of this functionality so we can keep the auto-sizes improvements decoupled from OD while working towards including that functionality directly in WP Core.

OD is not made a dependency with this PR. Rather, it integrates with OD if it is active. I kept all the OD functionality in a separate file to ensure it doesn't trip up core merge.

2. Handle the compatibility issue in Image Prioritizer, since it is the plugin that would be responsible for the incompatibility if auto-sizes were in Core.

The inclusion of sizes=auto could be applied in Image Prioritizer directly instead of doing it in the Auto Sizes plugin. But from #1088 (comment) I understood sizes-specific optimizations should be out of scope for Image Prioritizer.