Closed westonruter closed 2 weeks ago
@westonruter I would love to work on this ticket.
it seems the HTML Tag Processor code here should be updated to support adding auto to the SOURCE tags.
@westonruter I wanted to confirm whether adding SOURCE tag needs to be updated with HTML Tag Processor?
Not at that location since that is the Modern Image Formats plugin not the Enhanced Responsive Images plugin. I think you'd want to create a branch off of the branch for PR https://github.com/WordPress/performance/pull/1476 and then update the auto_sizes_apply_tag_parser_updates()
function introduced in that PR to apply changes to PICTURE > SOURCE
as well as IMG
.
Per https://github.com/WordPress/performance/issues/1446#issuecomment-2274643725:
I just realized a case where this drafted code using HTML Tag Processor might not work as expected, and that is specifically in relation to the
PICTURE
element output by Modern Image Formats. Enhanced Responsive Images is adding theauto
value at priority 10 of thewp_content_img_tag
filter:https://github.com/WordPress/performance/blob/e7313851f39749886a4ae0bacbcd620a6effce3d/plugins/auto-sizes/hooks.php#L79
However, Modern Image Formats is also using this same filter and priority to rewrite the
IMG
asPICTURE
:https://github.com/WordPress/performance/blob/e7313851f39749886a4ae0bacbcd620a6effce3d/plugins/webp-uploads/hooks.php#L769
Since the
auto-sizes
slug is alphabetically beforewebp-uploads
, then it seems theauto
value is injected first so that when thePICTURE
is generated by Modern Image Formats, it hasauto
in all thesizes
attributes as expected. However, this seems brittle. To be even more robust, it seems the HTML Tag Processor code here should be updated to support addingauto
to theSOURCE
tags. Otherwise, the priorities of the filters could be made distinctly different, either havingauto_sizes_update_content_img_tag()
run at a priority below 10 or havewebp_uploads_wrap_image_in_picture()
run at a priority over 10.Nevertheless, take note that Enhanced Responsive Images also has a
wp_content_img_tag
filter that runs at priority 9, so it would need to be bumped down to priority 8 if we go in that direction:https://github.com/WordPress/performance/blob/e7313851f39749886a4ae0bacbcd620a6effce3d/plugins/auto-sizes/hooks.php#L226
Lastly, Image Placeholders is also filtering
wp_content_img_tag
but at priority 20:https://github.com/WordPress/performance/blob/e7313851f39749886a4ae0bacbcd620a6effce3d/plugins/dominant-color-images/hooks.php#L166
I was worried that this would mean that
PICTURE
elements generated by Modern Image Formats would be broken with Image Placeholders. But this doesn't seem to be the case. Example image with picture element turned off:And with picture element turned on:
This is still working. Interestingly, the result is
--dominant-color: #8c7d58;
appearing on thePICTURE
tag whereasdata-dominant-color
anddata-has-transparency
remain on theIMG
tag. This is because we addedstyle="display:contents;"
to thePICTURE
in #1307, so Image Placeholders is accidentally amending thestyle
attribute on thePICTURE
tag as oppose to adding/updating thestyle
attribute on theIMG
tag:https://github.com/WordPress/performance/blob/e7313851f39749886a4ae0bacbcd620a6effce3d/plugins/dominant-color-images/hooks.php#L143-L147
Fortunately this didn't break anything, but we just got lucky. We should update Image Placeholders to use the HTML Tag Processor too to be more reliable/consistent.