Hey, I will try to take a look at this today.
Not all the resized version are webp, for example we leave animated GIF alone, and if it fails, we fallback to the original picture. Can that be an issue if we specify the wrong type in the source tag?
I am not sure we should hardcode the width, I think the CSS already handle that (and I don't want to break custom themes).
And I think the patch as-is is breaking the microformats2 classes (for example `u-photo` mark a tag as a picture, I think having it on the `picture` tag may fail with some parser). But I can take care of testing that and tweak it if needed.
I will keep you updated once I tested this/played with it.
I just realized we may be able to look at the `Accept` headers to determine if the browser supports webp, for example, my browser set this header when requesting an image:
I think this would be a better approach.
This PR doesn't change all images (e.g. avatars from likes still only
serve the resized image), but this seems enough for a nice experience on
older browsers (such as the one available on most KaiOS devices).
I tried on my instance and this seemed to work fine, but you might want
to check if the hardcoded widths and moving the CSS classes from img to
picture don't break anything on the default CSS.