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).
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. That's certainly going to have less adoption than JPEG XL.
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.
Why is Adobe so bad at their job? GIMP added webp support about 5 years ago. Paint.NET added it 4 years ago.
> many websites still don't support uploading webp files.
4chan is the only such site I've heard of, and 4chan is notoriously bad at this sort of thing ever since they lost moot. It took them years to permit uploading of vp9/opus webms, for no good reason. 4chan's present administrators are incompetent, but 4chan is barely profitable (if at all) so that's not really unexpected.
But Adobe rakes in huge piles of cash, so what is Adobe's excuse?
Did they finally do that? I left permanently a couple years ago (after being there regularly since 2006) because the small "these kinds of threads are why I still hang around this place" threads got more and more infrequent and the regular users got more and more annoying and less fun. Most of the site just became a constant pool of angry racism, cynicism, and paranoia. I can handle seeing stupid racism, but the death of fun and the constant angry sarcasm just got old.
Anyway, I was constantly annoyed that I couldn't upload vp9 webms, and that apng was also not supported given how much better than gif it was. Webp would have been decent, too.
Because this code will be exposed on every single webpage you load, and historically these kind of parsers have had a number of security problems.
Something something memory safety, but this is the situation that currently exists.
"All the image parsers" would be a very bad idea. Years ago there was a bug in some Linux setups where all gstreamer codecs were exposed in Firefox, and it was a huge problem (similar: https://lwn.net/Articles/708196/ – although the one I remember is much older, around 2010 or so).
It's not really comparable to all the old terminfo entries from decades ago: the vendor controls those terminfo entries, not $random_websites. Maybe the ncurses terminfo parser actually does have some buffer overflow (there's an entire mini-programming language in there), but if it does it's not really a huge acute problem.
By that logic, Chrome shouldn't ever add any new features. WebP is also an additional attack surface.
This is one of those things that sound nice, but there's a lot of practical caveats, and in reality it would all be pretty complex. Who would provide the "trusted certs"? How do you decide between a "good and safe plugin" and "not so good and unsafe plugin"? How do you update these decoders? etc.
That world existed, in the 90s and early 2000s, and it was called "ActiveX". The codebase= attribute of the <object> element exists for that use case. It sucked, for two major reasons: first of all, it was a reliable way to get malware into user's machines (being "signed with a trusted cert" doesn't help when all you need for a trusted cert is money and/or hacking a trusted software publisher). Second, it was very Windows-specific, and a significant obstacle to the adoption of alternative operating systems, hardware architectures, and browsers.
If that's the case (and if the implementation is sufficient, rather than a leaky prototype) it would seem that the burden is quite low.
Behaving like there's no cost in such maintenance is just whack.
Compile it to wasm and run it in a sandbox? Or throw some rust groupies at it?
> Once released, it's pretty much impossible to rollback support for media formats on the web.
We must live in a time where flash still dominates short web animations, streaming providers use silver light and every enterprise user is stuck waiting for the companies 5GB Java applet to load right when IE6 suddenly pops up to kill everything with an ActiveX based Windows update that adds more video codecs instead of removing them from the system. The list goes on forever. Browsers are not above killing features and breaking things for security reasons or if they just feel like it.
Also webp is 13 years old now or something since the initial release as compared with jpegxl which is quite new.
If after a decade no one really uses it, fine remove it - no one will care if it’s unused. But to kill it in its cradle is just BS. JPEGXL should have the same opportunities WebP had.
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.
It was in fact invented in Japan:
I remember being frustrated that my non-smartphone flip-phone didn't support them (and no way to add support for them either).
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.
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
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.
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.
The idea behind standardization is precisely to not let that happen.
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-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).
https://twitter.com/jonsneyers/status/1665792517613256705 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?
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.
I agree on giving the Chrome people some space, the title here is ridiculous.
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…
Huh? Up to that point I was expecting a joke about Chrome being the receiver of the exact same thing Google practices.
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.