...another facet of the web that Google itself controls...
No need to go any further. This explains the behaviour very nicely.
Apple is now supporting JPEG XL – a novel royalty-free image codec that Google last year controversially abandoned – in its Safari browser. The Safari 17 Beta Release Notes reveal that support for JPEG XL has been added, bringing with it various purported advantages over other image compression and decompression technologies …
Congrats on ignoring that the majority of browsers available today are variations of the Chromium core: Brave, Vivaldi, Opera, Edge, Samsung Internet
I already do. That doesn't change the fact that Chrome alone is still more than 60% of the whole browser market. If you sum up those variations above, it easily passes 70%. If Google says "We won't support X", you can bet only a very tiny minority of sites will bother showing X in any form.
It's not about the browser you use, it's about Google abusing its power
"Use another browser" is also a damn excuse for ignoring what a user may do *after* downloading that image on said browser.
That is, most operating systems don't have JPEG XL handling built-in at this point. So if you receive / download that XL image, you won't be able to view it in an OS-native / included image viewer, and therefore nor will you be able to print it out. JPEG XL right now is pretty much an "internet-only" format, and that is inexcusable at this time.
Get XL support included in the most-used modern OS packages (Ubuntu, Debian et al, Windows 10, Windows 11, MacOS) and THEN talk to me about rolling it out as a reasonable sharing standard on the web.
That is, most operating systems don't have JPEG XL handling built-in at this point. So if you receive / download that XL image, you won't be able to view it in an OS-native / included image viewer, and therefore nor will you be able to print it out.
Right click on image in browser, select 'Print'?
> but damn that's awkward
Right click->Open With
> and most people certainly wouldn't think of it.
Only those who lack decades worth of basic computer skills in regards to opening a file in another program or even changing the default program to open a file.
I doubt such people will even know how to change a font in a wordprocessor, so by your logic averything should be in Roboto?
I wonder why that is so. Then again, on all my personal devices running Firefox I also have installed NoScript, Facebook Firewall, Privacy Badger, uBlock Origin and one or two other nice add-ons.
I personally can't see how anyone is willing to browse the dumpster fire that is the internet without NoScript. You poor, poor suckers still dealing with popups, pop-unders and ads - ugh!
You must be too young to remember the Microsoft Internet Explorer fiasco. It didn't matter what browser you used, websites were designed to be bug-compatible with IE.
More conforming browsers were accused of being broken if a site "optimised" for IE didn't render properly.
And ill thoughtout IE html extensions became defacto-standards. It started with Netscape, but Microsoft took it to the next level.
It wasn't about an open web, it was about everyone using your product, because they couldn't reliably use any alternative.
So the alternatives had no choice but become bug-compatible, and support all the stupid extensions.
Microsoft basically had control over HTML and the web. Sound familiar?
-- Sound familiar? --
Sure do, especially when I think of email. In a business application I wrote (recruitment) I wanted email as a part of it. Studied the RFCs and produced what I thought was a pretty good subsystem. Then all the non-standard crap that Outlook Express allowed started to hit it and it ended up with more woops handling than nice clean code.
For most users (i.e. NOT the people who read/comment here) the Internet today is GOOGLE.
Their homepage is GOOGLE.
They search for all sites using GOOGLE rather than bookmark them.
The above is why all google owned IP's are blocked at my firewall. If I absolutely have to use their POS services then I fire up a VM that has a VPN configured that make it appear to the slurpers in chief that I am in the USA when I am not. The VM is overwritten with a clean copy after use. Any Chrome based browser is also banned on my network.
I could not get the linked page to load in Firefox, it worked fine in Chrome but did not include a lot of detail.
Unsurprisingly the Register's reporting was much better:
And more meta discussion:
> ...a decision that denied the codec to Chrome and to other downstream browsers like Microsoft Edge
Apart from the fact that the entire reason that these downstream browsers exist is to put in functionality that isn't in the Chromium project itself. If Microsoft want to support it in Edge there is literally nothing stopping them from putting the same code back in. Same goes for any other derivative.
Google is no different to MS of the 90s.
There is one difference.
MS of the 90s monopolised the computer market, a then nascent market that 80-90% of the world was blissfully unaware of.
Google monopolises the internet, which (until it finally fractures into geopolitical blocs) a good chunk of the world uses.
Yes, but Apple refused to support it for years. Even now it won't work on many Apple system like mine. JPEG-XL doesn't offer enough over WebP for websites to consider wholesale adoption.
At some point Webp will no doubt be replaced by AVIF, though I expect this to happen transparently, ie. WebP could become a container format.
Thank you (and others above) for your reply, learned something new. That comparison is very thorough and well argued indeed, thanks.
I also noted with some surprise that my editing software (Affinity Designer and Affinity Photo) turn out to already support JPEG XL, so it's now more a matter of keeping an eye out for which browsers support it. Otherwise I'll have to stay with webp for the large pretty things :).
Dunno, that site only compares compression at low quality, i have found contrary to that article that i can compress webp to a much gretear extent than jpg for fullscreen images, for example i can get a fullhd image down to around 70-100kb with webp and it has the same visual fidelity as a jpeg at 200-400kb.
But what's the source image?
Whether we like it or not, the majority of photos are spat out of phones and cameras as standard JPEG.
Further lossy compression is always going to create unacceptable degradation. The idea JPEG XL can losslessly compress a standard JPEG further, saving diskspace and bandwidth, but also can reverse the process to serve JPEG XL naïve clients with standard JPEGs is something so useful that it basically renders any other reasons as being firmly secondary.
Phones will use whatever format the manufacturer favours. Apple is already nudging users towards HEIC and Android supports WebP. Hardware-compression: h264, h265 and AV1 are key as video trumps photos on phones. Google will presumably have data on AV1 use from YouTube.
As for websites: compression ratios are still key. Most people are looking at images on small, probably smeared screens in bad light with not necessarily great connection speeds, so quality and fidelity are not that important. It's like trying to put a high fidelity audio system in a car: an expensive waste of time.
... Is truly worth investigating.
Not to mention their (and many other companies) insistence on rushing to copy whatever Apple does. Apple gives the middle finger to a file format? QUICK, LET'S DROP OUR SUPPORT, TOO! They're adding a new codec? QUICK, WE MUST DO THAT, TOO!! Ditching physical keyboards? OHMYGOD DESTROY THOSE, WE'RE NEVER USING PHYSICAL KEYBOARDS EVER AGAIN!!
I think it isn't "let's blindly copy what Apple does" it is "well Apple did this and other than some whining from neckbeards most people didn't take any issue with it, so maybe we shouldn't worry about the reaction if we decide to do it too".
Ditching physical keyboards was an unalloyed good. If the number of people who wished they were still around was more than a rounding error, there would be Android phones out there with a physical keyboard, just like you can still find a few with a removable battery, memory card slot, 3.5mm jack and other things that a certain vocal minority keep harping on about to this day.
Nobody wanted to lose an SD card slot, 3.5mm jack or removable battery. Keyboard, yes, that's very niche, but there would be buyers if there were offerings.
Many decisions have been taken in the pursuit of getting you to buy extra crap (new phone because your battery died, wireless headphones because you can't plug yours in any more, more storage at a higher cost upfront because you can't expand). Don't confuse those decisions with ones people actually want.
For the record my phone has a removable battery, 3.5mm jack and microSD slot (dedicated, can still run dual SIM alongside).. but that's not an easy combo to get these days.
My phone has an unused SD slot in the SIM tray. That's likely to stick around as long as SIMs are around. I'd like a removable battery but only really because I need to replace mine after four years, otherwise a power bank makes more sense. 3.5 jacks have always been a nightmare on phones because of the leverage they can exert, their tendency to snag, and the difficulty in making them waterproof. I've been using Bluetooth headphones for 15 years and have never looked back.
SIMs are already on their way out, and the poster I replied to above will be able to blame Apple for that as they are the first major phone OEM to drop SIM slots entirely (at least in the US with the current iPhone, and I'm sure they'll do it worldwide soon enough)
Having eSIMs is so much better. Two can be active at once but they can hold a bunch of inactive profiles which I suppose would be nice for some. I found it handy when I considered switching carriers last winter, since I could just load an eSIM profile I got as a free trial from a carrier and activate that on the second eSIM. The display changes to show bars for both connections simultaneously so I could check my phone in various places I frequent to make sure there was good coverage before I made the switch.
eSIMs haven't been trouble free, when I converted my AT&T account from SIM to eSIM last summer (because I knew I'd be getting the new iPhone and it wouldn't have a SIM slot) the seamless process that Apple supports didn't work and I ended up having to go to an AT&T store to get it working. And I had to do a little chat with a CSR when I ported my number from the AT&T eSIM to the Verizon eSIM but at least I didn't have to visit the Verizon store. So you can think of it that I'm taking the annoyance hits so the process is smooth when the Android world goes all-in on eSIM in a couple years or whatever.
The only people I've heard say that are those afraid of change. Not having a fiddly bit of hardware that has to be physically delivered to you and can easily become lost or broken if you are SIM swapping regularly is terrible technology. The reason eSIMs took so long to replace them is because CARRIERS didn't want to give up the control SIMs give them.
I don't see how eSIMs give e.g. Apple or any other smartphone OEM the slightest bit of power they didn't have with physical SIMs. The "power" they did have was limiting the number of physical SIM slots - which for the overwhelming majority of phones was exactly "1". If you wanted/needed two active at once your choice of phones was greatly reduced. With eSIM it is easy to provide two active profiles, even though 99% of your customers will never use that capability. There is no "gatekeeping" going on, they can't prevent you from using a certain carrier, other than the usual restrictions around "carrier locking" which exist with physical SIMs too.
I don't recall ever seeing the major carriers having a "demo" period available with SIM cards (this was in the US, if you live elsewhere maybe the story was different - some US MVNOs were willing to do this though) but they are the norm now with eSIM because it costs them nothing. It was something most people would not consider because they would have to remove the one SIM their phone could hold and replace it, making them unavailable on their 'real' number. If you were willing to put up with that you still had to wait a few days for the SIM to arrive or find somewhere you could go to get one - and you'd have to pay for it. Maybe it was only a buck or two but that's still not a "free" demo.
With a physical SIM, buy a new phone, take SIM out of old phone, plug into new, job done in about thirty seconds. No faffing around trying to get an eSIM transferred; no need to spend time in a telephone queue to the mobile provider, find the IMEI, prove my identity.
It's a bit less of an advantage when switching carriers on the same phone but with SIMs stacked up next to the TicTacs at every supermarket checkout, not much.
The multi-SIM thing is the only real advantage methinks, and then only if you don't have a phone with multiple slots. They are reasonably common in the UK and Europe and I am told almost ubiquitous in Asia and other markets.
Apple has automated transfer of eSIM from your old phone to your new phone. It didn't work when I tried it with new iPhone last fall, I ended up having to go to AT&T, but many people reported it did work for them. As carriers get things straightened on out on their end and Apple & Google programmers add a few more if/then checks for various corner cases the process might have been missing when I tried it pretty soon your eSIM profile(s) will be copied to your new phone along with all the rest of your stuff and you won't even have to think about it.
I wouldn't be surprised if when SIM cards were brand new the process of transferring them to a different phone was not trouble free at first either...
The key word in your argument is Apple: you're dependent on them to be able to switch providers. The SIM card was mandated in the EU precisely to avoid that kind of lock-in and using them in different phones was never ever a problem.
The key word in your argument is Apple: you're dependent on them to be able to switch providers
What the fuck are you on? How are they going to stop me from changing providers? Sure, they could theoretically do that via software, but they could ALSO stop you from switching hardware SIMs by refusing to operate if a new SIM card is inserted.
You're really stretching things to the breaking point with your reflexive "Apple is Satan!" stupidity. I'm sure you will change your tune about eSIMs when your favorite Android OEMs all drop support for hardware SIMs in a few years. Then suddenly it will be great, but you'll say "Apple's attempts to stop their users from switching providers were prevented by all the wonderful white knight Android vendors who provided alternatives that didn't do that causing Apple to scuttle those plans".
Honestly, what would Apple get from blocking me from switching from AT&T to Verizon, or someone else from switching from Verizon to AT&T? Your reflexive Apple hatred has dropped your IQ to room temperature. Centigrade room temperature.
pretty soon your eSIM profile(s) will be copied to your new phone along with all the rest of your stuff and you won't even have to think about it.
But still needs to involve a third party, or will Apple use some variant of AirDrop? Look, I know I'm a bit old-fashioned, but when I buy a new phone (erm, two in nine years), I take the opportunity to have a bit of a clear-out. I do not have Google or Apple accounts with full back-ups of my phone and I do not need to upload/download oodles of data to get the new one working. The closest I come to that is with the Signal database backup, and that stays local. Contacts get saved to a .vcf which comes over in a couple of seconds via Bluetooth.
I wouldn't be surprised if when SIM cards were brand new the process of transferring them to a different phone was not trouble free at first either...
I've never had a problem transferring a SIM card between my phones, or those of relatives, except once when the new phone took a smaller size and I had to get a SIM-punch tool. Worked a treat. The main thing to look out for is vendor-locked phones, but that would be an issue with an eSIM too, methinks.
But still needs to involve a third party, or will Apple use some variant of AirDrop?
When you get a new iPhone it sets up a direct wifi link with the old one and copies everything over. If you want to set up your new phone from scratch and not copy anything over you can still use what they call "eSIM quick transfer" that will let you copy just the eSIM.
Carriers also support loading eSIMs their own way, most use a QR code for this purpose that you can read with your camera and it will recognize as an eSIM and ask if you want to install it.
There's also a manual option where you enter individual details you get from the carrier - this is sort of the fallback if nothing works and you have to call the carrier or visit the store. They obviously don't have any incentive to add friction to the process of getting people to use their service anymore than Apple wants things to not "just work" so no doubt this will become less and less common as carriers iron out their issues so they don't have to pay CSRs to walk people through the manual process.
Personally I always found an SD a bit of a faf, if I was transferring between phones I'd use bluetooth and to a computer I'd invariably have forgotten the little adaptor thingy.
To be fair though I do end up paying for the next storage tier because of lack of expansion, but I expect this is what most people use the cloud for. (I don't; I'm old and like local storage).
It's also worth pointing out that the storage in most phones these days is much higher bandwidth than offered by a cheap SSD, they're more akin the PCI-E attached NVMe storage you'd find in a laptop/desktop.
The 3.5mm jack was just the way you attached headphones to a 'thing' for years for me, they were okay, used to fluff up a lot (more on old walkmans than phones). When they got removed my first phone came with an adaptor, which is still attached to the end of my wired headphones; these days though bluetooth sounds fine to my ageing ears and you can get 20 quid bluetooth headphones that sound fine and last a good length of time between charges, and not having that wire that snags or pulls things out of pockets is very handy.
I get there are people that still miss these things, I'm just raising a voice for the 'actually, not that bothered in the end' crowd. :)
Hmm... the documentation showed Chrome did support it (at some point) under version 91 onwards.
I've just checked my version 114.0.5735.110 (Official Build) (64-bit) and that flag is missing.
That's a shame as you'd expect all browsers to support all image formats - otherwise there's no point having that content on your website.
I understand that Google doesn't want the burden of supporting more image formats. How about this compromise: add JPEG XL support, and drop WebP support. It's useless anyway.
Otherwise, I do hope that Firefox will officially support JXL soon, and maybe Edge too (they don't support AVIF still!). Then we can put JXLs on all our websites and just need a nice little JS polyfill so the Chrome users can see them too. If they start complaining that Chrome is "slow", even better.
I'm already seeing places using .webp so it is too late to abandon it. We are doomed to end up with more and more standards since the old ones never die. There are still plenty of .gif out there and probably still will 20 years from now - heck the incentive to "fix" that and use a more efficient format will be far less then since everyone will probably have symmetric 10 gigabit links and a half terabyte of RAM on their phone (or whatever fills the purpose of today's smartphone) so who cares if you save a few hundred KB converting that .gif to something more efficient?