Technically that's a fine idea, but practically - I think this will merely be a distraction and slow everything down. There's not a lot of point to brunsli if y

Technically that's a fine idea, but practically - I think this will merely be a distraction and slow everything down. There's not a lot of point to brunsli if you've got jxl, and brunsli would make further non-transcoding improvements that jxl also enables harder to reach. It's also going to be yet another adoption problem (though given chromium's market share I guess they can just force brunsli into real-world usage without firefox or even webkit support). Finally, if jxl falls through permanently and brunsli succeeds - it's still probably time to look for a new codec; perhaps AVIF might succeed where jxl wont (I hear your concerns, but that might be acceptable or improvable). After all, there's a very good chance that given the presence of the AV1 decoder the extra complexity of AVIF in chromium might be very small, which seems to be one of their concerns. AVIF might render brunsli the kind of intermediate step that's not worth it. I think voting up the issue is probably a quicker chance of getting a satisfactory resolution (simply supporting jxl). Alternately, perhaps a WASM based polyfill might be possible, and hope that if at least one other browser adopts it natively and a polyfill is available, that chrome will reconsider. Worst case - if this turns out to be irreversible - even then I think it's more strategic to let the inevitable dust this will cause settle, and then start picking up the pieces afterwards - the discussions in the interim might reveal more of the chromium teams reason for blocking this, which might inform future steps.