4 ms·

Isn't the problem more that the browser can't be given multiple sources and types and allow it to chose what it believes is best? User-Agent sniffing really do

Isn't the problem more that the browser can't be given multiple sources and types and allow it to chose what it believes is best? User-Agent sniffing really does need to die. Part of me wonders what use UA headers serve beyond sniffing and analytics. EDIT: or the Accept (and content-type) header, but that's a next to worthless header anymore :-\

cbr 12y ago
Isn't the problem more that the browser can't be given multiple sources and types and allow it to chose what it believes is best? How would this look? If you simply did: <img src-options="image.jpg image.webp"> There's no way for the browser to know which one it wants without downloading all of them, because extensions aren't special. But I guess we could extend srcset to let you specify content type: <img srcset="medium.jpg 1000w image/jpeg, medium.webp 1000w image/webp, large.jpg 2000w image/jpeg, large.webp 2000w image/webp">
- SoftwareMaven 12y ago
  You are very close to CSS media queries there. Perhaps there is a solution in media queries.
- larzang 12y ago
  You just described the new "picture" element. It's an element with one or more "source" child elements which each have a media query and a uri, as well as an img child element to use as a fallback for non-supporting browsers. Browser support isn't really there yet but it's coming and since it has a built-in fallback you can use it now without requiring JS workarounds.
  - acdha 12y ago
    It's under consideration in IE so now would be a good time to vote for it since it's so much cleaner than srcset: https://wpdev.uservoice.com/forums/257854-internet-explorer-platform/suggestions/6261271-picture-element https://wpdev.uservoice.com/forums/257854-internet-explorer-...
sitharus 12y ago
That's actually a solved problem! As the article mentioned, it works the other way around - the browser specifies what it can receive. Since this wasn't around from day 1 it's really opt-in. Sure, sometimes Google make a SNAFU and break webp support, but if you're on the cutting edge that's what you get. Let's see what Chrome sends when it requests an image: GET /myimage.jpg Host: myhost.com Accept: image/webp,*/*;q=0.8 Accept-Encoding: gzip,deflate,sdch Accept-Language: en-US,en;q=0.8 That Accept line is part of HTTP Content Negotiation. Chrome is saying "I want that content, and I'd like a webp if you have one. Otherwise whatever you have is fine". Ideally it would list each image type it can handle, so the server can send an appropriate error if a suitable image can't be found. History being what it is though the / is needed. Alas this isn't really exploited enough, since you'd end up with ridiculous request sizes: Accept: image/webp,image/webp+lossless,image/webp+animated,*/*;q=0.8 You can see where that's going... Accept-Encoding is the one that's used most often. Compression on the server side is very useful to reduce latency, and for static resources it is often free - servers can pre-compress them. Accept-Language is sadly under-utilised, for the same reason we send dates from the server rather than using the user's clock - people often have misconfigured machines, or are using a friend's computer and don't want to change the language. There's a lot of things in HTTP, it'd be a shame to reinvent the wheel in JavaScript.
csirac2 12y ago
Why are accept headers next-to-worthless? I'm not heavily involved in front-end stuff these days but it's something I've relied on for years by now - admittedly not for image/media content, but still I'm curious.

cbr 12y ago

Isn't the problem more that the browser can't be given multiple sources and types and allow it to chose what it believes is best? How would this look? If you simply did: <img src-options="image.jpg image.webp"> There's no way for the browser to know which one it wants without downloading all of them, because extensions aren't special. But I guess we could extend srcset to let you specify content type: <img srcset="medium.jpg 1000w image/jpeg, medium.webp 1000w image/webp, large.jpg 2000w image/jpeg, large.webp 2000w image/webp">

SoftwareMaven 12y ago
You are very close to CSS media queries there. Perhaps there is a solution in media queries.
larzang 12y ago
You just described the new "picture" element. It's an element with one or more "source" child elements which each have a media query and a uri, as well as an img child element to use as a fallback for non-supporting browsers. Browser support isn't really there yet but it's coming and since it has a built-in fallback you can use it now without requiring JS workarounds.
- acdha 12y ago
  It's under consideration in IE so now would be a good time to vote for it since it's so much cleaner than srcset: https://wpdev.uservoice.com/forums/257854-internet-explorer-platform/suggestions/6261271-picture-element https://wpdev.uservoice.com/forums/257854-internet-explorer-...

sitharus 12y ago

That's actually a solved problem! As the article mentioned, it works the other way around - the browser specifies what it can receive. Since this wasn't around from day 1 it's really opt-in. Sure, sometimes Google make a SNAFU and break webp support, but if you're on the cutting edge that's what you get. Let's see what Chrome sends when it requests an image: GET /myimage.jpg Host: myhost.com Accept: image/webp,*/*;q=0.8 Accept-Encoding: gzip,deflate,sdch Accept-Language: en-US,en;q=0.8 That Accept line is part of HTTP Content Negotiation. Chrome is saying "I want that content, and I'd like a webp if you have one. Otherwise whatever you have is fine". Ideally it would list each image type it can handle, so the server can send an appropriate error if a suitable image can't be found. History being what it is though the / is needed. Alas this isn't really exploited enough, since you'd end up with ridiculous request sizes: Accept: image/webp,image/webp+lossless,image/webp+animated,*/*;q=0.8 You can see where that's going... Accept-Encoding is the one that's used most often. Compression on the server side is very useful to reduce latency, and for static resources it is often free - servers can pre-compress them. Accept-Language is sadly under-utilised, for the same reason we send dates from the server rather than using the user's clock - people often have misconfigured machines, or are using a friend's computer and don't want to change the language. There's a lot of things in HTTP, it'd be a shame to reinvent the wheel in JavaScript.

csirac2 12y ago

Why are accept headers next-to-worthless? I'm not heavily involved in front-end stuff these days but it's something I've relied on for years by now - admittedly not for image/media content, but still I'm curious.