8 ms·

Chrome Responds "No" to JPEG XL

54 points by markdog12 4y ago

thih9 4y ago
> JPEG XL is a royalty-free raster-graphics file format that supports both lossy compression and lossless compression. It is designed to outperform existing raster formats and thus become their universal replacement. > The bitstream was informally frozen on 24 December 2020 (...) The file format and core coding system were formally standardized on 13 October 2021 and 30 March 2022 respectively. source: https://en.wikipedia.org/wiki/JPEG_XL https://en.wikipedia.org/wiki/JPEG_XL
- ddalex 4y ago
  " If a tree falls in a wood, and there is no one around, does it make a sound ?" - Chrome, probably
CharlesW 4y ago
Rationale from thread: > Helping the web to evolve is challenging, and it requires us to make difficult choices. We've also heard from our browser and device partners that every additional format adds costs (monetary or hardware), and we’re very much aware that these costs are borne by those outside of Google. When we evaluate new media formats, the first question we have to ask is whether the format works best for the web. With respect to new image formats such as JPEG XL, that means we have to look comprehensively at many factors: compression performance across a broad range of images; is the decoder fast, allowing for speedy rendering of smaller images; are there fast encoders, ideally with hardware support, that keep encoding costs reasonable for large users; can we optimize existing formats to meet any new use-cases, rather than adding support for an additional format; do other browsers and OSes support it? > After weighing the data, we’ve decided to stop Chrome’s JPEG XL experiment and remove the code associated with the experiment. We'll work to publish data in the next couple of weeks. > For those who want to use JPEG XL in Chrome, we believe a WebAssembly (Wasm) implementation is both performant and a great path forward. > Jim
- 1MachineElf 4y ago
  It was an opt-in feature, so what data did they weigh?
- excite1997 4y ago
  I think that's a fair argument, except they almost certainly did not apply the same yardstick to WebP.
  - birken 4y ago
    Well in fairness when WebP support was added in Chrome over 10 years ago it was a massive, massive improvement over the existing image formats that were being commonly used on the web. JPEG XL's problem is that WebP has now existed for 10 years and has widespread support.
    - ZeroGravitas 4y ago
      Firefox didn't add Webp support for a long time, because it wasn't a massive, massive improvement over the existing image formats. https://research.mozilla.org/2013/10/17/studying-lossy-image-compression-efficiency/ https://research.mozilla.org/2013/10/17/studying-lossy-image... More recent coverage: https://siipo.la/blog/is-webp-really-better-than-jpeg https://siipo.la/blog/is-webp-really-better-than-jpeg
      - alophawen 4y ago
        Neither of your links support your claim that Firefox avoided adding Webp support because it wasn't technically superiour. Instead, what happened was that WebP started to be used on the web and this broke websites for Firefox users. Since Firefox is by no means dominant on the web, we had to follow suit or lose more users.
        ZeroGravitas 4y ago
        I'm not sure what you are saying. Mozilla didn't support WebP for years. I'm fairly certain one of the official reasons they gave for not doing it was that it wasn't a massive jump in quality over JPEG, which obviously would have been good for the web if it was true and motivation for them to support it sooner than they did. Notably, when they did add it, Edge did so around the same time, which seems to me suggests some politics in the background, (not in a conspiracy sense, just an agreement based on interperability) which I suspect might apply this time too.
deleted 4y ago
[deleted]
ZeroGravitas 4y ago
I really like JPEG XL tech, seemed like the first format that could completely replace animated gif, png, jpeg with a simple upgrade path and backwards compatability story for lots of weird corner case usages. I do have sympathy for the not adding lots of formats to the web argument though.
- deleted 4y ago
  [deleted]
- JyrkiAlakuijala 4y ago
  we could still remove both WebP and AVIF and go with JPEG XL only
sedatk 4y ago
> We've also heard from our browser and device partners that every additional format adds costs (monetary or hardware), What's that mean? What's a browser partner? What's a device partner? How do additional formats cost to those "partners", as the format handling would be performed by Chrome already?
- ugjka 4y ago
  Phones, TVs, Toasters
  - sedatk 4y ago
    Okay, how does it cost to them?
    - anecdotal1 4y ago
      Yeah it's not like it's video and we need a hardware decoder. I doubt device vendors are thoroughly testing every image and video format that the software on the device can render. Smells to me like BS
Scaevolus 4y ago
Disappointing. I'll have to figure out the JXL WASM polyfill. Maybe if I wait a few months someone else will do it for me? There's https://github.com/GoogleChromeLabs/squoosh/tree/dev/codecs/jxl/dec https://github.com/GoogleChromeLabs/squoosh/tree/dev/codecs/... that provides `JXLModule.decode(data: BufferSource): ImageData | null`, but for a polyfill I suspect you'd want a method to get the dimensions of the image and an IntersectionObserver to defer actually decoding the image until it scrolls into view. Having to load the image with XHR is annoying.
- Gigachad 4y ago
  If hardware decoding support wasn't going to happen, is there really any problem with a polyfill since presumably the performance would be similar? I suppose if it's just one image, the weight of the polyfill download may make the savings in image compression worthless.
- JyrkiAlakuijala 4y ago
  several wasm solutions will soon appear in libjxl github
jpgvm 4y ago
So does this mean we are getting AVIF or WebP or both? It's not clear to me which is the "blessed" format out of these. HEIC is ofcourse there but proprietary.
- gjsman-1000 4y ago
  WebP has been in Chrome for years, and isn't going anywhere. WebP2 is cancelled. AVIF is still arriving and is Chrome's preferred choice over JXL. HEIC was not supported by Chrome until recently, but only on devices where the manufacturers already paid for decoding. One advantage for AVIF is that an AVIF file is very close to just being an AV1 still, so if you implement AV1, you've basically got 95% of AVIF already. AVIF is also now natively supported by both Windows, macOS, iOS, and Android, whereas JXL is supported natively by none. The fact that AVIF has gotten OS-level support and JXL hasn't is a sign JXL is dead.
  - jpgvm 4y ago
    Thanks for a concise lay of the land, I'm curious about this stuff but not on top enough of the happenings.
bragr 4y ago
>After weighing the data, we’ve decided to stop Chrome’s JPEG XL experiment and remove the code associated with the experiment. We'll work to publish data in the next couple of weeks. You know, if you did that in the other order, you might avoid a lot of sturm und drang.
dang 4y ago
Related: Removing the JPEG XL code and flag from Chromium - https://news.ycombinator.com/item?id=33412340 https://news.ycombinator.com/item?id=33412340 - Oct 2022 (42 comments) Chrome drops JPEG XL, “not enough interest” - https://news.ycombinator.com/item?id=33404840 https://news.ycombinator.com/item?id=33404840 - Oct 2022 (4 comments) Google set to deprecate JPEG XL support in Chrome 110 - https://news.ycombinator.com/item?id=33399940 https://news.ycombinator.com/item?id=33399940 - Oct 2022 (93 comments) Google Chrome Is Already Preparing to Deprecate JPEG-XL - https://news.ycombinator.com/item?id=33383880 https://news.ycombinator.com/item?id=33383880 - Oct 2022 (20 comments) Also: The case for JPEG XL - https://news.ycombinator.com/item?id=33442281 https://news.ycombinator.com/item?id=33442281 - Nov 2022 (207 comments) Is there SNI (https://hn.algolia.com/?dateRange=all&page=0&prefix=false&sort=byDate&type=comment&query=%22significant%20new%20information%22%20by%3Adang https://hn.algolia.com/?dateRange=all&page=0&prefix=false&so...) in the current post? - if there is I can't find it.
- markdog12 4y ago
  I posted it because there has been a lot of activity, interested parties, etc.. on https://bugs.chromium.org/p/chromium/issues/detail?id=1178058#c84 https://bugs.chromium.org/p/chromium/issues/detail?id=117805..., waiting for some kind of reply from the Chrome team. Despite interest, it looks like they haven't changed their mind, given the link I posted, and I thought it merited discussion.
  - pvg 4y ago
    The interest is largely contained to that issue and its forum and you've already had the issue itself discussed in a recent post (beside the other recent posts). The overlap between advocacy and interesting conversation is not zero but repetitions diminish it a lot. And just generally, even if it's not the intent, posting project bug trackers on HN (which is much bigger than most bug trackers) tends to have effect of brigading the particular issue which is not great for the project and not great for HN.
RedShift1 4y ago
This is ridiculous. Chrome's influence is too big and Google is basically dictating how the web works. The whole world must bow to what a select group of people decide. This internet explorer level of oppression has to stop.
- RedShift1 4y ago
  Sure. Downvote me. Perhaps you weren't around when IE was still a thing. As a webdesigner back in those days your job was basically working around IE6's limitations and quirks. _You couldn't even use transparant PNG's ffs_. MS didn't give a flying F and only started improving IE again when they started losing big chunks of marketshare. We are heading towards that exact same situation right now.
twotwotwo 4y ago
They have not closed a narrower bug about the lossless JPEG compression: https://bugs.chromium.org/p/chromium/issues/detail?id=1109698 https://bugs.chromium.org/p/chromium/issues/detail?id=110969... I think it's a legitimately different tradeoff because the recompression is not like a new lossy format--less code, plus you don't need the whole ecosystem to move, big sites and CDNs can transparently start using it--but still substantial (22% on JPEG content out there). And by being very CPU-light it fills a fairly large gap where people are not ready to use AVIF, which needs either dedicated hardware or tons of CPU to encode. One thing this is right about is a WASM polyfill is interesting. With that and a ServiceWorker, you can make the recompression pretty transparent (right-click saves a .jpg) but still save your 22%. The performance penalty of doing it in WASM is a question, but it's definitely possible.
- mike_hearn 4y ago
  The problem with using WASM is that because of their cache segmentation, every site that wants to render JXL would have to redownload the WASM decoder from scratch, and every page load that wants to render it would presumably have to JITC it from scratch too. The WASM model doesn't seem to be a good replacement for browser plugins. Amusingly, when Chrome killed off plugins one of the rationales they gave was "reducing code complexity". The enormous bloat in the code and HTML5 specs that followed did many things, but reducing Chrome's code complexity isn't one of them.
  - edflsafoiewq 4y ago
    The problem with using WASM is it doesn't create an ecosystem where you can save the JXL, open it in a editor, upload it yourself, etc. like a normal image file.
  - twotwotwo 4y ago
    A JXL contributor says full JXL (not just the recompression) can fit in 174kB, and thinks a smaller version could fit in 50: https://news.ycombinator.com/item?id=33414678 https://news.ycombinator.com/item?id=33414678 If you have large JPEGs it's not hard to earn the bandwidth cost back. I am definitely curious about other aspects of WASM performance including speed on first run.
sedatk 4y ago
Could supporting JPEG XL natively be an opportunity for Edge and Firefox to compete with Chrome seriously?
edflsafoiewq 4y ago
I increasingly despair over the possibility of any new image format getting traction. That means support in web browsers (functionally, Chrome) and on desktop (Windows explorer, etc.). WebP is probably the one that's advanced the furthest but AFAIK it doesn't even get thumbnailed in the Windows file browser and normies absolutely hate it since it won't work everywhere a PNG or JPEG will.
- shrimp_emoji 4y ago
  I'm not a normie, but I also hate WEBP "since it won't work everywhere a PNG or JPEG will" (i.e., an image viewer).
  - Macha 4y ago
    It's been a while since I've used an image viewer that doesn't support webp, to be fair.
    - Zandikar 4y ago
      To be fair, there is no bundled or built in app in windows 11 that associates with or can view webp by default. Edge can, but that's not a photo app, and you have to explicitly tell it to (open with) or explicitly associate it with that file type. In other words, it's not natively supported in the current version of Windows. That's a trivial "problem" for the HackerNews audience, but it's a pain point for webp with the broader windows audience.
mkl95 4y ago
> We've also heard from our browser and device partners that every additional format adds costs (monetary or hardware), and we’re very much aware that these costs are borne by those outside of Google To add some info, JPEG XL can still be enabled on the latest Edge, Opera, and Firefox Nightly versions. It can be enabled on Chrome 91 - 110 (not included).
least 4y ago
It's hard to be anything but skeptical about the intent behind this decision, considering that the competing emerging standard (WebP) is one that Google controls. This is one reason why I am thankful that Apple still only allows webkit on iOS even if philosophically I believe people should be able to run the software they want on their phone — it's basically the only check against pure Google hegemony over the web. > can we optimize existing formats to meet any new use-cases, rather than adding support for an additional format; do other browsers and OSes support it? They did not show this restraint at all when it came to implementing and pushing their own formats.
- jsnell 4y ago
  This is a really strange take, because Apple does not support JPEG XL and was never going to support it. And since nobody else can bring that support to iOS either, the format as a whole is dead to the web. (And, uh, I don't know where you're getting webp from here. The competition for this generation of image formats is AVIF; AVIF has been blessed by Apple, so no matter how distasteful it is that's what we'll get.) > They did not show this restraint at all when it came to implementing and pushing their own formats. JPEG XL was largely a Google-created format.
  - jonsneyers 4y ago
    The Chrome team did not create JPEG XL, that was a totally different team. The Chrome team did create WebP and was heavily involved in the creation of AVIF.
rektide 4y ago
Is it possible to still write pages with JXL as an option a xompatibpe browser could use/prefer? It'd be great to see this just keep happening anyways. Is this just a content-negotiation question? How else might a page declare it would like to use certain resources, if the broeser supports it, else fallback?
- Wevah 4y ago
  Sure, with the <picture> element: https://developer.mozilla.org/en-US/docs/Web/HTML/Element/picture https://developer.mozilla.org/en-US/docs/Web/HTML/Element/pi...

54 points by markdog12 4y ago

> JPEG XL is a royalty-free raster-graphics file format that supports both lossy compression and lossless compression. It is designed to outperform existing raster formats and thus become their universal replacement. > The bitstream was informally frozen on 24 December 2020 (...) The file format and core coding system were formally standardized on 13 October 2021 and 30 March 2022 respectively. source: https://en.wikipedia.org/wiki/JPEG_XL https://en.wikipedia.org/wiki/JPEG_XL

ddalex 4y ago
" If a tree falls in a wood, and there is no one around, does it make a sound ?" - Chrome, probably

CharlesW 4y ago

Rationale from thread: > Helping the web to evolve is challenging, and it requires us to make difficult choices. We've also heard from our browser and device partners that every additional format adds costs (monetary or hardware), and we’re very much aware that these costs are borne by those outside of Google. When we evaluate new media formats, the first question we have to ask is whether the format works best for the web. With respect to new image formats such as JPEG XL, that means we have to look comprehensively at many factors: compression performance across a broad range of images; is the decoder fast, allowing for speedy rendering of smaller images; are there fast encoders, ideally with hardware support, that keep encoding costs reasonable for large users; can we optimize existing formats to meet any new use-cases, rather than adding support for an additional format; do other browsers and OSes support it? > After weighing the data, we’ve decided to stop Chrome’s JPEG XL experiment and remove the code associated with the experiment. We'll work to publish data in the next couple of weeks. > For those who want to use JPEG XL in Chrome, we believe a WebAssembly (Wasm) implementation is both performant and a great path forward. > Jim

1MachineElf 4y ago
It was an opt-in feature, so what data did they weigh?
excite1997 4y ago
I think that's a fair argument, except they almost certainly did not apply the same yardstick to WebP.
- birken 4y ago
  Well in fairness when WebP support was added in Chrome over 10 years ago it was a massive, massive improvement over the existing image formats that were being commonly used on the web. JPEG XL's problem is that WebP has now existed for 10 years and has widespread support.
  - ZeroGravitas 4y ago
    Firefox didn't add Webp support for a long time, because it wasn't a massive, massive improvement over the existing image formats. https://research.mozilla.org/2013/10/17/studying-lossy-image-compression-efficiency/ https://research.mozilla.org/2013/10/17/studying-lossy-image... More recent coverage: https://siipo.la/blog/is-webp-really-better-than-jpeg https://siipo.la/blog/is-webp-really-better-than-jpeg
    - alophawen 4y ago
      Neither of your links support your claim that Firefox avoided adding Webp support because it wasn't technically superiour. Instead, what happened was that WebP started to be used on the web and this broke websites for Firefox users. Since Firefox is by no means dominant on the web, we had to follow suit or lose more users.
      - ZeroGravitas 4y ago
        I'm not sure what you are saying. Mozilla didn't support WebP for years. I'm fairly certain one of the official reasons they gave for not doing it was that it wasn't a massive jump in quality over JPEG, which obviously would have been good for the web if it was true and motivation for them to support it sooner than they did. Notably, when they did add it, Edge did so around the same time, which seems to me suggests some politics in the background, (not in a conspiracy sense, just an agreement based on interperability) which I suspect might apply this time too.

deleted 4y ago

[deleted]

ZeroGravitas 4y ago

I really like JPEG XL tech, seemed like the first format that could completely replace animated gif, png, jpeg with a simple upgrade path and backwards compatability story for lots of weird corner case usages. I do have sympathy for the not adding lots of formats to the web argument though.

deleted 4y ago
[deleted]
JyrkiAlakuijala 4y ago
we could still remove both WebP and AVIF and go with JPEG XL only

sedatk 4y ago

> We've also heard from our browser and device partners that every additional format adds costs (monetary or hardware), What's that mean? What's a browser partner? What's a device partner? How do additional formats cost to those "partners", as the format handling would be performed by Chrome already?

ugjka 4y ago
Phones, TVs, Toasters
- sedatk 4y ago
  Okay, how does it cost to them?
  - anecdotal1 4y ago
    Yeah it's not like it's video and we need a hardware decoder. I doubt device vendors are thoroughly testing every image and video format that the software on the device can render. Smells to me like BS

Scaevolus 4y ago

Disappointing. I'll have to figure out the JXL WASM polyfill. Maybe if I wait a few months someone else will do it for me? There's https://github.com/GoogleChromeLabs/squoosh/tree/dev/codecs/jxl/dec https://github.com/GoogleChromeLabs/squoosh/tree/dev/codecs/... that provides `JXLModule.decode(data: BufferSource): ImageData | null`, but for a polyfill I suspect you'd want a method to get the dimensions of the image and an IntersectionObserver to defer actually decoding the image until it scrolls into view. Having to load the image with XHR is annoying.

Gigachad 4y ago
If hardware decoding support wasn't going to happen, is there really any problem with a polyfill since presumably the performance would be similar? I suppose if it's just one image, the weight of the polyfill download may make the savings in image compression worthless.
JyrkiAlakuijala 4y ago
several wasm solutions will soon appear in libjxl github

jpgvm 4y ago

So does this mean we are getting AVIF or WebP or both? It's not clear to me which is the "blessed" format out of these. HEIC is ofcourse there but proprietary.

gjsman-1000 4y ago
WebP has been in Chrome for years, and isn't going anywhere. WebP2 is cancelled. AVIF is still arriving and is Chrome's preferred choice over JXL. HEIC was not supported by Chrome until recently, but only on devices where the manufacturers already paid for decoding. One advantage for AVIF is that an AVIF file is very close to just being an AV1 still, so if you implement AV1, you've basically got 95% of AVIF already. AVIF is also now natively supported by both Windows, macOS, iOS, and Android, whereas JXL is supported natively by none. The fact that AVIF has gotten OS-level support and JXL hasn't is a sign JXL is dead.
- jpgvm 4y ago
  Thanks for a concise lay of the land, I'm curious about this stuff but not on top enough of the happenings.

bragr 4y ago

>After weighing the data, we’ve decided to stop Chrome’s JPEG XL experiment and remove the code associated with the experiment. We'll work to publish data in the next couple of weeks. You know, if you did that in the other order, you might avoid a lot of sturm und drang.

dang 4y ago

Related: Removing the JPEG XL code and flag from Chromium - https://news.ycombinator.com/item?id=33412340 https://news.ycombinator.com/item?id=33412340 - Oct 2022 (42 comments) Chrome drops JPEG XL, “not enough interest” - https://news.ycombinator.com/item?id=33404840 https://news.ycombinator.com/item?id=33404840 - Oct 2022 (4 comments) Google set to deprecate JPEG XL support in Chrome 110 - https://news.ycombinator.com/item?id=33399940 https://news.ycombinator.com/item?id=33399940 - Oct 2022 (93 comments) Google Chrome Is Already Preparing to Deprecate JPEG-XL - https://news.ycombinator.com/item?id=33383880 https://news.ycombinator.com/item?id=33383880 - Oct 2022 (20 comments) Also: The case for JPEG XL - https://news.ycombinator.com/item?id=33442281 https://news.ycombinator.com/item?id=33442281 - Nov 2022 (207 comments) Is there SNI (https://hn.algolia.com/?dateRange=all&page=0&prefix=false&sort=byDate&type=comment&query=%22significant%20new%20information%22%20by%3Adang https://hn.algolia.com/?dateRange=all&page=0&prefix=false&so...) in the current post? - if there is I can't find it.

markdog12 4y ago
I posted it because there has been a lot of activity, interested parties, etc.. on https://bugs.chromium.org/p/chromium/issues/detail?id=1178058#c84 https://bugs.chromium.org/p/chromium/issues/detail?id=117805..., waiting for some kind of reply from the Chrome team. Despite interest, it looks like they haven't changed their mind, given the link I posted, and I thought it merited discussion.
- pvg 4y ago
  The interest is largely contained to that issue and its forum and you've already had the issue itself discussed in a recent post (beside the other recent posts). The overlap between advocacy and interesting conversation is not zero but repetitions diminish it a lot. And just generally, even if it's not the intent, posting project bug trackers on HN (which is much bigger than most bug trackers) tends to have effect of brigading the particular issue which is not great for the project and not great for HN.

RedShift1 4y ago

This is ridiculous. Chrome's influence is too big and Google is basically dictating how the web works. The whole world must bow to what a select group of people decide. This internet explorer level of oppression has to stop.

RedShift1 4y ago
Sure. Downvote me. Perhaps you weren't around when IE was still a thing. As a webdesigner back in those days your job was basically working around IE6's limitations and quirks. _You couldn't even use transparant PNG's ffs_. MS didn't give a flying F and only started improving IE again when they started losing big chunks of marketshare. We are heading towards that exact same situation right now.

twotwotwo 4y ago

They have not closed a narrower bug about the lossless JPEG compression: https://bugs.chromium.org/p/chromium/issues/detail?id=1109698 https://bugs.chromium.org/p/chromium/issues/detail?id=110969... I think it's a legitimately different tradeoff because the recompression is not like a new lossy format--less code, plus you don't need the whole ecosystem to move, big sites and CDNs can transparently start using it--but still substantial (22% on JPEG content out there). And by being very CPU-light it fills a fairly large gap where people are not ready to use AVIF, which needs either dedicated hardware or tons of CPU to encode. One thing this is right about is a WASM polyfill is interesting. With that and a ServiceWorker, you can make the recompression pretty transparent (right-click saves a .jpg) but still save your 22%. The performance penalty of doing it in WASM is a question, but it's definitely possible.

mike_hearn 4y ago
The problem with using WASM is that because of their cache segmentation, every site that wants to render JXL would have to redownload the WASM decoder from scratch, and every page load that wants to render it would presumably have to JITC it from scratch too. The WASM model doesn't seem to be a good replacement for browser plugins. Amusingly, when Chrome killed off plugins one of the rationales they gave was "reducing code complexity". The enormous bloat in the code and HTML5 specs that followed did many things, but reducing Chrome's code complexity isn't one of them.
- edflsafoiewq 4y ago
  The problem with using WASM is it doesn't create an ecosystem where you can save the JXL, open it in a editor, upload it yourself, etc. like a normal image file.
- twotwotwo 4y ago
  A JXL contributor says full JXL (not just the recompression) can fit in 174kB, and thinks a smaller version could fit in 50: https://news.ycombinator.com/item?id=33414678 https://news.ycombinator.com/item?id=33414678 If you have large JPEGs it's not hard to earn the bandwidth cost back. I am definitely curious about other aspects of WASM performance including speed on first run.

sedatk 4y ago

Could supporting JPEG XL natively be an opportunity for Edge and Firefox to compete with Chrome seriously?

edflsafoiewq 4y ago

I increasingly despair over the possibility of any new image format getting traction. That means support in web browsers (functionally, Chrome) and on desktop (Windows explorer, etc.). WebP is probably the one that's advanced the furthest but AFAIK it doesn't even get thumbnailed in the Windows file browser and normies absolutely hate it since it won't work everywhere a PNG or JPEG will.

shrimp_emoji 4y ago
I'm not a normie, but I also hate WEBP "since it won't work everywhere a PNG or JPEG will" (i.e., an image viewer).
- Macha 4y ago
  It's been a while since I've used an image viewer that doesn't support webp, to be fair.
  - Zandikar 4y ago
    To be fair, there is no bundled or built in app in windows 11 that associates with or can view webp by default. Edge can, but that's not a photo app, and you have to explicitly tell it to (open with) or explicitly associate it with that file type. In other words, it's not natively supported in the current version of Windows. That's a trivial "problem" for the HackerNews audience, but it's a pain point for webp with the broader windows audience.

mkl95 4y ago

> We've also heard from our browser and device partners that every additional format adds costs (monetary or hardware), and we’re very much aware that these costs are borne by those outside of Google To add some info, JPEG XL can still be enabled on the latest Edge, Opera, and Firefox Nightly versions. It can be enabled on Chrome 91 - 110 (not included).

least 4y ago

It's hard to be anything but skeptical about the intent behind this decision, considering that the competing emerging standard (WebP) is one that Google controls. This is one reason why I am thankful that Apple still only allows webkit on iOS even if philosophically I believe people should be able to run the software they want on their phone — it's basically the only check against pure Google hegemony over the web. > can we optimize existing formats to meet any new use-cases, rather than adding support for an additional format; do other browsers and OSes support it? They did not show this restraint at all when it came to implementing and pushing their own formats.

jsnell 4y ago
This is a really strange take, because Apple does not support JPEG XL and was never going to support it. And since nobody else can bring that support to iOS either, the format as a whole is dead to the web. (And, uh, I don't know where you're getting webp from here. The competition for this generation of image formats is AVIF; AVIF has been blessed by Apple, so no matter how distasteful it is that's what we'll get.) > They did not show this restraint at all when it came to implementing and pushing their own formats. JPEG XL was largely a Google-created format.
- jonsneyers 4y ago
  The Chrome team did not create JPEG XL, that was a totally different team. The Chrome team did create WebP and was heavily involved in the creation of AVIF.

rektide 4y ago

Is it possible to still write pages with JXL as an option a xompatibpe browser could use/prefer? It'd be great to see this just keep happening anyways. Is this just a content-negotiation question? How else might a page declare it would like to use certain resources, if the broeser supports it, else fallback?

Wevah 4y ago
Sure, with the <picture> element: https://developer.mozilla.org/en-US/docs/Web/HTML/Element/picture https://developer.mozilla.org/en-US/docs/Web/HTML/Element/pi...