To be honest I kind of understand where Google was coming from with dropping jxl. But now with Apple throwing their weight behind it, the situation has drastically changed. I really do hope they bring it back.
I'm curious what there is to understand -- this just a selfish decision they are making, right? Not including JPEG XL is worse for users, developers, and the ecosystem.
When it was removed, no other browser supported JPEG XL, and no other browser had expressed an intent to do it. The last thing the web needs is more image formats with limited support. (Could they even have supported it consistently across platforms due to the iOS limitation on all browsers needing to be implemented on WebKit?)
Apple implementing JPEG XL in Safari changes that. Now it's a format with a real chance of being supported across the whole ecosystem.
> Apple implementing JPEG XL in Safari changes that. Now it's a format with a real chance of being supported across the whole ecosystem.
As I’ve mentioned in other threads, I don’t believe the Chrome team didn’t know Apple was going to implement JPEG XL.
There’s lots of communication between the Chrome and WebKit teams.
It’s going to take more than just Apple shipping JPEG XL to perhaps change Google’s point of view; JPEG XL needs to be seen as a game changer that moves the needle.
Yes, it was true for WebP for like a decade. One of the many issues WebP had. Isn't it good to learn from the mistake of WebP, rather than repeat it?
(AVIF was not supported by all browsers on day 1, obviously, but all the major browsers were governing members of the foundation developing it. So it was much more clear that the backing was there across the ecosystem.)
They explicitly said they were disabling it because nobody cares and no industry players were behind in. Not some kind of conspiracy, an actual objective evaluation. With Apple behind it, perhaps the activation energy will exist.
It was a clearly false statement when they said it. Adobe added JPEG XL to its products. Along with them, Facebook, flickr, and a bunch of other services expressed their eagerness to support the new format (because it is vastly superior to all prior image format options). Google decided it conflicted with their competitor format AVIF and axed the experiment.
> Google decided it conflicted with their competitor format AVIF
This is absolutely ridiculous take given JPEG XL is mainly authored by Google and Cloudinary, with AVIF coming from Netflix & alliance that includes Google.
There is no "competitor" here. Just a format nobody else indicated interest in supporting (notably Apple which forces ~half of mobile marked to have no support, given their browser engine restrictions).
Now that they added the support Chrome can easily bring it back.
1. There is nothing ridiculous about cutting another format, whether it is authored by them or not. They took a stand and it was Pro AOM.
2. There has never been another image format that has the level of support or interest as JEPG XL since JPEG becomes the internet standard. And that was before the drama of Chrome dropping support for it.
WebKit already added support for it if I remember correctly. It's just not on Safari so to speak since it uses the macOS stack for this, so it needs the OS itself to adopt it, but Apple was clearly interested in it.
And web browsers aren't the industry. Adobe added support for it, for example, and it didn't really seem like Google did a good-faith discussion with actual industry players, who range from content creation software to OS makers to other web browsers.
It's also not like there are people lining up to use AVIF right now and Google is still pushing for it.
Since Google has already established that JPEG XL is objectively inferior to AVIF [1], and some of its employees, speaking for themselves have also shown similar testing results on twitter. I would actually ask Google why would they be interested in supporting an inferior image codec?
They are comparing production encoders of AVIF, JPEG and WEBP with the reference implementation of JPEG XL. If anything, it is amazing to see how fast the reference implementation is. Remember initial AV1 days-per-frame perfomance?
I wonder how Apple found a way around the allegedly insurmountable problem of supporting and maintaining this feature. Google, I have been told, just doesn't have the resources to do the same.
Learn to use the <picture> element and you can stop caring about what petty squabbles browser vendors have around which image formats they choose to support. It's in all the browsers (except IE..), it handles image fallbacks really nicely, and every site should use it where they have an <img> right now.
> you can stop caring about what petty squabbles browser vendors have around which image formats they choose to support.
I think you misunderstand what the picture element does. Yes, you can put a JXL image into a picture tag, but Chrome still won't render it. You'd still need a backup (lower quality) JPG.
You still have to worry about what image formats the vendors support, and now you have the added burden of making sure you have backups for all your images.
> Yeah, uploading six versions of every image doesn't intersect with my definition of not caring.
You're not doing this manually though, and images encoded for distribution are small. The path to JPEG XL eventually mattering is by JPEG XL alternates being automatically created from a higher-quality source image by your CMS, or at build time, or via services like CloudFlare Images, etc.
Even once Safari 17 (and all iOS browsers via WebKit) makes JPEG XL worth making an alternate for, most sites are realistically 5+ years away from not having to have a JPEG fallback. And if you're doing that, you might as well support the far-more-popular WebP as well.
This is why people use platforms like Squarespace, Substack, Medium, or if self hosting at least use a CMS. Just add it to the list of things you need to learn to run a website, along with... JS bundlers, CSS media queries, responsive design... now we need to pre process images too. All in the pursuit of quality, of course.
Yeah, uploading six versions of every image doesn't intersect with my definition of not caring.
What I meant was that you only need to care about what image formats you want to support. You don't need to care about what image formats browser vendors support.
Except that you're totally wrong. If you care about JXL, and only want to support JXL, and you put a JXL in your picture tag, then the browser still won't render it, even if you use a picture tag.
> If you care about JXL, and only want to support JXL, and you put a JXL in your picture tag, then the browser still won't render it, even if you use a picture tag.
Is this true if you provide a polyfill? Have you tried it and it failed? (Serious question.)
Having to provide a polyfill is the opposite of "stop caring about what petty squabbles browser vendors have around which image formats they choose to support."
Gotta love being called a dick for having a hypothetical opinion on image formats.
You are suggesting that `<picture>` alone would solve this issue. It very clearly does not; you're still limited by what browsers support the format you use in your pictures. If you only release it in one format because you don't want to deal with compression/format changes/whatever, then you still have the same exact problem.
If months from now, Chrome is the only browser that doesn't support it, then it's just as bad of a solution as now, and I'd no longer be called a dick by a random stranger on the internet. What then?
Compress your jpeg with jpegli.
Configure your webserver to losslessly recompress to jpeg xl. You don't even notice that new formats arrived but will get 90% of the benefit.
If your goal is purely compatibility, then using img with either PNG or JPEG will be just fine.
If however you care about image quality, bandwidth, &c. then you should use picture but... you'll also probably care about what % of your users are getting served whatever image version you consider optimal.
So using picture and stopping caring seem like opposites to me.
It’s pretty nice, although it makes your image encoding, storage, and HTML size N times larger to support N formats. That gets even crazier if you also want responsive images.
Does the picture element make it easier to handle jxl files with a wasm polyfill? That seems like the ideal case— website maintainer only has to deal with, store, and serve a single file, old browsers get only a slightly degraded experience.
More info for those inclined. In short, you can specify multiple versions of the same image…
> “ The HTML <picture> element gives web developers more flexibility in specifying image resources.
> The <picture> element contains one or more <source> elements, each referring to different images through the srcset attribute. This way the browser can choose the image that best fits the current view and/or device.
> Each <source> element has a media attribute that defines when the image is the most suitable.”
https://bugs.chromium.org/p/chromium/issues/detail?id=117805...