6 ms·

> so do we think Chrome will reverse their decision to drop support? The argument was that there's no industry support (apparently this means: beyond words in

> so do we think Chrome will reverse their decision to drop support? The argument was that there's no industry support (apparently this means: beyond words in an issue tracker), let's see how acceptance is with Safari supporting it. An uptick in JXL use sounds like a good-enough reason to re-add JXL support, this time not behind an experimental flag. Maybe Firefox even decides to provide it without a flag and in their regular user build.

mgaunard 3y ago
We all know what the real argument is: NIH.
- bbatsell 3y ago
  One of the three main authors of JXL works for Google. But in the Google Research Zurich office, so he might as well not exist to the Chrome team, I guess.
  - deleted 3y ago
    [deleted]
- masklinn 3y ago
  Ah yes, NIH from a contributor to the spec, makes complete sense.
  - mrguyorama 3y ago
    [flagged]
    - pgeorgi 3y ago
      Same with av1. It's not verbatim vp10, but incorporates concepts developed by xiph.org and Cisco (and whoever else).
    - ruuda 3y ago
      This is definitely not the case, the team behind Pik is eager to get JPEG XL deployed, but Chrome is blocking it.
      - mrguyorama 3y ago
        I'm not sure what we are misunderstanding from each other. I'm saying google could very well be blocking it's deployment in chrome because it is not the implementation they originally came forward with if they are that petty and NIH.
        vanderZwan 3y ago
        The team that wrote the original Google proposal (PIK) joined forces with the team that wrote FUIF and together they created JXL, so no, those particular Googlers are not petty about this. They're a distinct team from the Chrome team though.
    - alickz 3y ago
      While that's a possibility the article made it seem like Google's PIK team and Cloudinary worked together on JPEGXL
  - mgaunard 3y ago
    I've seen people rage-quit because their work was standardized but with modifications they themselves didn't approve of.
- hortense 3y ago
  Last time I looked, all the top commiters were from Google.
jorvi 3y ago
What I don’t understand is, why still push for JPEG XL when webP already has a lot of support and AVIF has a lot of momentum?
- pgeorgi 3y ago
  According to the article, WebP requires more CPU to decode. JPEG XL also supports lossless transcoding from JPEG, so it could be used for old image sets with no loss in image fidelity. There are arguments for the new format, but the Chrome people seemed unwilling to maintain support for it when pick-up was non-existent (Firefox could have moved it out of their purgatory. Safari could have implemented it earlier. Edge could have enabled it by default. Sites could use polyfills to demonstrate that they want the desirable properties. And so on.) To me, the situation was one of "If Chrome enables it, people will whine how Chrome forces file formats onto everybody, making the web platform harder to reimplement, a clear signal of domination. If they don't enable it, people will whine how Chrome doesn't push the format, a clear signal of domination", and they chose to use the variant of the lose-lose scenario that means less work down the road.
  - cubefox 3y ago
    > There are arguments for the new format, but the Chrome people seemed unwilling to maintain support for it when pick-up was non-existent Of course there is no pick-up when Chrome, with its massive market share, doesn't support it. Demanding pick-up before support makes no sense for an entity with such a large dominance.
    - pgeorgi 3y ago
      - Polyfills (there _is_ polyfill-enabling code - maintained by Chrome devs.) - Microsoft enabling the flag in Edge by default and telling people that websites can be 30% smaller/faster in Edge, automatically adding JXL conversion in their web frameworks - Apple doing the same with Safari (what they're _now_ doing) - Mozilla doing the same with Firefox (instead of hiding that feature in a developer-only build behind a flag) None of that happened so far, only the mixed signal of "lead and we'll follow" and "you are too powerful, stop dominating us." in some issue tracker _after_ the code has been removed.

mgaunard 3y ago

We all know what the real argument is: NIH.

bbatsell 3y ago
One of the three main authors of JXL works for Google. But in the Google Research Zurich office, so he might as well not exist to the Chrome team, I guess.
- deleted 3y ago
  [deleted]
masklinn 3y ago
Ah yes, NIH from a contributor to the spec, makes complete sense.
- mrguyorama 3y ago
  [flagged]
  - pgeorgi 3y ago
    Same with av1. It's not verbatim vp10, but incorporates concepts developed by xiph.org and Cisco (and whoever else).
  - ruuda 3y ago
    This is definitely not the case, the team behind Pik is eager to get JPEG XL deployed, but Chrome is blocking it.
    - mrguyorama 3y ago
      I'm not sure what we are misunderstanding from each other. I'm saying google could very well be blocking it's deployment in chrome because it is not the implementation they originally came forward with if they are that petty and NIH.
      - vanderZwan 3y ago
        The team that wrote the original Google proposal (PIK) joined forces with the team that wrote FUIF and together they created JXL, so no, those particular Googlers are not petty about this. They're a distinct team from the Chrome team though.
  - alickz 3y ago
    While that's a possibility the article made it seem like Google's PIK team and Cloudinary worked together on JPEGXL
- mgaunard 3y ago
  I've seen people rage-quit because their work was standardized but with modifications they themselves didn't approve of.
hortense 3y ago
Last time I looked, all the top commiters were from Google.

jorvi 3y ago

What I don’t understand is, why still push for JPEG XL when webP already has a lot of support and AVIF has a lot of momentum?

pgeorgi 3y ago
According to the article, WebP requires more CPU to decode. JPEG XL also supports lossless transcoding from JPEG, so it could be used for old image sets with no loss in image fidelity. There are arguments for the new format, but the Chrome people seemed unwilling to maintain support for it when pick-up was non-existent (Firefox could have moved it out of their purgatory. Safari could have implemented it earlier. Edge could have enabled it by default. Sites could use polyfills to demonstrate that they want the desirable properties. And so on.) To me, the situation was one of "If Chrome enables it, people will whine how Chrome forces file formats onto everybody, making the web platform harder to reimplement, a clear signal of domination. If they don't enable it, people will whine how Chrome doesn't push the format, a clear signal of domination", and they chose to use the variant of the lose-lose scenario that means less work down the road.
- cubefox 3y ago
  > There are arguments for the new format, but the Chrome people seemed unwilling to maintain support for it when pick-up was non-existent Of course there is no pick-up when Chrome, with its massive market share, doesn't support it. Demanding pick-up before support makes no sense for an entity with such a large dominance.
  - pgeorgi 3y ago
    - Polyfills (there _is_ polyfill-enabling code - maintained by Chrome devs.) - Microsoft enabling the flag in Edge by default and telling people that websites can be 30% smaller/faster in Edge, automatically adding JXL conversion in their web frameworks - Apple doing the same with Safari (what they're _now_ doing) - Mozilla doing the same with Firefox (instead of hiding that feature in a developer-only build behind a flag) None of that happened so far, only the mixed signal of "lead and we'll follow" and "you are too powerful, stop dominating us." in some issue tracker _after_ the code has been removed.