I don't understand what you're trying to say. Mozilla said over a year ago that they would support JXL as soon as there's a fast memory safe decoder that will be supported.
Google on the other hand never expressed any desire to support JXL at all, regardless of the implementation. Only just now after the PDF Association announced that PDF would be using JXL, did they decide to support JXL on the web.
> avif is just better for typical web image quality, it produces better looking images and its artifacts aren't as annoying (smoothing instead of blocking and ringing around sharp edges).
AVIF is certainly better for the level of quality that Google wants you to use, but in reality, images on the web are much higher quality than that.
And JXL is pretty good if you want smoothing, in fact libjxl's defaults have gotten so overly smooth recently that it's considered a problem which they're in the process of fixing.
> I don't understand what you're trying to say. Mozilla said over a year ago that they would support JXL as soon as there's a fast memory safe decoder that will be supported.
Did they actually say that? All the statements i've seen them have been much more guarded and vauge. More of a, maybe we will think about it if that happens.
> If they successfully contribute an implementation that satisfies these properties and meets our normal production requirements, we would ship it.
That's what they said a year ago. And a couple of Mozilla devs have been in regular contact with the JXL devs ever since then, helping with the integration. The patches to use jxl-rs with Firefox already exist, and will be merged as soon as a couple of prerequisite issues in Gecko are fixed.
Their standards position is still neutral; what switched a year ago was that they said they would be open to shipping an implementation that met their requirements. The tracking bug hasn't been updated[2] The patches you mention are still part of the intent to prototype (behind a flag), similar to the earlier implementation that was removed in Chrome.
They're looking at the same signals as Chrome of a format that's actually getting use, has a memory safe implementation, and that will stick around for decades to justify adding it to the web platform, all of which seem more and more positive since 2022.
Google on the other hand never expressed any desire to support JXL at all, regardless of the implementation. Only just now after the PDF Association announced that PDF would be using JXL, did they decide to support JXL on the web.
> avif is just better for typical web image quality, it produces better looking images and its artifacts aren't as annoying (smoothing instead of blocking and ringing around sharp edges).
AVIF is certainly better for the level of quality that Google wants you to use, but in reality, images on the web are much higher quality than that.
And JXL is pretty good if you want smoothing, in fact libjxl's defaults have gotten so overly smooth recently that it's considered a problem which they're in the process of fixing.