8 ms·

It's such a shame Google decided to block adoption of JPEG XL: it's a strict improvement over classic JPEG (you can losslessly reencode JPEG to JXL and reduce t

It's such a shame Google decided to block adoption of JPEG XL: it's a strict improvement over classic JPEG (you can losslessly reencode JPEG to JXL and reduce the size, due to a better entropy coder in JXL!) and JXL has various other upgrades compared to 'classic' JPEG. In the meantime, let's hope AVIF or whatever manages to pick up the slack, and/or other browsers decide en masse to support JPEG XL anyway; that would be a bad look for Google, especially if even Apple decides to join in on the JXL party.

jfeser 3y ago
Apple already has! Safari has Jpeg XL enabled by default.
Latty 3y ago
I must admit, I'm not sure why JPEG XL is viewed so favourably on HN, it's not something I know a ton about, but my understanding is that the big advantage of AVIF is that you can reuse hardware decoders built into devices for AV1 for the images. It being a strict improvement over JPEG is nice for the developers not having to go back to the source image for an upgrade, but that seems like a pretty small benefit that only matters during the transitional period. Meanwhile, if you are getting better battery life every time someone views an AVIF image, that's a huge benefit for the entire lifetime of the format, it seems to massively outweigh any advantage JXL has, to me.
- izacus 3y ago
  JPEG XL is viewed favorably on HN because it's the underdog to evil Google. Before they wrote their complaint article about Chrome removing support (after significant time of noone using the format), noone here gave it a thought. It's not like anyone is attacking Firefox for not enabling it either. This is not a format quality thing, this is "let's have a chance to complain about Google" thing again ;) I mean, this whole posted blog is doing a comparison on a single image. Anyone with a bit of thought would dismiss this as ridiculous in first second... but there's the Google name and the HN haters are out of the woods.
  - dontlaugh 3y ago
    I don't know, I liked it on its merits before. I'm sure others did too. Seamless legacy support is very valuable. And it still performs pretty well compared to competitors. I think it's a good default for a lossy network format.
  - eviks 3y ago
    Firefox nightly has support according to https://jpegxl.io/tutorials/firefox/ https://jpegxl.io/tutorials/firefox/, of course you're wrong that nobody is attacking FF, but given its tiny niche compared to Chrome it's obviously much less consequential, so the volume attacks on Chrome would dwarf anything FF-related (Safari was also criticized, and they've recently added support) > after significant time of noone using the format That's also fasle, this is too new of a format for any significant time of no use to materialize, besides, requiring flags that vast majority of users will not enable is a huge factor limiting widespread use
  - orbital-decay 3y ago
    The support was never complete to begin with, so the removal wasn't due to nobody using it. Some rivalry between different teams inside Google is more likely.
  - account42 3y ago
    What a shit take. JXL did have plenty favorable responses on HN before Google removed it for reasons that they never applied to their own formats. And FF did get plenty of complaints for not supporting JXL but those are often shut down with the opposite variant of your take.
    - izacus 3y ago
      As I work with codecs I've been following the situation quite closely and the attention to XL was pretty much zero until Google decided to not support it. Moreover, this whole topic is about a comparison over a SINGLE IMAGE. Anyone who ever came close to codecs would immediately dismiss this as ridiculous. Yet here we are.
- londons_explore 3y ago
  Image decode is a rather tiny fraction of the loading time of a modern web page, or its power budget... Thats why, to my knowledge, nobody even bothers to use hardware jpeg encoders/decoders on phones/laptops, despite many bits of silicon having them.
  - arp242 3y ago
    JPEG may be fast enough for all of that, but is that also true for these newer ones? Decoding the .heic pictures from my old iPhone takes 1-2 seconds on my laptop(!!) As near as I could find out that's because the iPhones and macBooks and such all have hardware support for that, and my ThinkPad doesn't.
    - eviks 3y ago
      According to the article I've linked above, JXL has twice as many points (don't remember actual speed comparison numbers) in the decoding speed comparison, and is also more parallelizable
      - arp242 3y ago
        To be honest I find that a little bit too vague to be useful. I can't find clear numbers on this, but on e.g. [1] I read it's not too fast, but I didn't try to reproduce their results, and according to some comments a number of factors can greatly affect performance. [1]: https://old.reddit.com/r/jpegxl/comments/zwftn2/libjxl_on_android_much_slower_than_expected_is_it/ https://old.reddit.com/r/jpegxl/comments/zwftn2/libjxl_on_an...
- chrismorgan 3y ago
  AVIF kinda needs hardware decoding, because otherwise it’s considerably more expensive than the traditional codecs. Even with hardware decoding, I’m not sure if AVIF is actually faster/chaper—compared in https://jpegxl.io/articles/faq/#%E2%8F%A9speedfeatures https://jpegxl.io/articles/faq/#%E2%8F%A9speedfeatures, “AVIF” takes 7× as long as libjpeg-turbo to decode, and I don’t believe hardware encoders tend to bring that big a performance difference over software, but I’m really not sure. AVIF reduces the amount of traffic required, but will tend to consume more power. This is the general compression tradeoff. (Other formats often have hardware decoding support too, incidentally. But a lot of the time they’re ignored as too much effort to integrate, or buggy, or something.)
  - arghwhat 3y ago
    > AVIF reduces the amount of traffic required, but will tend to consume more power. This is the general compression tradeoff. Mobile devices on battery are connected wirelessly, so traffic consumes a lot of power. The faster the radio can power back down the better, so CPU time is usually a worthwhile trade.
  - Latty 3y ago
    You kind of ignore the case where almost every device is going to do AV1 hardware decoding (which very much appears to be the trend), if that is significantly faster/cheaper battery wise then AV1 still has a big advantage. Comparing single-core software decoding speed seems like a benchmark designed to make JXL look good, not something that actually matters. > AVIF reduces the amount of traffic required, but will tend to consume more power. This is the general compression tradeoff. Again, you seem to be ignoring hardware decoding. Dedicated silicon can be many magnitudes more efficient than doing something in software. To take an extreme example with a ton of effort into the efficiency: look at mining bitcoin on a CPU vs an ASIC. I'm not saying the difference will be that big, but it may well be worthwhile. As to buggy/too much effort/cost of hardware, that's precisely why it makes sense to piggy-back on AV1, a format that already has a lot of incentive to implement in hardware, and the work already done to make it work well. You need that kind of compression for video, and people are putting in the effort to make it work well, so AVIF gets that effectively for free.
- washadjeffmad 3y ago
  Then doesn't that follow the line of argument for why AV1 isn't being adopted, either? Namely, lack of hardware support? I can understand why jxl isn't a dominant web format, but I don't see where avif has any place being a web format currently.
  - Latty 3y ago
    AV1 is being adopted? Almost every modern bit of hardware has AV1 decoding baked into it now, which is a huge hurdle to pass.
- eviks 3y ago
  Part of the reason is because it's a technically superior codec, check out John Snyer's series of blogs on comparisons, e.g., https://cloudinary.com/blog/time_for_next_gen_codecs_to_dethrone_jpeg https://cloudinary.com/blog/time_for_next_gen_codecs_to_deth... Video codecs as used for images also have big disadvantages since they weren't designed for many picture-focused workflows > only matters during the transitional period. which can be decades, so this matters a lot > it seems to massively outweigh any advantage JXL has Since you haven't listed any other advantages outside of downplaying the compatibility during transition, so that's hard to weigh. Also, it's not like, if we're talking about the whole lifetime, hardware couldn't add support
  - Latty 3y ago
    The advantage is increased battery life and performance, which is way more important to most end users than any of the advantages I've seen for JXL. People are not pixel-peeping different images to compare quality, they are annoyed when their battery dies. As to hardware adding support for JXL, that seems extremely unlikely: image decoding is less impactful than video decoding, and the cost of adding custom decoding silicon to a chip is very high, as is adding support to software for that hardware. Being able to piggy-back on the work already done for video meaning you get that stuff for free makes it way more viable. AV1 decoding is already out there in virtually every new device, and rolling out hardware support is very slow, it's massively ahead in that respect.
- fold3 3y ago
  Jpeg-XL is light enough to not require hardware support. Did you tried to transcode a PNG to avif? It's painful. Not the case with Jpeg XL. Meanwhile I urge you to read this article. Jpeg XL has way more features than avif. https://cloudinary.com/blog/the-case-for-jpeg-xl https://cloudinary.com/blog/the-case-for-jpeg-xl
  - Latty 3y ago
    Hardware decoding can mean less battery usage, which is very big for end users. I just don't think any of those features matter as much a battery life, most of them are about encoding speed which just seems wildly unimportant to me: encoding may be more work, but generally you view images far more than you make them, and admins and creators are in a better position to spend the time/effort to encode something, and hardware encoding may well end up making it a non-issue anyway. People are out there running `zopflipng` and the like to try and get better sizes at the cost of more work at encode time, so it seems like that priority isn't just me.
- PaulHoule 3y ago
  I have problems w/ AVIF that are like the ones that guy has with WebP. Please don’t post a link to the F1 car sample image because I think that image sucks (e.g. a reflection from a surface near the driver’s head gets replaced with a different but plausible reflection.)
- gruturo 3y ago
  JXL is an image codec - it can afford to be less efficient (it's not! Other way around, rather) and not be hardware accelerated as its typical use case is not to present 30-60 images per second like in a video codec, it will not affect the battery life of a device in any meaningful way. Also, AV1 hardware decoding is far, far from ubiquitous so many users would not benefit at all from it. But - back to JXL vs WebP: I think Google had genuinely good intentions with WebP, but the effort was somewhat ruined by their culture: they relied too heavily on metrics which aren't always a good proxy for image quality, because humans looking at pictures don't scale, and Google does things that scale. We now have a codec with good metrics, but looks poor. It's based on the intraframe coding of the VP8 format - a video codec - and I think it suffers from that. Looks OK in a video, but bad in stills where you have more time to notice its warts Most importantly, it's almost always produced by recompressing a jpeg and causing a generation loss. I don't know of any phone or camera which produces native WebP (maybe some recent pixels? Dunno), and any professional device used in RAW mode usually implies the participation of someone who cares about the finished product and will not want WebP (and will resent when it's used without their consent by webmasters wishing to tick a box in pagespeed, as the author mentions). JXL has a lossless recompression mode in which it just replaces the Huffmann compression stage of an existing JPEG with something more modern, and this results in a pixel-accurate image which is 20% smaller than the original file - this already eat WebP's claimed space saving, and then some, with no generation loss. Based on this fact alone, there shouldn't even be a discussion. ....but let's have a discussion anyway. A JPEG -> JXL lossless recompression isn't conceptually new - Stuffit (remember them?) did it in 2005, with not enough traction sadly (unsurprisingly since there were patents and licensing costs). Basically it's _still_ a JPEG - if you decompress the final stage of a JPEG, and the final stage of a JXL (or a .SIF), you get the exact same bytestream. While yet another amazing testament of JPEG's longevity and relevance, it is also concerning: How could Google do worse than that??? When basically rezipping (with a modern algo) the existing DCT macroblock bytestream of a 30 year old codec beats your new codec, you should just trash it. Edit: ...but I forgot to answer your question. Why is JXL viewed so favorably on HN? Because it doesn't suck, and we're sad that Google decided to be a roadblock, and pushing for their own thing, which instead sucks. At least AVIF is way better than WebP, even though it's a monster, computationally.
  - 3y ago
chrismorgan 3y ago
Google haven’t explicitly decided to block adoption of JPEG XL. They removed an incomplete implementation from Chromium which had never been shipped, because it was a maintenance burden and they weren’t ready to commit to supporting it. That’s quite a different thing. It may indicate a broader strategic direction, but it doesn’t necessarily.
- lakpan 3y ago
  I want to believe. Having an immediate upgrade path to all pictures from the past is too good an opportunity to pass up. We rarely get a free “compress losslessly” button for our archives.
- lifthrasiir 3y ago
  That charitable interpretation would have been okay unless the Chrome team (yes, "Google" is not a single entity here) tried to publish a faulty benchmark [1] that has been thoroughly criticized [2] which never has been answered so far. [1] https://storage.googleapis.com/avif-comparison/index.html https://storage.googleapis.com/avif-comparison/index.html [2] https://cloudinary.com/blog/contemplating-codec-comparisons https://cloudinary.com/blog/contemplating-codec-comparisons
- nicoburns 3y ago
  Yeah, I'm quite hopeful that this is one where the developer backlash will cause a U-turn. I suspect it was seen as something that most people didn't care about, and now that it's clear that they do then likely something will be done about. I can't see any reason why Google would be strongly against it's inclusion.
- RedShift1 3y ago
  The called it technically inferior based on opinions. They didn't do a thorough technical review, and why would they, they have webp. This was absolutely a strategical thing, it's naive to think it isn't.
account42 3y ago
Agreed. It's especially infuriating that their arguments against jxl would have applied to webp too (even more so) but for some reason that was pushed trough (as were other Google formats).
markdog12 3y ago
Seems Safari has it enabled by default now, and Apple has support at the OS level. Firefox at least has it under a flag. Chrome team are the odd ones out here.
deleted 3y ago
[deleted]

jfeser 3y ago

Apple already has! Safari has Jpeg XL enabled by default.

Latty 3y ago

I must admit, I'm not sure why JPEG XL is viewed so favourably on HN, it's not something I know a ton about, but my understanding is that the big advantage of AVIF is that you can reuse hardware decoders built into devices for AV1 for the images. It being a strict improvement over JPEG is nice for the developers not having to go back to the source image for an upgrade, but that seems like a pretty small benefit that only matters during the transitional period. Meanwhile, if you are getting better battery life every time someone views an AVIF image, that's a huge benefit for the entire lifetime of the format, it seems to massively outweigh any advantage JXL has, to me.

izacus 3y ago
JPEG XL is viewed favorably on HN because it's the underdog to evil Google. Before they wrote their complaint article about Chrome removing support (after significant time of noone using the format), noone here gave it a thought. It's not like anyone is attacking Firefox for not enabling it either. This is not a format quality thing, this is "let's have a chance to complain about Google" thing again ;) I mean, this whole posted blog is doing a comparison on a single image. Anyone with a bit of thought would dismiss this as ridiculous in first second... but there's the Google name and the HN haters are out of the woods.
- dontlaugh 3y ago
  I don't know, I liked it on its merits before. I'm sure others did too. Seamless legacy support is very valuable. And it still performs pretty well compared to competitors. I think it's a good default for a lossy network format.
- eviks 3y ago
  Firefox nightly has support according to https://jpegxl.io/tutorials/firefox/ https://jpegxl.io/tutorials/firefox/, of course you're wrong that nobody is attacking FF, but given its tiny niche compared to Chrome it's obviously much less consequential, so the volume attacks on Chrome would dwarf anything FF-related (Safari was also criticized, and they've recently added support) > after significant time of noone using the format That's also fasle, this is too new of a format for any significant time of no use to materialize, besides, requiring flags that vast majority of users will not enable is a huge factor limiting widespread use
- orbital-decay 3y ago
  The support was never complete to begin with, so the removal wasn't due to nobody using it. Some rivalry between different teams inside Google is more likely.
- account42 3y ago
  What a shit take. JXL did have plenty favorable responses on HN before Google removed it for reasons that they never applied to their own formats. And FF did get plenty of complaints for not supporting JXL but those are often shut down with the opposite variant of your take.
  - izacus 3y ago
    As I work with codecs I've been following the situation quite closely and the attention to XL was pretty much zero until Google decided to not support it. Moreover, this whole topic is about a comparison over a SINGLE IMAGE. Anyone who ever came close to codecs would immediately dismiss this as ridiculous. Yet here we are.
londons_explore 3y ago
Image decode is a rather tiny fraction of the loading time of a modern web page, or its power budget... Thats why, to my knowledge, nobody even bothers to use hardware jpeg encoders/decoders on phones/laptops, despite many bits of silicon having them.
- arp242 3y ago
  JPEG may be fast enough for all of that, but is that also true for these newer ones? Decoding the .heic pictures from my old iPhone takes 1-2 seconds on my laptop(!!) As near as I could find out that's because the iPhones and macBooks and such all have hardware support for that, and my ThinkPad doesn't.
  - eviks 3y ago
    According to the article I've linked above, JXL has twice as many points (don't remember actual speed comparison numbers) in the decoding speed comparison, and is also more parallelizable
    - arp242 3y ago
      To be honest I find that a little bit too vague to be useful. I can't find clear numbers on this, but on e.g. [1] I read it's not too fast, but I didn't try to reproduce their results, and according to some comments a number of factors can greatly affect performance. [1]: https://old.reddit.com/r/jpegxl/comments/zwftn2/libjxl_on_android_much_slower_than_expected_is_it/ https://old.reddit.com/r/jpegxl/comments/zwftn2/libjxl_on_an...
chrismorgan 3y ago
AVIF kinda needs hardware decoding, because otherwise it’s considerably more expensive than the traditional codecs. Even with hardware decoding, I’m not sure if AVIF is actually faster/chaper—compared in https://jpegxl.io/articles/faq/#%E2%8F%A9speedfeatures https://jpegxl.io/articles/faq/#%E2%8F%A9speedfeatures, “AVIF” takes 7× as long as libjpeg-turbo to decode, and I don’t believe hardware encoders tend to bring that big a performance difference over software, but I’m really not sure. AVIF reduces the amount of traffic required, but will tend to consume more power. This is the general compression tradeoff. (Other formats often have hardware decoding support too, incidentally. But a lot of the time they’re ignored as too much effort to integrate, or buggy, or something.)
- arghwhat 3y ago
  > AVIF reduces the amount of traffic required, but will tend to consume more power. This is the general compression tradeoff. Mobile devices on battery are connected wirelessly, so traffic consumes a lot of power. The faster the radio can power back down the better, so CPU time is usually a worthwhile trade.
- Latty 3y ago
  You kind of ignore the case where almost every device is going to do AV1 hardware decoding (which very much appears to be the trend), if that is significantly faster/cheaper battery wise then AV1 still has a big advantage. Comparing single-core software decoding speed seems like a benchmark designed to make JXL look good, not something that actually matters. > AVIF reduces the amount of traffic required, but will tend to consume more power. This is the general compression tradeoff. Again, you seem to be ignoring hardware decoding. Dedicated silicon can be many magnitudes more efficient than doing something in software. To take an extreme example with a ton of effort into the efficiency: look at mining bitcoin on a CPU vs an ASIC. I'm not saying the difference will be that big, but it may well be worthwhile. As to buggy/too much effort/cost of hardware, that's precisely why it makes sense to piggy-back on AV1, a format that already has a lot of incentive to implement in hardware, and the work already done to make it work well. You need that kind of compression for video, and people are putting in the effort to make it work well, so AVIF gets that effectively for free.
washadjeffmad 3y ago
Then doesn't that follow the line of argument for why AV1 isn't being adopted, either? Namely, lack of hardware support? I can understand why jxl isn't a dominant web format, but I don't see where avif has any place being a web format currently.
- Latty 3y ago
  AV1 is being adopted? Almost every modern bit of hardware has AV1 decoding baked into it now, which is a huge hurdle to pass.
eviks 3y ago
Part of the reason is because it's a technically superior codec, check out John Snyer's series of blogs on comparisons, e.g., https://cloudinary.com/blog/time_for_next_gen_codecs_to_dethrone_jpeg https://cloudinary.com/blog/time_for_next_gen_codecs_to_deth... Video codecs as used for images also have big disadvantages since they weren't designed for many picture-focused workflows > only matters during the transitional period. which can be decades, so this matters a lot > it seems to massively outweigh any advantage JXL has Since you haven't listed any other advantages outside of downplaying the compatibility during transition, so that's hard to weigh. Also, it's not like, if we're talking about the whole lifetime, hardware couldn't add support
- Latty 3y ago
  The advantage is increased battery life and performance, which is way more important to most end users than any of the advantages I've seen for JXL. People are not pixel-peeping different images to compare quality, they are annoyed when their battery dies. As to hardware adding support for JXL, that seems extremely unlikely: image decoding is less impactful than video decoding, and the cost of adding custom decoding silicon to a chip is very high, as is adding support to software for that hardware. Being able to piggy-back on the work already done for video meaning you get that stuff for free makes it way more viable. AV1 decoding is already out there in virtually every new device, and rolling out hardware support is very slow, it's massively ahead in that respect.
fold3 3y ago
Jpeg-XL is light enough to not require hardware support. Did you tried to transcode a PNG to avif? It's painful. Not the case with Jpeg XL. Meanwhile I urge you to read this article. Jpeg XL has way more features than avif. https://cloudinary.com/blog/the-case-for-jpeg-xl https://cloudinary.com/blog/the-case-for-jpeg-xl
- Latty 3y ago
  Hardware decoding can mean less battery usage, which is very big for end users. I just don't think any of those features matter as much a battery life, most of them are about encoding speed which just seems wildly unimportant to me: encoding may be more work, but generally you view images far more than you make them, and admins and creators are in a better position to spend the time/effort to encode something, and hardware encoding may well end up making it a non-issue anyway. People are out there running `zopflipng` and the like to try and get better sizes at the cost of more work at encode time, so it seems like that priority isn't just me.
PaulHoule 3y ago
I have problems w/ AVIF that are like the ones that guy has with WebP. Please don’t post a link to the F1 car sample image because I think that image sucks (e.g. a reflection from a surface near the driver’s head gets replaced with a different but plausible reflection.)
gruturo 3y ago
JXL is an image codec - it can afford to be less efficient (it's not! Other way around, rather) and not be hardware accelerated as its typical use case is not to present 30-60 images per second like in a video codec, it will not affect the battery life of a device in any meaningful way. Also, AV1 hardware decoding is far, far from ubiquitous so many users would not benefit at all from it. But - back to JXL vs WebP: I think Google had genuinely good intentions with WebP, but the effort was somewhat ruined by their culture: they relied too heavily on metrics which aren't always a good proxy for image quality, because humans looking at pictures don't scale, and Google does things that scale. We now have a codec with good metrics, but looks poor. It's based on the intraframe coding of the VP8 format - a video codec - and I think it suffers from that. Looks OK in a video, but bad in stills where you have more time to notice its warts Most importantly, it's almost always produced by recompressing a jpeg and causing a generation loss. I don't know of any phone or camera which produces native WebP (maybe some recent pixels? Dunno), and any professional device used in RAW mode usually implies the participation of someone who cares about the finished product and will not want WebP (and will resent when it's used without their consent by webmasters wishing to tick a box in pagespeed, as the author mentions). JXL has a lossless recompression mode in which it just replaces the Huffmann compression stage of an existing JPEG with something more modern, and this results in a pixel-accurate image which is 20% smaller than the original file - this already eat WebP's claimed space saving, and then some, with no generation loss. Based on this fact alone, there shouldn't even be a discussion. ....but let's have a discussion anyway. A JPEG -> JXL lossless recompression isn't conceptually new - Stuffit (remember them?) did it in 2005, with not enough traction sadly (unsurprisingly since there were patents and licensing costs). Basically it's _still_ a JPEG - if you decompress the final stage of a JPEG, and the final stage of a JXL (or a .SIF), you get the exact same bytestream. While yet another amazing testament of JPEG's longevity and relevance, it is also concerning: How could Google do worse than that??? When basically rezipping (with a modern algo) the existing DCT macroblock bytestream of a 30 year old codec beats your new codec, you should just trash it. Edit: ...but I forgot to answer your question. Why is JXL viewed so favorably on HN? Because it doesn't suck, and we're sad that Google decided to be a roadblock, and pushing for their own thing, which instead sucks. At least AVIF is way better than WebP, even though it's a monster, computationally.
- 3y ago

chrismorgan 3y ago

Google haven’t explicitly decided to block adoption of JPEG XL. They removed an incomplete implementation from Chromium which had never been shipped, because it was a maintenance burden and they weren’t ready to commit to supporting it. That’s quite a different thing. It may indicate a broader strategic direction, but it doesn’t necessarily.

lakpan 3y ago
I want to believe. Having an immediate upgrade path to all pictures from the past is too good an opportunity to pass up. We rarely get a free “compress losslessly” button for our archives.
lifthrasiir 3y ago
That charitable interpretation would have been okay unless the Chrome team (yes, "Google" is not a single entity here) tried to publish a faulty benchmark [1] that has been thoroughly criticized [2] which never has been answered so far. [1] https://storage.googleapis.com/avif-comparison/index.html https://storage.googleapis.com/avif-comparison/index.html [2] https://cloudinary.com/blog/contemplating-codec-comparisons https://cloudinary.com/blog/contemplating-codec-comparisons
nicoburns 3y ago
Yeah, I'm quite hopeful that this is one where the developer backlash will cause a U-turn. I suspect it was seen as something that most people didn't care about, and now that it's clear that they do then likely something will be done about. I can't see any reason why Google would be strongly against it's inclusion.
RedShift1 3y ago
The called it technically inferior based on opinions. They didn't do a thorough technical review, and why would they, they have webp. This was absolutely a strategical thing, it's naive to think it isn't.

account42 3y ago

Agreed. It's especially infuriating that their arguments against jxl would have applied to webp too (even more so) but for some reason that was pushed trough (as were other Google formats).

markdog12 3y ago

Seems Safari has it enabled by default now, and Apple has support at the OS level. Firefox at least has it under a flag. Chrome team are the odd ones out here.

deleted 3y ago

[deleted]