5 ms·

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

JyrkiAlakuijala 3y ago
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.
onion2k 3y ago
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.
- jedberg 3y ago
  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.
  - deleted 3y ago
    [deleted]
  - CharlesW 3y ago
    > 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 https://github.com/niutech/jxl.js
    - cornstalks 3y ago
      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."
- mynameisvlad 3y ago
  So what if you only care about JPEG-XL?
  - onion2k 3y ago
    [flagged]
    - mynameisvlad 3y ago
      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?
      - onion2k 3y ago
        [flagged]
lozenge 3y ago
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.
- yread 3y ago
  Not everyone is using the web to blog you know... Imagine if google maps satellite view could save 30% of image bandwidth
CharlesW 3y ago
> 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.
- ksec 3y ago
  >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.
dbbk 3y ago
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.

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.

onion2k 3y ago

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.

jedberg 3y ago
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.
- deleted 3y ago
  [deleted]
- CharlesW 3y ago
  > 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 https://github.com/niutech/jxl.js
  - cornstalks 3y ago
    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."
mynameisvlad 3y ago
So what if you only care about JPEG-XL?
- onion2k 3y ago
  [flagged]
  - mynameisvlad 3y ago
    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?
    - onion2k 3y ago
      [flagged]

lozenge 3y ago

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.

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

CharlesW 3y ago

> 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.

ksec 3y ago
>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.

dbbk 3y ago

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.