~tsileo/microblog.pub-devel

Fallback to unresized image on attachments v1 SUPERSEDED

João Costa: 1
 Fallback to unresized image on attachments

 1 files changed, 10 insertions(+), 2 deletions(-)
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.

Thanks!
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:

```
image/avif,image/webp,*/*
```

I think this would be a better approach.
Export patchset (mbox)
How do I use this?

Copy & paste the following snippet into your terminal to import this patchset into git:

curl -s https://lists.sr.ht/~tsileo/microblog.pub-devel/patches/37461/mbox | git am -3
Learn more about email & git

[PATCH] Fallback to unresized image on attachments Export this patch

This allows browsers that do not support webp to still render the images.
---
 app/templates/utils.html | 12 ++++++++++--
 1 file changed, 10 insertions(+), 2 deletions(-)

diff --git a/app/templates/utils.html b/app/templates/utils.html
index 32bbcc9..fbccf7b 100644
--- a/app/templates/utils.html
+++ b/app/templates/utils.html
@@ -273,7 +273,10 @@

<div class="actor-box h-card p-author">
    <div class="icon-box">
        <img src="{{ actor.resized_icon_url }}" alt="{{ actor.display_name }}'s avatar" class="actor-icon u-photo">
        <picture class="actor-icon u-photo" width="50">
          <source srcset="{{ actor.resized_icon_url }}" type="image/webp">
          <img src="{{ actor.proxied_icon_url }}" alt="{{ actor.display_name }}'s avatar" width="50">
        </picture>
    </div>
    <a href="{{ actor.url }}" class="u-url">
        <div><strong>{{ actor.display_name | clean_html(actor) | safe  }}</strong></div>
@@ -425,7 +428,12 @@
    {% if attachment.type == "Image" or (attachment | has_media_type("image")) %}
        {% if attachment.url not in object.inlined_images %}
        <a class="media-link" href="{{ attachment.proxied_url }}" target="_blank">
            <img src="{{ attachment.resized_url or attachment.proxied_url }}"{% if attachment.name %} title="{{ attachment.name }}" alt="{{ attachment.name }}"{% endif %} class="attachment u-photo">
            <picture class="attachment u-photo" width="740">
              {% if attachment.resized_url %}
              <source srcset="{{ attachment.resized_url }}" type="image/webp">
              {% endif %}
              <img src="{{ attachment.proxied_url }}"{% if attachment.name %} title="{{ attachment.name }}" alt="{{ attachment.name }}"{% endif %} width="740">
            </picture>
        </a>
        {% endif %}
    {% elif attachment.type == "Video" or (attachment | has_media_type("video")) %}
-- 
2.38.1.windows.1
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.