You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Decide on order of webp_uploads_content_image_mimes filter items #237
Follow-up on #187: The webp_uploads_content_image_mimes filter that was introduced as part of that issue controls which image formats should be preferred as replacements in the frontend content (all conditional based on whether the current attachment has a version in the given image format).
Currently the items in the filter are ordered so that:
The most backward-compatible image format (i.e. with most widespread browser support) should come first.
The most progressive image format (i.e. most efficient compression and file sizes) should come last.
Based on various comments (e.g. starting in #230 (comment), and also in #187 (comment)), we still need to discuss what is the most suitable expected order for the filter.
Right now, since we want to pick the most progressive format in the current implementation, we go through the array in reverse, which arguably is confusing. However, a counter-argument is that the most backward-compatible format should come first which may be "safer" and aligns it better with the webp_uploads_upload_image_mime_transforms filter for which it definitely makes more sense to have the backward-compatible format first, as it is more essential to have.
We also have to consider how this filter could be leveraged in a potential future where there is picture element support and even more progressive image formats like AVIF could be supported. At that point, we would include all of the formats in the frontend based on the order of items in this filter, and JPEG would always be the fallback.
Based on my proposal for the other somewhat related issue in #238 (comment), I am now also leaning towards changing the filter order so that the most "performant" image format comes first in the list. I agree it makes sense to sort the format preferring performance of the format over its "quality", since the filter's purpose is to use more optimized image formats in the content.
@felixarntz I have been working on issue #186 which uses the webp_uploads_content_image_mimes in the plugin to return an array of available mime types, ordered by filesize, with the smallest first.
The intention here is that, regardless of the mime type, the smallest filesize will be delivered as it's considered the most performant.
As it hooks into the webp_uploads_content_image_mimes filter it can be removed/altered by other developers if needed.
Activity
felixarntz commentedon Mar 18, 2022
Based on my proposal for the other somewhat related issue in #238 (comment), I am now also leaning towards changing the filter order so that the most "performant" image format comes first in the list. I agree it makes sense to sort the format preferring performance of the format over its "quality", since the filter's purpose is to use more optimized image formats in the content.
jjgrainger commentedon Mar 22, 2022
@felixarntz I have been working on issue #186 which uses the
webp_uploads_content_image_mimesin the plugin to return an array of available mime types, ordered by filesize, with the smallest first.The intention here is that, regardless of the mime type, the smallest filesize will be delivered as it's considered the most performant.
As it hooks into the
webp_uploads_content_image_mimesfilter it can be removed/altered by other developers if needed.The PR for this is here #243 for review
eugene-manuilov commentedon Mar 22, 2022
I agree that the order needs to be changed to use the first mime type in the list supported by an image. I have added a PR that updates it: #250
felixarntz commentedon Mar 22, 2022
Makes sense. I've gone ahead and approved #250, needs one more approval though.