3 ms·
So, what you are saying is that JPEG-XL is superior, as long as your use case is insensitive to whether the majority of web users can view your content?
by dragonwriter 1y ago
So, what you are saying is that JPEG-XL is superior, as long as your use case is insensitive to whether the majority of web users can view your content?
- Spivak 1y agoI mean if you define superior not in terms of its technical merits but because of its blessed status by Google. It's not a terrible format but it is very much "what is the worst quality we can reasonably get away with to save on bandwidth." Such a thing does have its uses. At some point you have to be pragmatic and meet users where they are but doesn't mean you have to like that Google did throw their weight around in a way that only they really can.
- dragonwriter 1y ago> I mean if you define superior not in terms of its technical merits “Technical merits” are rarely, for anything, the sole measurement of fitness for purposes. Even for purely internal uses, internal social, cultural, and non-technical business constraints often have a real impact on what is the best choice, and when you get out into wider uses with external uses, the non-technical factors proliferate. That's just reality. I understand the aesthetic preference to have decisions only require considering a narrow set of technical criteria which you think should be important, but you will make suboptimal decisions in the vast majority of real-world circumstances if you pretend that the actual decision before you conforms to that aesthetic ideal.
- Zardoz84 1y agojust fuking use a poly fill to add support of JPEG XL. Or store JPEG XL and convert on the fly to JPEG to supply it to browsers that don't support JPEG XL.
- throw_m239339 1y ago> just fuking use a poly fill to add support of JPEG XL. Or store JPEG XL and convert on the fly to JPEG to supply it to browsers that don't support JPEG XL. Doesn't a polyfill imply more Javascript running on the device?
- BugsJustFindMe 1y agoOnly until the browser gets updated and then the polyfill stops being invoked automatically. It's self-healing.
- Zardoz84 1y agoTt's a WASM . And really isn't very big. So if you need to store and serve many images files, potentially big images like in an preservation & diffusion software (like the stuff that I'm working), I felt that I could afford to pay the extra few KiBs on that WASM.
- MrDOS 1y agoNo need to bring JavaScript into it. In HTML, use `<picture>`: https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Elements/picture https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/... In CSS, use `image-set()`: https://developer.mozilla.org/en-US/docs/Web/CSS/image/image-set https://developer.mozilla.org/en-US/docs/Web/CSS/image/image....
- alwillis 1y agoI get it but 2+ billion Apple device users is not nothin’. They can render JPEG-XL; everything else will render the fall back format like JPEG or WebP.
- throw_m239339 1y agoTeams & developers will likely only chose a single format if they can, the one that most browsers support, because doing some content negotiation is more code, more work. It doesn't take away anything from the parent point though, if JPEG-XL is more performant it could reduce bandwidth requirements.
- alwillis 1y ago> because doing some content negotiation is more code, more work It's actually not more work. The user's browser automatically handles the content negotiation and only downloads the image format it understands: <picture> <source srcset="photo.jxl" type="image/jxl"> <source srcset="photo.webp" type="image/webp"> <img src="photo.jpg" alt="Product photo" loading="lazy"> </picture> macOS, iPadOS and iOS get the JPEG-XL image, device that can handle WebP get that and everything else gets JPEG. There are several image delivery services that will provide the best image format depending on the device that's connecting.