Support webp images

[mutec]

https://developers.google.com/speed/webp/

• [ ] ImageUtil::getExtensionByMimeType()
• [ ] ImageAdapter::loadFile()

[dtdesign]

The browser support for webp is still very limited: https://caniuse.com/#feat=webp

[mutec]

I know, but maybe it's better to be able to read/convert those images before everyone starts using it.

[cadeyrn]

I understand that it's too late for 5.2 so I don't have any objections to 5.3 as milestone but I don't agree with the following statement:

The browser support for webp is still very limited: https://caniuse.com/#feat=webp

Apple is the only "major player" without WebP support. Yes Apple is important and there is still the Internet Explorer. But - similar to videos - images can be provided in more than one format at the same time. That's called progressive enhancement. Just have a look at other CMS like Pimcore which have WebP support and where images work like a charm even in Internet Explorer and in Apple browsers because they simply get the fallback image. Browser support is really no reason to not support in WebP in 2019. Time contraints are a more realistic reason because it's not a small task. ;-)

[dtdesign]

At the time of writing, WebP was only supported in Blink browsers.

We do want to support WebP, but want it to be implemented throughout the entire software suite. Right now, we're in the dawn of the development cycle and while WebP is an interessting image format, there are other things that are ranked higher for 5.2.

[cadeyrn]

At the time of writing WebP support was already supported by Edge and by Firefox one day after this issue was opened. ;-)

But yes, as said in my previous comment, I understand that it's not a small task and too late for 5.2. And to be clear: I'll be happy when the new version is finally ready, I don't want any delays. :D I only wanted to clarify that browser support should not be the problem. ;-)

[dtdesign]

The beta of Safari 14 currently lists "Added WebP image support." [1], which is the remaining blocker. After that point, the Internet Explorer 11 will be the last browser that does not support WebP.

However, we're planing on retiring the support for Internet Explorer 11 with an upcoming version (not 5.3!). Technically, we do not officially support it since 5.2, but we have kept the CSS and JavaScript compatible, because there was no significant benefit to break the implicit compatibility. We're looking forward to move to newer techniques (ES2017, WebP, possibly CSS variables) in the future, which would be a good opportunity to drop the IE11 support for good.

There will be no support for WebP in 5.3, because even when Safari 14 arrives in time, it may take some time for a widespread adoption and it would break IE11. We're not going with some workarounds to present different versions of a file depending on the browser support, the effort is simply not worth it, considering that we intend to keep a tight release schedule for 5.4.

[1] https://developer.apple.com/documentation/safari-release-notes/safari-14-beta-release-notes

[cadeyrn]

The beta of Safari 14 currently lists "Added WebP image support." [1], which is the remaining blocker.

…

There will be no support for WebP in 5.3, because even when Safari 14 arrives in time, it may take some time for a widespread adoption and it would break IE11.

That's not correct and I don't understand why Safari support should be a blocker. If you do it right there are no compatibility problems at all.

We're not going with some workarounds to present different versions of a file depending on the browser support

Using the picture element and srcset is not a workaround, it's the correct way to do it and possible since many years. It's disappointing to wait any longer for something other softwares are able to do since years.

You have to do something like this anyway even if IE is no longer a thing and Safari supports WebP because you can disable WebP support in some browsers and it would be unacceptable if the software no longer works for these users.

This is the output generated by another CMS:

<picture>
  <source srcset="/filename.webp 1x, /filename@2x.webp 2x" type="image/webp">
  <source srcset="/filename.jpg 1x, /filename@2x.jpg 2x" type="image/jpeg">
  <img alt="" class="img-fluid" src="/filename.jpg">
</picture>

And it works in every browser. It allows even more complex scenarios:

<picture>
  <source media="(max-width: 991px)" srcset="/filename~-~media--0f9b86cf--query.webp 1x, /filename~-~media--0f9b86cf--query@2x.webp 2x" type="image/webp">
  <source media="(max-width: 991px)" srcset="/filename~-~media--0f9b86cf--query.jpg 1x, /filename~-~media--0f9b86cf--query@2x.jpg 2x" type="image/jpeg">
  <source media="(max-width: 1199px)" srcset="/filename~-~media--3f079e97--query.webp 1x, /filename~-~media--3f079e97--query@2x.webp 2x" type="image/webp">
  <source media="(max-width: 1199px)" srcset="/filename~-~media--3f079e97--query.jpg 1x, /filename~-~media--3f079e97--query@2x.jpg 2x" type="image/jpeg">
  <source media="(max-width: 1589px)" srcset="/filename~-~media--99f6f531--query.webp 1x, /filename~-~media--99f6f531--query@2x.webp 2x" type="image/webp">
  <source media="(max-width: 1589px)" srcset="/filename~-~media--99f6f531--query.jpg 1x, /filename~-~media--99f6f531--query@2x.jpg 2x" type="image/jpeg">
  <source srcset="/filename.webp 1x, /filename@2x.webp 2x" type="image/webp">
  <source srcset="/filename.jpg 1x, /filename@2x.jpg 2x" type="image/jpeg">
  <img alt="" class="img-fluid" src="/filename.jpg">
</picture>

There is really no reason not to support WebP in the year 2020, it's already late…

[cadeyrn]

WoltLab Suite 5.3 is available now. So let's talk again about WebP support in a future release of WoltLab Suite before you start the implementation (or before you decide to delay this enhancement again 😉).

It's important not to drop the support of other image formats altogether. As already mentioned you should use the picture element and srcset attribute. It's not only about compatibility with legacy browsers like Internet Explorer. As I learnt as part of my Firefox support activities it's a real use case that some users disable WebP support in their browser because they want to save images but don't have an image editor for WebP. It should not happen that these users can't see any images.

But it's also about being ready for the future. Now we're talking about WebP support. It's no secret that browser vendors already work on the "next big image format", AVIF images, based on AV1 from the Alliance of Open Media: http://aomedia.org/membership/members/. Browsers like Firefox and Chrome already have preliminary support for AVIF. If you do it right for WebP now it will be easier to support other image formats like AVIF in the future.

Another important advantage of using the picture element with srcset is that you can deliver different image sizes for users with and without high resolution displays. That's another important piece of providing the end user with the best image quality and performance at the same time.

It's proven that performance has a real impact on the behaviour of users and search engines have already started to treat the website performance as a ranking factor. For these reasons it's very important to support modern image formats even if some browsers will need more time than others. Thanks to the HTML standard there are no compatibility reasons to wait for all browsers. You don't have to retire old browsers to support newer image formats.

tl;dr: Please make use of the picture element and srcset attribute and don't do a simple 1:1 "replacement" of PNG/JPEG <-> WebP.

[dtdesign]

We are sitting between two chairs: srcset does not support content type negotiation and <picture> greatly breaks backwards compatibility (*) while also bloating the resulting HTML (although, that's not much of a concern).

(*) Selectors in CSS and JavaScript that use img will stop working, this affects both 3rd party plugins and custom CSS written by the user.

[cadeyrn]

Well… If your primary concern is that you don't want compatibility breaks at all then we won't get support for modern image formats for many more years because the story won't end with the support of WebP. There will be AVIF very soon and it would be a shame if we have to wait additional five years for AVIF support. So you need a solution to support different image formats anyway if you see the WoltLab Suite as a modern solution for web communities in the long run. And as I already explained: WebP-only can't be the solution because this would make the software unusable for some users.

The WoltLab Suite is already behind other softwares in terms of image support. And this should change as soon as possible since performance is more important than ever. This is why it should be done the correct way with the next release even if there are some small changes needed for some themes or plugins. This shouldn't be too bad especially since it requires no really big changes for third parties and the use of modern standards is simply necessary.

I agree that "bloating" the HTML should not be much of a concern, not to say no concern at all because a) this is how it works and b) because you save much, much more bytes with the support of modern image formats and the right image versions (serve different images to different resolutions and pixel densities) than with a few less lines HTML.