8 ms·

This is starting to feel like the IE6 situation. 1. Someone comes up with a cool feature. 2. Browser developer refuses to incorporate it since "No one uses i

This is starting to feel like the IE6 situation. 1. Someone comes up with a cool feature. 2. Browser developer refuses to incorporate it since "No one uses it!". Pushes developed in-house technology instead. 3. No one uses the feature as a result. "See no one wants it!" 4. Competitors start to implement the feature 5. ??? And no, pollyfill is again not the (right) solution.

chrischen 3y ago
It’s like QR codes too. First it was invented… but no phone platform supported it natively, then WeChat in China built a platform and ecosystem within phone platforms and bundled a QR code reader which made it take off in China, then something like 10 years later Apple adds QR scanning to the camera app and we get pervasive QR codes finally. Saying “nobody uses it” is a copout if you are a de-facto monopoly.
- vlovich123 3y ago
  That's not correct. Firstly, it had taken off in Japan a long time ago. Blackberry supported it in fact and I remember being at an intern recruiting event where the recruiter was smug about QR codes being on the cusp of mass adoption (being more than a decade early is wrong for this kind of stuff). The problem was that the UX sucked. The UX today still kind of sucks but it's infinitely better than what was available when QR codes were first around by being integrated into the camera app.
  - throw0101c 3y ago
    > That's not correct. Firstly, it had taken off in Japan a long time ago. It was in fact invented in Japan: * https://en.wikipedia.org/wiki/QR_code https://en.wikipedia.org/wiki/QR_code
- mlindner 3y ago
  Pretty sure China had no part in popularizing it and third party apps had support for it on iPhone a long time ago. I was seeing and using QR codes here in the US back in 2010 or so pretty commonly. They were limited to college campuses and SF bay area then but still were around plenty. I remember being frustrated that my non-smartphone flip-phone didn't support them (and no way to add support for them either).
  - tssva 3y ago
    Were college campuses and the SF bay area the only places you had exposure to in 2010? I wasn't near either around 2010 but saw a lot of QR codes.
  - chrischen 3y ago
    I lived in SF in the 2010s... QR code adoption was abysmal. I'm not saying China wis why we adopted QR codes, but because the QR code function was part of the main UX of their main platform (Wechat app), there was massive adoption of QR codes before the US started doing so in the late 2010s because our major platforms (Android, iOS) started integrating it into the core UX.
- ls612 3y ago
  I remember seeing QR codes in my high school in 2010 so idk how people were using them back then (I wasn’t allowed a smartphone as a teenager).
  - zone411 3y ago
    You could use an iPhone app. Here is an article from 2009 that mentions some https://www.cnet.com/tech/services-and-software/qr-code-readers-for-your-iphone/ https://www.cnet.com/tech/services-and-software/qr-code-read...
- bobthepanda 3y ago
  There was an NYT article about how restaurants are actually dropping QR code menus due to customers disliking them and spending less with QR menus. https://www.nytimes.com/2023/05/22/dining/restaurant-qr-code-menu.html https://www.nytimes.com/2023/05/22/dining/restaurant-qr-code...
  - Spooky23 3y ago
    The issue isn’t the QR, it’s the weird dynamic of a restaurant with a guy who shows you to a table, then you’re ordering from some stupid webpage. For the price of eliminating underpaid waitstaff, the customer has a weird, slow ordering experience that cannot accommodate undocumented needs. The customer response is: fuck you. Fast food is similar with order kiosks.
    - katbyte 3y ago
      > Fast food is similar with order kiosks i'd be ok with them if i could place my usual order (sub and add onions) but i can't so i always have to goto the counter
      - nightfly 3y ago
        It really depends on the place. Taco bell and burger king both handle changes really well in their app
vlovich123 3y ago
Devil's argument time. They add support and there's little adoption. Worse yet, it's a meaningful amount of adoption that deprecating is now it's own criticism cycle. So now Google is being forced to add support and maintain an image format because of evangelists? I think the problem here is that W3C is lagging on listing which image formats are standard and vendors are shipping their own in-house tech in the vaccuum (and that W3C is composed of browser vendors means Google, Apple, Microsoft, Mozila & whoever is there from the community can't agree).
- reaperducer 3y ago
  They add support and there's little adoption. Who cares if there's little adoption? Why not be feature complete? It's not like Google is some cash-strapped startup. Heck, macOS ships with terminal definitions so you can log into a Mac using a Commodore B-128 as a serial terminal. It didn't have to, and that's certainly going to have less adoption than JPEG XL. (/usr/share/terminfo/62/b-128, if you're curious.) https://en.m.wikipedia.org/wiki/Commodore_CBM-II https://en.m.wikipedia.org/wiki/Commodore_CBM-II
  - refulgentis 3y ago
    Then you fall on the sword of “google forces web standards!!” (See: WebP)
    - whywhywhywhy 3y ago
      Photoshop still can't open webp files, many websites still don't support uploading webp files. Do you not see how its annoying to drag a file out of Google image searches, see the extension is .jpg.webp then have to convert it back into jpeg to edit thus adding a 3rd layer of compression artifacts to the image.
      - arp242 3y ago
        > many websites still don't support uploading webp files. On GitHub if you rename your WebP file to "file.webp.png" it will upload just fine, and will use the correct Content-Type header when serving. It's really frustrating a simple \.(png|gif|jpe?g)$ check is preventing the uploading of these files. I found this is actually the case for a number of platforms.
captainmuon 3y ago
The 'right' solution would be to just use system codecs for everything. Many apps need good implementations of image codecs. They just need to be implemented once by the OS vendor (or the toolkit on Linux). Now somebody is going to say that's bad because it will fragment the ecosystem, and people will rely on something that works on one platform but not another. But you know what, that's not much different from something that works in one browser and not in another. Just file a bug against your OS. There are only finitely many image formats in the world. I'm sure Qt, .NET, Cocoa, ... have every format that you could conceivably need, and if not it should be easy to add them once.
- n2d4 3y ago
  > But you know what, that's not much different from something that works in one browser and not in another. The idea behind standardization is precisely to not let that happen.
  - account42 3y ago
    Right. We already made that mistake with fonts and still only have provided workarounds (esentially the same as polyfills) instead of just standardizing a reasonable base set. This would be even worse with image formats.
- dspillett 3y ago
  > The 'right' solution would be to just use system codecs for everything. That doesn't always work. VLC became as popular as it is partly through bundling its own selection of codecs for its own use, when getting certain things to play in some places was quite a faf. If doing it the right way is hassle to the end user, we'll often sidestep rather than campaigning for fixes where they should be made.
- deleted 3y ago
  [deleted]
- Avamander 3y ago
  > The 'right' solution would be to just use system codecs for everything. Many apps need good implementations of image codecs. They just need to be implemented once by the OS vendor (or the toolkit on Linux). Windows has done this and is still doing this, but the decade-long track history so far is that this does not work well. It can work, in a very limited scope and if you have a lot of influence. Sure, it's really nice if an 8K@60Hz HDR HEVC video plays perfectly straight in your browser or desktop app, but more often than not, it just won't. You don't have the right browser, the extension installed (due to license agreements), good enough graphics drivers or someone has forgotten a flag yet again. And we haven't even gotten to the immense amount of variation each codec introduces or the potential attack surface. How shit the situation is with just HEVC (and thus also basically HEIC): https://github.com/StaZhu/enable-chromium-hevc-hardware-decoding https://github.com/StaZhu/enable-chromium-hevc-hardware-deco... > Just file a bug against your OS. In the end that "just" carries a lot of burden, it can't be the users reporting these issues. It's just way easier to leech off of ffmpeg and similar, and let it deal with all the formats. Instead of hoping that maybe you can leverage what the OS gives you, that it works and works correctly in all your edge-cases. Though not everything is that gloomy, there are Vulkan extensions that might (in the future) simplify cross-platform image and video decoding (and HW acceleration).
jsnell 3y ago
That's a great narrative, except that in this case the "someone" in point 1 and the "browser developer" in point 2 are the same company, and the "competitors" from point 4 are not supporting the feature either.
- samtheprogram 3y ago
  Apple is adding support to macOS/iOS/Safari
- pikelet 3y ago
  According to the comments directly below the linked comment, Safari is actually adding support... https://twitter.com/jonsneyers/status/1665792517613256705 https://twitter.com/jonsneyers/status/1665792517613256705 https://www.webkit.org/blog/14203/web-technology-sessions-at-wwdc23/ https://www.webkit.org/blog/14203/web-technology-sessions-at... So, can we just get past this silly drama now and get JXL support back in Chromium?
  - jsnell 3y ago
    Ok, that's great news! Maybe let's wait for Apple to actually announce the details (which neither the cropped screenshot or the talk abstract have), and give the Chrome team some time to react and make a statement. Rather than have the 10th rehash of this on HN with an incendiary title.
    - lonjil 3y ago
      JXL and HEIC/HEIF support are in the changelog for Safari 17. If you download the iOS or iPadOS 17 beta, JXL will work in pretty much all apps. I agree on giving the Chrome people some space, the title here is ridiculous.
      - alwillis 3y ago
        > If you download the iOS or iPadOS 17 beta, JXL will work in pretty much all apps. I’m running iOS 17; JPEG XL doesn’t work in Chrome (or Brave). So there’s more going on. What will be interesting: if Google will enable JPEG XL support in the next update of Chrome on iOS…
Retr0id 3y ago
A polyfill (in the form of a wasm blob that implements the decoder) would be an interesting solution at least, since it would make the chrome experience noticeably worse than any competitor that has native support.
- dcow 3y ago
  Now all that's left is to generalize that and start a movement where we kill Chrome by making commonly used JS frameworks deliberately perform orders of magnitude worse on Chrome. (I understand I'm being absurd and that your suggestion is not actively malicious like mine is because Chrome is being stubborn in this case.)
  - WorldMaker 3y ago
    It worked for YouTube helping get Chrome adopted in the first place. (I kid, mostly.)
  - marcosdumay 3y ago
    > I understand I'm being absurd Huh? Up to that point I was expecting a joke about Chrome being the receiver of the exact same thing Google practices.
  - StrangeATractor 3y ago
    That's not so outrageous, Google gives you different search experiences based on your user agent.
  - bmacho 3y ago
    No, don't do that, but make google to support the best possible technologies at least.
  - devwastaken 3y ago
    You can't kill chrome because there is no alternate tech. Everything is chromium, or follows it (except safari).
    - 3y ago
naikrovek 3y ago
that is exactly what Google hope Chrome to become: the IE6 of the new era. everything they've done for the past few years points to this, including decisions like this one.
rsynnott 3y ago
Chrome _did_ actually support it at some point, though, didn't it?
- peppermint_gum 3y ago
  Hidden behind a disabled-by-default feature flag. WebP and AVIF had no experimental period.
boringuser2 3y ago
Only on HN will you get mental delinquents suggesting that Safari is one obscure image codec away from supplanting Chromium.

chrischen 3y ago

It’s like QR codes too. First it was invented… but no phone platform supported it natively, then WeChat in China built a platform and ecosystem within phone platforms and bundled a QR code reader which made it take off in China, then something like 10 years later Apple adds QR scanning to the camera app and we get pervasive QR codes finally. Saying “nobody uses it” is a copout if you are a de-facto monopoly.

vlovich123 3y ago
That's not correct. Firstly, it had taken off in Japan a long time ago. Blackberry supported it in fact and I remember being at an intern recruiting event where the recruiter was smug about QR codes being on the cusp of mass adoption (being more than a decade early is wrong for this kind of stuff). The problem was that the UX sucked. The UX today still kind of sucks but it's infinitely better than what was available when QR codes were first around by being integrated into the camera app.
- throw0101c 3y ago
  > That's not correct. Firstly, it had taken off in Japan a long time ago. It was in fact invented in Japan: * https://en.wikipedia.org/wiki/QR_code https://en.wikipedia.org/wiki/QR_code
mlindner 3y ago
Pretty sure China had no part in popularizing it and third party apps had support for it on iPhone a long time ago. I was seeing and using QR codes here in the US back in 2010 or so pretty commonly. They were limited to college campuses and SF bay area then but still were around plenty. I remember being frustrated that my non-smartphone flip-phone didn't support them (and no way to add support for them either).
- tssva 3y ago
  Were college campuses and the SF bay area the only places you had exposure to in 2010? I wasn't near either around 2010 but saw a lot of QR codes.
- chrischen 3y ago
  I lived in SF in the 2010s... QR code adoption was abysmal. I'm not saying China wis why we adopted QR codes, but because the QR code function was part of the main UX of their main platform (Wechat app), there was massive adoption of QR codes before the US started doing so in the late 2010s because our major platforms (Android, iOS) started integrating it into the core UX.
ls612 3y ago
I remember seeing QR codes in my high school in 2010 so idk how people were using them back then (I wasn’t allowed a smartphone as a teenager).
- zone411 3y ago
  You could use an iPhone app. Here is an article from 2009 that mentions some https://www.cnet.com/tech/services-and-software/qr-code-readers-for-your-iphone/ https://www.cnet.com/tech/services-and-software/qr-code-read...
bobthepanda 3y ago
There was an NYT article about how restaurants are actually dropping QR code menus due to customers disliking them and spending less with QR menus. https://www.nytimes.com/2023/05/22/dining/restaurant-qr-code-menu.html https://www.nytimes.com/2023/05/22/dining/restaurant-qr-code...
- Spooky23 3y ago
  The issue isn’t the QR, it’s the weird dynamic of a restaurant with a guy who shows you to a table, then you’re ordering from some stupid webpage. For the price of eliminating underpaid waitstaff, the customer has a weird, slow ordering experience that cannot accommodate undocumented needs. The customer response is: fuck you. Fast food is similar with order kiosks.
  - katbyte 3y ago
    > Fast food is similar with order kiosks i'd be ok with them if i could place my usual order (sub and add onions) but i can't so i always have to goto the counter
    - nightfly 3y ago
      It really depends on the place. Taco bell and burger king both handle changes really well in their app

vlovich123 3y ago

Devil's argument time. They add support and there's little adoption. Worse yet, it's a meaningful amount of adoption that deprecating is now it's own criticism cycle. So now Google is being forced to add support and maintain an image format because of evangelists? I think the problem here is that W3C is lagging on listing which image formats are standard and vendors are shipping their own in-house tech in the vaccuum (and that W3C is composed of browser vendors means Google, Apple, Microsoft, Mozila & whoever is there from the community can't agree).

reaperducer 3y ago
They add support and there's little adoption. Who cares if there's little adoption? Why not be feature complete? It's not like Google is some cash-strapped startup. Heck, macOS ships with terminal definitions so you can log into a Mac using a Commodore B-128 as a serial terminal. It didn't have to, and that's certainly going to have less adoption than JPEG XL. (/usr/share/terminfo/62/b-128, if you're curious.) https://en.m.wikipedia.org/wiki/Commodore_CBM-II https://en.m.wikipedia.org/wiki/Commodore_CBM-II
- refulgentis 3y ago
  Then you fall on the sword of “google forces web standards!!” (See: WebP)
  - whywhywhywhy 3y ago
    Photoshop still can't open webp files, many websites still don't support uploading webp files. Do you not see how its annoying to drag a file out of Google image searches, see the extension is .jpg.webp then have to convert it back into jpeg to edit thus adding a 3rd layer of compression artifacts to the image.
    - arp242 3y ago
      > many websites still don't support uploading webp files. On GitHub if you rename your WebP file to "file.webp.png" it will upload just fine, and will use the correct Content-Type header when serving. It's really frustrating a simple \.(png|gif|jpe?g)$ check is preventing the uploading of these files. I found this is actually the case for a number of platforms.

captainmuon 3y ago

The 'right' solution would be to just use system codecs for everything. Many apps need good implementations of image codecs. They just need to be implemented once by the OS vendor (or the toolkit on Linux). Now somebody is going to say that's bad because it will fragment the ecosystem, and people will rely on something that works on one platform but not another. But you know what, that's not much different from something that works in one browser and not in another. Just file a bug against your OS. There are only finitely many image formats in the world. I'm sure Qt, .NET, Cocoa, ... have every format that you could conceivably need, and if not it should be easy to add them once.

n2d4 3y ago
> But you know what, that's not much different from something that works in one browser and not in another. The idea behind standardization is precisely to not let that happen.
- account42 3y ago
  Right. We already made that mistake with fonts and still only have provided workarounds (esentially the same as polyfills) instead of just standardizing a reasonable base set. This would be even worse with image formats.
dspillett 3y ago
> The 'right' solution would be to just use system codecs for everything. That doesn't always work. VLC became as popular as it is partly through bundling its own selection of codecs for its own use, when getting certain things to play in some places was quite a faf. If doing it the right way is hassle to the end user, we'll often sidestep rather than campaigning for fixes where they should be made.
deleted 3y ago
[deleted]
Avamander 3y ago
> The 'right' solution would be to just use system codecs for everything. Many apps need good implementations of image codecs. They just need to be implemented once by the OS vendor (or the toolkit on Linux). Windows has done this and is still doing this, but the decade-long track history so far is that this does not work well. It can work, in a very limited scope and if you have a lot of influence. Sure, it's really nice if an 8K@60Hz HDR HEVC video plays perfectly straight in your browser or desktop app, but more often than not, it just won't. You don't have the right browser, the extension installed (due to license agreements), good enough graphics drivers or someone has forgotten a flag yet again. And we haven't even gotten to the immense amount of variation each codec introduces or the potential attack surface. How shit the situation is with just HEVC (and thus also basically HEIC): https://github.com/StaZhu/enable-chromium-hevc-hardware-decoding https://github.com/StaZhu/enable-chromium-hevc-hardware-deco... > Just file a bug against your OS. In the end that "just" carries a lot of burden, it can't be the users reporting these issues. It's just way easier to leech off of ffmpeg and similar, and let it deal with all the formats. Instead of hoping that maybe you can leverage what the OS gives you, that it works and works correctly in all your edge-cases. Though not everything is that gloomy, there are Vulkan extensions that might (in the future) simplify cross-platform image and video decoding (and HW acceleration).

jsnell 3y ago

That's a great narrative, except that in this case the "someone" in point 1 and the "browser developer" in point 2 are the same company, and the "competitors" from point 4 are not supporting the feature either.

samtheprogram 3y ago
Apple is adding support to macOS/iOS/Safari
pikelet 3y ago
According to the comments directly below the linked comment, Safari is actually adding support... https://twitter.com/jonsneyers/status/1665792517613256705 https://twitter.com/jonsneyers/status/1665792517613256705 https://www.webkit.org/blog/14203/web-technology-sessions-at-wwdc23/ https://www.webkit.org/blog/14203/web-technology-sessions-at... So, can we just get past this silly drama now and get JXL support back in Chromium?
- jsnell 3y ago
  Ok, that's great news! Maybe let's wait for Apple to actually announce the details (which neither the cropped screenshot or the talk abstract have), and give the Chrome team some time to react and make a statement. Rather than have the 10th rehash of this on HN with an incendiary title.
  - lonjil 3y ago
    JXL and HEIC/HEIF support are in the changelog for Safari 17. If you download the iOS or iPadOS 17 beta, JXL will work in pretty much all apps. I agree on giving the Chrome people some space, the title here is ridiculous.
    - alwillis 3y ago
      > If you download the iOS or iPadOS 17 beta, JXL will work in pretty much all apps. I’m running iOS 17; JPEG XL doesn’t work in Chrome (or Brave). So there’s more going on. What will be interesting: if Google will enable JPEG XL support in the next update of Chrome on iOS…

Retr0id 3y ago

A polyfill (in the form of a wasm blob that implements the decoder) would be an interesting solution at least, since it would make the chrome experience noticeably worse than any competitor that has native support.

dcow 3y ago
Now all that's left is to generalize that and start a movement where we kill Chrome by making commonly used JS frameworks deliberately perform orders of magnitude worse on Chrome. (I understand I'm being absurd and that your suggestion is not actively malicious like mine is because Chrome is being stubborn in this case.)
- WorldMaker 3y ago
  It worked for YouTube helping get Chrome adopted in the first place. (I kid, mostly.)
- marcosdumay 3y ago
  > I understand I'm being absurd Huh? Up to that point I was expecting a joke about Chrome being the receiver of the exact same thing Google practices.
- StrangeATractor 3y ago
  That's not so outrageous, Google gives you different search experiences based on your user agent.
- bmacho 3y ago
  No, don't do that, but make google to support the best possible technologies at least.
- devwastaken 3y ago
  You can't kill chrome because there is no alternate tech. Everything is chromium, or follows it (except safari).
  - 3y ago

naikrovek 3y ago

that is exactly what Google hope Chrome to become: the IE6 of the new era. everything they've done for the past few years points to this, including decisions like this one.

rsynnott 3y ago

Chrome _did_ actually support it at some point, though, didn't it?

peppermint_gum 3y ago
Hidden behind a disabled-by-default feature flag. WebP and AVIF had no experimental period.

boringuser2 3y ago

Only on HN will you get mental delinquents suggesting that Safari is one obscure image codec away from supplanting Chromium.