I don't speak for Google/Chrome but I really need to clarify something that keeps being misstated:
The test of JPEG XL support has been removed.
It was always behind a flag and never actually supported. That is not to say that Chrome will not ever support JPEG XL. The two concepts are fundamentally unrelated. So we should stop conflating them.
In fact, it could be that the test was successful and now Chrome is waiting on something else before it adds proper support. I would argue this is likely the case. And the thing they should be waiting on IMHO is wide spread support.
Adding image formats to the web should be the last step because it is so difficult to remove them. I bet other browser devs in the image space wish they could remove ico support. Oh well.
"So why add it in a test just to later remove it?" I hear someone ask. Because you want to make sure that path is clear and you're in position long before it is needed. Once you know the path is clear, you don't want to keep dead code around. It is easy enough to dig it out of old commits when the time comes.
Heck, it could even be as simple as someone wanted to add a big item to their promo packet. Who knows.
But at the end of the day, Chrome did not remove JPEG XL support. And I haven't seen anything saying Chrome wouldn't later add it. If we all want JPEG XL (I do), we should continue to help its adoption grow. Using it via WASM is a strong indicator. Get it to the point where "of course Chrome will add support -- it is everywhere".
I think it's fine to assume the more likely interpretation that this company simply isn't interested in the format anymore, rather than whatever larger stretch you're describing here. "You don't want to keep dead code around." That's rich :) maybe if this was some one person hobby project or something.
I strongly disagree with "more likely interpretation". For several reasons:
- FireFox & Safari also don't fully support it. For your claim to be true, Google would need to be in control of them, too.
- I still get nag emails that I'm long overdue to remove dead test code from my Chromium tests. I'm being a bad person to other Chromium devs by being lazy and not getting around to it.
I think it is far more likely that they ran a test and know they're ready to support JPEG XL when the time comes. And that time (IMHO) is when there is already wide spread support outside of browsers. Browsers should be the last ones to add it. Not the first.
Chrome supports plenty of things that are unsupported by Firefox and Safari. E.g. you get set the audio sink id on individual media elements in Chrome. You can’t do that in Safari and Firefox.
Cleaning up code is something I get great pleasure. It not only makes navigating the code base easier for people new to the code base won't look at something that isn't ever actually run in production. It also prevents people from depending on something that we don't really want to be used anymore.
> In fact, it could be that the test was successful and now Chrome is waiting on something else before it adds proper support.
Waiting for libjxl 1.0 is reasonable. Though I can't help but to think it would be less work to just keep the experimental feature in there until it is stable.
Is there a good way to do that, though? What I think will needing to do properly:
1. You can implement picture/audio/video/document file formats as extensions, without needing to intercept requests/responses (so that save, view-source, etc will still access the original file). (I think some versions of Mozilla have this capability (although some details of the design are not as good as they could have been), but as far as I know, WebExtensions does not.)
2. Extensions can be native codes, WebAssembly codes, or JavaScript codes. (Native extensions will be excluded from the extensions catalog, and the end user or system administrator must install them manually.)
3. Add a "Interpreter" response header, to indicate what to do if the browser does not understand the file format. For example, this might link to an implementation of that file format in WebAssembly.
4. Such WebAssembly programs can also be used outside of a web browser, in local standalone programs. For example, an external program might run the WebAssembly code to convert data from stdin to stdout.
> In fact, it could be that the test was successful and now Chrome is waiting on something else before it adds proper support. I would argue this is likely the case.
If Chrome deems that something is useful (to them, for some definition of useful), they just release it (and if this something was on a standards track, too bad, it's out now).
I don't know about that. Some of the first responses I saw were along the lines of "It was a test. Tests have end dates. When that end date comes, the code gets removed unless it is being committed to full support."
Doesn't it now read like the bulk of the message is other's support? And the internal debate of "Should we be the ones to push this first, despite other's support and objections and browsers ideally adding support last?"
EDIT: To help clarify what I mean, let me insert my thoughts here inside a quote:
"When we evaluate new media formats [new as in not yet widely supported], the first question we have to ask is whether the format works best for the web [which is why it isn't yet widely supported -- IE it should actually come to browser first]."
The test of JPEG XL support has been removed.
It was always behind a flag and never actually supported. That is not to say that Chrome will not ever support JPEG XL. The two concepts are fundamentally unrelated. So we should stop conflating them.
In fact, it could be that the test was successful and now Chrome is waiting on something else before it adds proper support. I would argue this is likely the case. And the thing they should be waiting on IMHO is wide spread support.
Adding image formats to the web should be the last step because it is so difficult to remove them. I bet other browser devs in the image space wish they could remove ico support. Oh well.
"So why add it in a test just to later remove it?" I hear someone ask. Because you want to make sure that path is clear and you're in position long before it is needed. Once you know the path is clear, you don't want to keep dead code around. It is easy enough to dig it out of old commits when the time comes.
Heck, it could even be as simple as someone wanted to add a big item to their promo packet. Who knows.
But at the end of the day, Chrome did not remove JPEG XL support. And I haven't seen anything saying Chrome wouldn't later add it. If we all want JPEG XL (I do), we should continue to help its adoption grow. Using it via WASM is a strong indicator. Get it to the point where "of course Chrome will add support -- it is everywhere".