Viewing a single comment thread. View all comments

gurenkagurenda t1_iugn8q9 wrote

Reply to comment by xeeeeeeeeeeeeeeeeenu in Google Outlines Why They Are Removing JPEG-XL Support From Chrome by DirectControlAssumed

The specific wording is:

> There is not enough interest from the entire ecosystem to continue experimenting with JPEG XL

I think what they mean is that other browsers weren't moving to support it (no Safari support, and Firefox support only in nightlies, afaict).

This really doesn't seem that baffling to me. At the very least least, I don't have to speculate very far to make it seem anything other than mundane.

For example, suppose one engineer took this support on as their pet project, and now they've moved on to other things (pretty typical at Google, from what I understand). Image decoders are complicated, highly optimized code, so they're ripe for security flaws and have to be actively maintained. So you've got a possible attack vector with no maintainer, which nobody is actually using (because it's behind a flag), and no new movement on it becoming a de facto web standard. And of course, the spec is right there (as is the old code), so if that situation changes, you can just put it back and actually dedicate resources to it. That all sounds like business as usual in the software industry.

5

xeeeeeeeeeeeeeeeeenu t1_iugrfyl wrote

> I think what they mean is that other browsers weren't moving to support it (no Safari support, and Firefox support only in nightlies, afaict).

Chrome was the first browser to support WebP and AVIF, they didn't wait for other vendors to implement it. In practice Google is the one who dictates web standards, the others follow them. It's not surprising considering that Blink-based browsers have >70% market share.

>This really doesn't seem that baffling to me. At the very least least, I don't have to speculate very far to make it seem anything other than mundane.

>For example, suppose one engineer took this support on as their pet project, and now they've moved on to other things (pretty typical at Google, from what I understand). Image decoders are complicated, highly optimized code, so they're ripe for security flaws and have to be actively maintained. So you've got a possible attack vector with no maintainer, which nobody is actually using (because it's behind a flag), and no new movement on it becoming a de facto web standard. And of course, the spec is right there (as is the old code), so if that situation changes, you can just put it back and actually dedicate resources to it. That all sounds like business as usual in the software industry.

Right, and none of those considerations apply to WebP and AVIF. In fact, AVIF was enabled by default in production releases immediately, there was no experimental period.

5

gurenkagurenda t1_iuhcw08 wrote

Sure, they’re playing favorites with the tech they’ve invested in and backed. The point is that the JPEG-XL situation is the normal case.

If the principal leans on a teacher and they give a passing grade to the star football player so he remains in good academic standing, but then the teacher fails another student who has a similar performance, there’s nothing baffling about either case, and certainly not about the student the teacher failed. The favoritism is bad, but the fact that they failed the one student is the normal situation.

4