10 ms·

I wish they had extended content negotiation to let the browser request an image near an ideal size in pixels using some kind of Accept header. Adding cruft lik

I wish they had extended content negotiation to let the browser request an image near an ideal size in pixels using some kind of Accept header. Adding cruft like "med-hd" to the URL path is a design smell, and so is being able to suggest it from HTML but not HTTP.

hcarvalhoalves 13y ago
> using some kind of Accept header. That would be way saner, the problem is that it seems no one wants wants to touch HTTP. Browser vendors work under the assumption that whatever feature they implement, it only has a chance of being adopted if it can be hacked in other browsers with javascript shims.
- bsimpson 13y ago
  The stupid part about that logic re:images is that you get graceful degradation for free in systems that don't implement the additional Accept header.
  - lukeschlather 13y ago
    It's not stupid. From an academic perspective, sure it works either way. From a business perspective, you have to support the full feature set on a given set of browsers, and you're not going to waste time on a solution that only covers 80% of your required browsers when you can write one codebase that covers all of your browsers.
1qaz2wsx3edc 13y ago
Or have a progressive image format. Wherein the smallest/lowest quality image is at the front of the file and is enhanced by loading more data of the same file. It should be up to the browser and the image file format to determine the best option.
- adamzochowski 13y ago
  JPEG2000 had awesome option of having progressive quality. During compression user could specify number of quality years, with each layer having specific compression ratios. Browser could download a chunk of JPEG2000 and render it, and depending on bandwidth available the browser would keep downloading and improving image quality. Both Jasper support this (ilyrrates) and OpenJpeg (-r and -q) support this functionality.
  - acdha 13y ago
    I really wish the open-source JP2 situation was better. OpenJPEG is looking good but it's still in need of some performance work – which is a real shame since, as you pointed out, it'd be perfect for responsive imaging - just use HTTP byte ranges and it'd work with most proxies and caches, too.
- othermaciej 13y ago
  That's not so great for high-latency networks (like most cellular networks). If you use range requests, you add round trips. If you cancel the load partway, you're too late because your pipe is already filled with bits you don't need.
  - acdha 13y ago
    You could avoid that with a simple optimization where the page could indicate the byte ranges for a tile level. Suppose something like this worked: <picture> <source srcset="foo.jp2 100w 100h range=1-<first layer>"> <source srcset="foo.jp2 500w 500h range=1-<middle>"> <source srcset="foo.jp2 1000w 1000h"> </picture> That'd avoid the need to a round trip at all and it'd also be a huge improvement for caches which support HTTP range correctly since it'd be a single resource rather than multiple different URLs. It'd also allow browsers to start making decisions like selectively preloading more of an image which the user is likely to zoom, etc. although some of that would come simply from a good progressive JP2 implementation.
    - 13y ago
kalleboo 13y ago
That would certainly be the cleanest solution, but I think we rely on so many old servers, CDNs, shared hosts etc that implementors (rightfully) worry that it would hurt uptake.
bmm6o 13y ago
On the other hand, could that work without server-side code? If the logic is all done in the browser, you don't need support in your web server and you can still load pages straight from disk.
- hcarvalhoalves 13y ago
  All it would take is some internal rewrite on the server, some directive to serve "lolcat_300dpi.jpg" when the client requests "/media/lolcat.jpg" with an accept header like "image/jpeg;dpi=300". It would be way more flexible and even easier to implement, since you don't have to revisit all your markup.
  - lukeschlather 13y ago
    Theoretically, yes, but that means you need a pretty complicated setup to serve static assets. Also, this solution can be built into a Javascript shim for older browsers, something header-based would be much harder to do as a shim.
    - hcarvalhoalves 13y ago
      > Theoretically, yes, but that means you need a pretty complicated setup to serve static assets. Why? There's no difference on the server side, you would have multiple versions of the same file anyway. You're just exchanging the responsibility of getting the right file from the markup to responding with the right file on the server (which is way easier to keep consistent, IMO).
      - lukeschlather 13y ago
        The way I see it, keeping it in the markup makes it more straightforward to debug. If it's server-side, all of our developers need direct access to the asset server as soon as there are content negotiation issues. If it's client-side, we can share a highly-available asset server and each developer has their code sandboxed. In an ideal world, it would be server side. But it would easily mean twice as much work to get there.
ha-ha-ha 13y ago
I wish people would spend a few hundred hours thinking about, discussing and implementing a feature, before posting critique opinions.

hcarvalhoalves 13y ago

> using some kind of Accept header. That would be way saner, the problem is that it seems no one wants wants to touch HTTP. Browser vendors work under the assumption that whatever feature they implement, it only has a chance of being adopted if it can be hacked in other browsers with javascript shims.

bsimpson 13y ago
The stupid part about that logic re:images is that you get graceful degradation for free in systems that don't implement the additional Accept header.
- lukeschlather 13y ago
  It's not stupid. From an academic perspective, sure it works either way. From a business perspective, you have to support the full feature set on a given set of browsers, and you're not going to waste time on a solution that only covers 80% of your required browsers when you can write one codebase that covers all of your browsers.

1qaz2wsx3edc 13y ago

Or have a progressive image format. Wherein the smallest/lowest quality image is at the front of the file and is enhanced by loading more data of the same file. It should be up to the browser and the image file format to determine the best option.

adamzochowski 13y ago
JPEG2000 had awesome option of having progressive quality. During compression user could specify number of quality years, with each layer having specific compression ratios. Browser could download a chunk of JPEG2000 and render it, and depending on bandwidth available the browser would keep downloading and improving image quality. Both Jasper support this (ilyrrates) and OpenJpeg (-r and -q) support this functionality.
- acdha 13y ago
  I really wish the open-source JP2 situation was better. OpenJPEG is looking good but it's still in need of some performance work – which is a real shame since, as you pointed out, it'd be perfect for responsive imaging - just use HTTP byte ranges and it'd work with most proxies and caches, too.
othermaciej 13y ago
That's not so great for high-latency networks (like most cellular networks). If you use range requests, you add round trips. If you cancel the load partway, you're too late because your pipe is already filled with bits you don't need.
- acdha 13y ago
  You could avoid that with a simple optimization where the page could indicate the byte ranges for a tile level. Suppose something like this worked: <picture> <source srcset="foo.jp2 100w 100h range=1-<first layer>"> <source srcset="foo.jp2 500w 500h range=1-<middle>"> <source srcset="foo.jp2 1000w 1000h"> </picture> That'd avoid the need to a round trip at all and it'd also be a huge improvement for caches which support HTTP range correctly since it'd be a single resource rather than multiple different URLs. It'd also allow browsers to start making decisions like selectively preloading more of an image which the user is likely to zoom, etc. although some of that would come simply from a good progressive JP2 implementation.
  - 13y ago

kalleboo 13y ago

That would certainly be the cleanest solution, but I think we rely on so many old servers, CDNs, shared hosts etc that implementors (rightfully) worry that it would hurt uptake.

bmm6o 13y ago

On the other hand, could that work without server-side code? If the logic is all done in the browser, you don't need support in your web server and you can still load pages straight from disk.

hcarvalhoalves 13y ago
All it would take is some internal rewrite on the server, some directive to serve "lolcat_300dpi.jpg" when the client requests "/media/lolcat.jpg" with an accept header like "image/jpeg;dpi=300". It would be way more flexible and even easier to implement, since you don't have to revisit all your markup.
- lukeschlather 13y ago
  Theoretically, yes, but that means you need a pretty complicated setup to serve static assets. Also, this solution can be built into a Javascript shim for older browsers, something header-based would be much harder to do as a shim.
  - hcarvalhoalves 13y ago
    > Theoretically, yes, but that means you need a pretty complicated setup to serve static assets. Why? There's no difference on the server side, you would have multiple versions of the same file anyway. You're just exchanging the responsibility of getting the right file from the markup to responding with the right file on the server (which is way easier to keep consistent, IMO).
    - lukeschlather 13y ago
      The way I see it, keeping it in the markup makes it more straightforward to debug. If it's server-side, all of our developers need direct access to the asset server as soon as there are content negotiation issues. If it's client-side, we can share a highly-available asset server and each developer has their code sandboxed. In an ideal world, it would be server side. But it would easily mean twice as much work to get there.

ha-ha-ha 13y ago

I wish people would spend a few hundred hours thinking about, discussing and implementing a feature, before posting critique opinions.