7 ms·

It's so frustrating how the chromium team is ending up as a gatekeeper of the Internet by pick and choosing what gets developed or not. I recently come across

It's so frustrating how the chromium team is ending up as a gatekeeper of the Internet by pick and choosing what gets developed or not. I recently come across another issue pertaining to the chromium team not budging on their decisions, despite pressure from the community and an RFC backing it up - in my case custom headers in WebSocket handshakes, that are supported by other Javascript runtimes like node and bun, but the chromium maintainer just disagrees with it - https://github.com/whatwg/websockets/issues/16#issuecomment-1961031987 https://github.com/whatwg/websockets/issues/16#issuecomment-...

hwbunny 3y ago
Question is for how long. Time to slam the hammer on them.
- hhh 3y ago
  Why not make a better product than slam some metaphorical hammer?
  - mort96 3y ago
    That's not how this works. Firefox is the closest we have, and realistically the closest we will get to a "better product" than Chromium for the foreseeable future, and it's clearly not enough.
    - KingOfCoders 3y ago
      And Firefox does not support the format. Mozilla is the same political company as everyone else.
    - bombcar 3y ago
      The only hammer at all left is Safari, basically on iPhones only. That hammer is very close to going away; if the EU does force Apple to really open the browsers on the iPhone, everything will be Chrome as far as the eye can see in short order. And then we fully enter the chromE6 phase.
  - Certhas 3y ago
    Because "better" products don't magically win.
- caskstrength 3y ago
  What hammer? You want US president or supreme court to compel Chrome developers to implement every image format in existence and every JS API proposed by anyone anywhere? Unless it is some kind of anti-competitive behavior like they intentionally stiffening adoption of standard competing with their proprietary patent-encumbered implementation that they expect to collect royalties for (doesn't seem to be the case), then I don't see the problem.
madeofpalk 3y ago
Where's Firefox's and Webkit's position on the proposal?
- jonsneyers 3y ago
  Safari/Webkit has added JPEG XL support already. Firefox is "neutral", which I understand as meaning they'll do whatever Chrome does. All the code has been written, patches to add JPEG XL support to Firefox and Chromium are available and some of the forks (Waterfox, Pale Moon, Thorium, Cromite) do have JPEG XL support.
  - lonjil 3y ago
    I believe they were referring to that WebSocket issue, not JXL.
pgeorgi 3y ago
> It's so frustrating how the chromium team is ending up as a gatekeeper of the Internet by pick and choosing what gets developed or not. https://github.com/niutech/jxl.js https://github.com/niutech/jxl.js is based on Chromium tech (Squoosh from GoogleChromeLabs) and provides an opportunity to use JXL with no practical way for Chromium folks to intervene. Even if that's a suboptimal solution, JXL's benefits supposedly should outweight the cost of integrating that, and yet I haven't seen actual JXL users running to that in droves. So JXL might not be a good support for your theory: where people could do they still don't. Maybe the format isn't actually that important, it's just a popular meme to rehash.
- mardifoufs 3y ago
  Why do you assume that the benefits would outweigh said costs? That's a weird burden to set on the format. Using JavaScript on the browser to decode it is a huge hurdle, I don't know of any format that ever got popular or got its initial usage from a similar approach. Avif was just added too, even if no one was using a js library to decode it beforehand Fwiw I agree that there's a weird narrative around jpegxl, at the end of the day it's just a format, and I think it's not very good for lower quality images as proven by the linked article in the OP. Avif looks better in that regard. I think it would've made more sense than WebP though (which also doesn't look good at all when not lossless), but that was like a decade ago and that ship has sailed. So avif fills a niche that WebP sucks at, while jpegxl doesn't really do that. That alone is reason enough to not bother with including it.
  - JyrkiAlakuijala 3y ago
    People don't use blurry low quality images in the web. These low qualities don't matter outside of compression research. Average/median quality of images is between 85 to 90 depending how you calculate it. There, users' waiting time is worth during image formats life time for about 3 trillion USD. If we can reduce 20 % of it we create wealth of 600 billion USD distributed to the users. More savings come from data transfer costs.
    - 3y ago

hwbunny 3y ago

Question is for how long. Time to slam the hammer on them.

hhh 3y ago
Why not make a better product than slam some metaphorical hammer?
- mort96 3y ago
  That's not how this works. Firefox is the closest we have, and realistically the closest we will get to a "better product" than Chromium for the foreseeable future, and it's clearly not enough.
  - KingOfCoders 3y ago
    And Firefox does not support the format. Mozilla is the same political company as everyone else.
  - bombcar 3y ago
    The only hammer at all left is Safari, basically on iPhones only. That hammer is very close to going away; if the EU does force Apple to really open the browsers on the iPhone, everything will be Chrome as far as the eye can see in short order. And then we fully enter the chromE6 phase.
- Certhas 3y ago
  Because "better" products don't magically win.
caskstrength 3y ago
What hammer? You want US president or supreme court to compel Chrome developers to implement every image format in existence and every JS API proposed by anyone anywhere? Unless it is some kind of anti-competitive behavior like they intentionally stiffening adoption of standard competing with their proprietary patent-encumbered implementation that they expect to collect royalties for (doesn't seem to be the case), then I don't see the problem.

madeofpalk 3y ago

Where's Firefox's and Webkit's position on the proposal?

jonsneyers 3y ago
Safari/Webkit has added JPEG XL support already. Firefox is "neutral", which I understand as meaning they'll do whatever Chrome does. All the code has been written, patches to add JPEG XL support to Firefox and Chromium are available and some of the forks (Waterfox, Pale Moon, Thorium, Cromite) do have JPEG XL support.
- lonjil 3y ago
  I believe they were referring to that WebSocket issue, not JXL.

pgeorgi 3y ago

> It's so frustrating how the chromium team is ending up as a gatekeeper of the Internet by pick and choosing what gets developed or not. https://github.com/niutech/jxl.js https://github.com/niutech/jxl.js is based on Chromium tech (Squoosh from GoogleChromeLabs) and provides an opportunity to use JXL with no practical way for Chromium folks to intervene. Even if that's a suboptimal solution, JXL's benefits supposedly should outweight the cost of integrating that, and yet I haven't seen actual JXL users running to that in droves. So JXL might not be a good support for your theory: where people could do they still don't. Maybe the format isn't actually that important, it's just a popular meme to rehash.

mardifoufs 3y ago
Why do you assume that the benefits would outweigh said costs? That's a weird burden to set on the format. Using JavaScript on the browser to decode it is a huge hurdle, I don't know of any format that ever got popular or got its initial usage from a similar approach. Avif was just added too, even if no one was using a js library to decode it beforehand Fwiw I agree that there's a weird narrative around jpegxl, at the end of the day it's just a format, and I think it's not very good for lower quality images as proven by the linked article in the OP. Avif looks better in that regard. I think it would've made more sense than WebP though (which also doesn't look good at all when not lossless), but that was like a decade ago and that ship has sailed. So avif fills a niche that WebP sucks at, while jpegxl doesn't really do that. That alone is reason enough to not bother with including it.
- JyrkiAlakuijala 3y ago
  People don't use blurry low quality images in the web. These low qualities don't matter outside of compression research. Average/median quality of images is between 85 to 90 depending how you calculate it. There, users' waiting time is worth during image formats life time for about 3 trillion USD. If we can reduce 20 % of it we create wealth of 600 billion USD distributed to the users. More savings come from data transfer costs.
  - 3y ago