Why Parse the User Agent?
11–20 of 78 posts
Re: Why Parse the User Agent?
#12Yay! Yet another image format that I can't open in Preview, if I save it to my hard drive. Webp may be great for displaying in a web page, but it's TFU if I save it to my hard drive and try to view it with default viewing or editing software. It may not be a proprietary format, but it might as well be.
BTW: gthumb opens it A-OK. So, maybe the issue isn't the openness of the format, but the openness of your platform?
Re: Why Parse the User Agent?
#13Author is going about this in completely the wrong way. The best way to determine if you should deliver webp or jpeg is to look at the browser's accept header [1]. In this header you will find a listing of what the browser is willing to accept and the order of preference. [1] https://www.igvita.com/2013/05/01/deploying-webp-via-accept-...
"To emit html that references either a JPEG or a WebP depending on the browser, you need some way that the server can tell whether the browser supports WebP. Because this feature is so valuable, there is a standard way of indicating support for it: include image/webp in the Accept header. Unfortunately this doesn't quite work in practice. For example, Chrome v36 on iOS broke support for WebP images outside of data:// urls but was still sending Accept: image/webp. Similarly, Opera added image/webp to their Accept header before they supported WebP lossless. And no one indicates in their Accept whether they support animated WebP."
Re: Why Parse the User Agent?
#14Author is going about this in completely the wrong way. The best way to determine if you should deliver webp or jpeg is to look at the browser's accept header [1]. In this header you will find a listing of what the browser is willing to accept and the order of preference. [1] https://www.igvita.com/2013/05/01/deploying-webp-via-accept-...
From the article: "To emit html that references either a JPEG or a WebP depending on the browser, you need some way that the server can tell whether the browser supports WebP. Because this feature is so valuable, there is a standard way of indicating support for it: include image/webp in the Accept header. Unfortunately this doesn't quite work in practice. For example, Chrome v36 on iOS broke support for WebP images…
....what the heck is an animated WebP
Re: Why Parse the User Agent?
#15Author is going about this in completely the wrong way. The best way to determine if you should deliver webp or jpeg is to look at the browser's accept header [1]. In this header you will find a listing of what the browser is willing to accept and the order of preference. [1] https://www.igvita.com/2013/05/01/deploying-webp-via-accept-...
From the article: "To emit html that references either a JPEG or a WebP depending on the browser, you need some way that the server can tell whether the browser supports WebP. Because this feature is so valuable, there is a standard way of indicating support for it: include image/webp in the Accept header. Unfortunately this doesn't quite work in practice. For example, Chrome v36 on iOS broke support for WebP images…
It's not a good argument for crafting html that bypasses content negotiation.
Re: Why Parse the User Agent?
#16User-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 :-\
Re: Why Parse the User Agent?
#17Yay! Yet another image format that I can't open in Preview, if I save it to my hard drive. Webp may be great for displaying in a web page, but it's TFU if I save it to my hard drive and try to view it with default viewing or editing software. It may not be a proprietary format, but it might as well be.
I'll admit that support for the format isn't perfect, but at least in your case it can be remedied pretty easily with a quick search [1]. That said, format adoption has to start somewhere. It'd be pretty sad if we were still using GIFs for all of our lossless images because PNGs were never allowed to catch on before they could become universally supported.
Re: Why Parse the User Agent?
#18Isn'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 :-\
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:
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: Re: Why Parse the User Agent?
#19Earlier quoted context omitted.
From the article: "To emit html that references either a JPEG or a WebP depending on the browser, you need some way that the server can tell whether the browser supports WebP. Because this feature is so valuable, there is a standard way of indicating support for it: include image/webp in the Accept header. Unfortunately this doesn't quite work in practice. For example, Chrome v36 on iOS broke support for WebP images…
Well those are dumb problems but sniffing UA doesn't really fix them. You'll still have clients suddenly broken. ....what the heck is an animated WebP
what the heck is an animated WebP
A drop in improvement for animated GIF: https://developers.google.com/speed/webp/faq#why_should_i_us...Re: Why Parse the User Agent?
#20Client side JS for feature detection can work well, I have a simple example in the code of http://http-echo.com