Backwards compatibility for webp images.

[StevenDufresne]

I ran into this, while testing #111. If we are going to fix the layout for containers, we should probably do the same for these images that are rendering as broken images.

The only concern I can see there being is if we need back-compat support for non-webp-enabled browsers. That's a followup issue if it is determined to be a problem after launch though IMHO.

Originally posted by @dd32 in #42 (comment)

[ryelle]

What browser were you using that they're broken? According to caniuse, webp is pretty broadly supported except for IE11 — and I don't think we need to support IE.

[StevenDufresne]

macOs: Catalina
Browser: Safari 13.1

Via BrowserStack

[ryelle]

Do we have any statistics that say we need to support back to Safari 13?

My hesitation is that I don't know if there is a core/editor-supported way to provide fallbacks, so would we need to stop using webp entirely? The file size savings from webp were impressive, so it would be nice to keep that if we can.

[StevenDufresne]

A quick look at analytics reveals:

0.6% of users are using Safari 13.X. That number inches slightly higher if we account for lesser versions. While 0.6% may feel small, it does account for a significant number of real people.

[StevenDufresne]

I don't know if we need to necessarily serve a fallback image, but it should probably not look broken.

[ryelle]

For reference, some images work and some don't (not totally sure why, since that showcase image is theoretically a webp despite being .webp, when returned via https://i2.wp.com/wordpress.org/files/2022/08/Showcase_2560.webp?w=2560&ssl=1 it's content-type: image/png).

Anyway, to get this to "readable," we need to add a background to the editor section. The missing community image is awkward but not critical to understanding the page.

screenshot from browserstack