Hacker News new | past | comments | ask | show | jobs | submit login

Learn to use the <picture> element and you can stop caring about what petty squabbles browser vendors have around which image formats they choose to support. It's in all the browsers (except IE..), it handles image fallbacks really nicely, and every site should use it where they have an <img> right now.



> you can stop caring about what petty squabbles browser vendors have around which image formats they choose to support.

I think you misunderstand what the picture element does. Yes, you can put a JXL image into a picture tag, but Chrome still won't render it. You'd still need a backup (lower quality) JPG.

You still have to worry about what image formats the vendors support, and now you have the added burden of making sure you have backups for all your images.


Yeah, uploading six versions of every image doesn't intersect with my definition of not caring.


> Yeah, uploading six versions of every image doesn't intersect with my definition of not caring.

You're not doing this manually though, and images encoded for distribution are small. The path to JPEG XL eventually mattering is by JPEG XL alternates being automatically created from a higher-quality source image by your CMS, or at build time, or via services like CloudFlare Images, etc.

Even once Safari 17 (and all iOS browsers via WebKit) makes JPEG XL worth making an alternate for, most sites are realistically 5+ years away from not having to have a JPEG fallback. And if you're doing that, you might as well support the far-more-popular WebP as well.


>you might as well support the far-more-popular WebP as well.

May be far more compatible. I am not sure if WebP is actually popular.


Every company I've worked at just serves images from something like Imgix or Cloudinary, which converts them on the fly. Never have to think about it.


This is why people use platforms like Squarespace, Substack, Medium, or if self hosting at least use a CMS. Just add it to the list of things you need to learn to run a website, along with... JS bundlers, CSS media queries, responsive design... now we need to pre process images too. All in the pursuit of quality, of course.


Not everyone is using the web to blog you know... Imagine if google maps satellite view could save 30% of image bandwidth


Yeah, uploading six versions of every image doesn't intersect with my definition of not caring.

What I meant was that you only need to care about what image formats you want to support. You don't need to care about what image formats browser vendors support.


Except that you're totally wrong. If you care about JXL, and only want to support JXL, and you put a JXL in your picture tag, then the browser still won't render it, even if you use a picture tag.


> If you care about JXL, and only want to support JXL, and you put a JXL in your picture tag, then the browser still won't render it, even if you use a picture tag.

Is this true if you provide a polyfill? Have you tried it and it failed? (Serious question.)

https://github.com/niutech/jxl.js


Having to provide a polyfill is the opposite of "stop caring about what petty squabbles browser vendors have around which image formats they choose to support."


So what if you only care about JPEG-XL?


[flagged]


Gotta love being called a dick for having a hypothetical opinion on image formats.

You are suggesting that `<picture>` alone would solve this issue. It very clearly does not; you're still limited by what browsers support the format you use in your pictures. If you only release it in one format because you don't want to deal with compression/format changes/whatever, then you still have the same exact problem.

If months from now, Chrome is the only browser that doesn't support it, then it's just as bad of a solution as now, and I'd no longer be called a dick by a random stranger on the internet. What then?


Compress your jpeg with jpegli. Configure your webserver to losslessly recompress to jpeg xl. You don't even notice that new formats arrived but will get 90% of the benefit.


I think the point is that you can then put multiple versions in it to get the best option supported in each browser.

There are lots of reasons why that's annoying to do, but it's a solution.


> you can stop caring

If your goal is purely compatibility, then using img with either PNG or JPEG will be just fine.

If however you care about image quality, bandwidth, &c. then you should use picture but... you'll also probably care about what % of your users are getting served whatever image version you consider optimal.

So using picture and stopping caring seem like opposites to me.

Otherwise, 100% agree: use picture.


It’s pretty nice, although it makes your image encoding, storage, and HTML size N times larger to support N formats. That gets even crazier if you also want responsive images.


Does the picture element make it easier to handle jxl files with a wasm polyfill? That seems like the ideal case— website maintainer only has to deal with, store, and serve a single file, old browsers get only a slightly degraded experience.


More info for those inclined. In short, you can specify multiple versions of the same image…

> “ The HTML <picture> element gives web developers more flexibility in specifying image resources.

> The <picture> element contains one or more <source> elements, each referring to different images through the srcset attribute. This way the browser can choose the image that best fits the current view and/or device.

> Each <source> element has a media attribute that defines when the image is the most suitable.”

https://www.w3schools.com/html/html_images_picture.asp




Join us for AI Startup School this June 16-17 in San Francisco!

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: