Apple Safari 17 beta release notes: JPEG XL support added | Hacker News Reader

Apple Safari 17 beta release notes: JPEG XL support added

developer.apple.com

156 pointscroes59 comments

Your move, Chrome.

https://bugs.chromium.org/p/chromium/issues/detail?id=117805...

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.

Not exactly. Firefox had JPEG XL support in its nightly versions until January(?) 2023.

I thought it was flag-protected in Firefox, not actually supported?

Same was valid for Chrome, that's why it was ridiculous to claim lack of interest.

>(Could they even have supported it consistently across platforms due to the iOS limitation on all browsers needing to be implemented on WebKit?)

They same is true to WebP and AVIF?

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.)

> 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.

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.

All I learned from this is you gleefully accept corporate lip service

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.

Ah the politics of web standards. At least they aren’t bickering about support for the <marquee> tag or something.

Wonder what is happening behind closed doors in this squabble…

In the meantime you can use a polyfill: https://github.com/niutech/jxl.js

Thank you for posting something pragmatic in this oddly-emotional thread!

Would have been nice for somebody from Apple to chime in and say they intended to support 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?

Unless they were wrong in the first place?

[1] https://archive.is/MwJxy

JXL can losslessly recompress the billions of JPEG images out there, which AVIF cannot.

Also, from your link:

"JPEG XL has better lossless compression compared to WebP, which has better lossless compression compared to AVIF for these images."

I would then argue that the superiority of AVIF over JXL is a point of view at best.

Precisely.

Great comparision! as you can see on the linked page: https://storage.googleapis.com/avif-comparison/verification-...

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.

Apple is the most valuable company in the world.[0] Google isn't. I guess that's what it takes to implement JPEG XL in a browser.

partially \s

[0] https://companiesmarketcap.com/

Where is AV1 video playback?

A17 on iPhone 15 Pro this fall.

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.

I think the point is that you can then put multiple versions in it to get the best option supported in each browser.

There are lots of reasons why that's annoying to do, but it's a solution.

Yeah, uploading six versions of every image doesn't intersect with my definition of not caring.

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.)

https://github.com/niutech/jxl.js

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."

So what if you only care about JPEG-XL?

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.

Not everyone is using the web to blog you know... Imagine if google maps satellite view could save 30% of image bandwidth

> 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.

>you might as well support the far-more-popular WebP as well.

May be far more compatible. I am not sure if WebP is actually popular.

Every company I've worked at just serves images from something like Imgix or Cloudinary, which converts them on the fly. Never have to think about it.

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.

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://www.w3schools.com/html/html_images_picture.asp

> you can stop caring

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.

Otherwise, 100% agree: use picture.

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.

I saw that during WWDC and was like... "oh, really! Nice!".

I am curious if Bing will add support and embarrass Google.

you meant Edge, right?

They probably meant the Bing flavor of ChatGPT as a cheeky way of saying nobody uses Edge other than to get access to the chat bot.

Does it that mean that Chrome on Iphone will also support it since it's basically Safari with a Chrome skin?

Yes.

Also, Image decoders are part of the OS on Apple devices so likely all existing apps will support it automatically when iOS updates.

I’m running the iOS 17 beta. Currently, Chrome on iOS 17 does NOT support JPEG XL.

Woohoo. One advantage to the web browser monopoly on iOS. ;)

"No JPEG XL users" indeed.

I mean if we took that attitude to everything, we'd go no where.

It's a scoff at the reason Chromium removed its experimental JPEG XL support.

Yeah. As chungy said, one of the reasons for Chrome removing JXL was a lack of users.

Reply on news.ycombinator.com