Hacker News Reader

Comment by jimktrains2 | Hacker News Reader

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 :-\

View on HN

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.

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

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.

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

You are very close to CSS media queries there. Perhaps there is a solution in media queries.

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.

Reply on news.ycombinator.com