Hacker News Reader

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.

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.

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.

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

>Adding image formats to the web should be the last step because it is so difficult to remove them.

Not from a company that added WebP to its browser and wanted a new video codec every 2 years.

> Using it via WASM is a strong indicator.

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

In that case they would have worded their rejection message differently.

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

Re-read this after-outrage-began-and-being-put-on-the-spot response with the new lens of "Non-browsers should add it first": https://groups.google.com/a/chromium.org/g/blink-dev/c/WjCKc...

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