Why Parse the User Agent?
jefftk.com
Why Parse the User Agent?
1–10 of 78 posts
Re: Why Parse the User Agent?
#2The author dismisses feature detection as being "slow", but it's much less error prone:
http://www.stucox.com/blog/using-webp-with-modernizr/
You can just cache the result in localStorage; you take a few-millisecond hit once.
Here's how the feature detection is done:
https://github.com/Modernizr/Modernizr/blob/924c7611c170ef2d...
HOWEVER, in this case (webp), it's likely better to detect it on the server:
https://github.com/igrigorik/webp-detect (More info: http://www.stucox.com/blog/client-side-vs-server-side-detect...)
The only time you really should be looking at the User Agent is if you're trying to do something like show a "Download for (Chrome|Firefox|etc)" button.
Re: Why Parse the User Agent?
#3The author dismisses feature detection as being "slow", but it's much less error prone: http://www.stucox.com/blog/using-webp-with-modernizr/ You can just cache the result in localStorage; you take a few-millisecond hit once. Here's how the feature detection is done: https://github.com/Modernizr/Modernizr/blob/924c7611c170ef2d... HOWEVER , in this case (webp), it's likely better to detect it on the server: https://gi…
> The only time you really should be looking at the User Agent is if you're trying to do something like show a "Download for (Chrome|Firefox|etc)" button.
Amen.
Re: Why Parse the User Agent?
#4Mr Kaufman, JavaScript is like violence: If it isn't solving your problems, then you're not using enough of it.
Re: Why Parse the User Agent?
#5The author dismisses feature detection as being "slow", but it's much less error prone: http://www.stucox.com/blog/using-webp-with-modernizr/ You can just cache the result in localStorage; you take a few-millisecond hit once. Here's how the feature detection is done: https://github.com/Modernizr/Modernizr/blob/924c7611c170ef2d... HOWEVER , in this case (webp), it's likely better to detect it on the server: https://gi…
> HOWEVER, in this case (webp), it's likely better to detect it on the server:
It would be awesome if this idea could be extended to HTML. I'd love to see content negotiation in an Accept header, or some other kind of feature-list header that the browser sends to notify my server of what features it supports. I could then pass that data down to JS or, since the browser already knows that information, why not have a `navigator.features` object that developers can look in and see exactly what is supported? Would eliminate the need for Modernizr or performing your own feature detection...and save a lot of code.
Re: Why Parse the User Agent?
#6My personal approach...use feature detection for the first pass. User Agents for the cases where it doesn't work. And by the way, it doesn't always work, and some "features" cannot be detected.
I've spent a lot of time optimizing pages for video. Some browsers work just fine, some work but look like crap, so you use a flash/silverlight plugin, then a new version comes out and looks less crappy.
I also have a lot of code I turn off just for IE7...the code works, but doesn't render properly. There is no way to detect "renders ugly"
So, "YES", feature detection is the future...but it isn't quite there yet (about 98%).
Re: Why Parse the User Agent?
#7I imagine that in the future with HTTP2 we could send the list of available browser features as HTTP headers such as Animated-WebP: Supported ? With HTTP1 the cost of sending long list of available features would be too big probably. But could HTTP2 solve this problem. If I recall correctly it only sends diffs of headers between subsequent requests in the same connection. Maybe that could be helpful for a class of problems like this one and similar.
Re: Why Parse the User Agent?
#8Author 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-...
Re: Why Parse the User Agent?
#9Yay! 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.
Re: Why Parse the User Agent?
#10Unfortunately, encouraging people to parse the UA header leads to them getting it wrong in a way that would be amusing if it wasn't so irritating.
For example FirefoxOS has a UA string of the from User-Agent:Mozilla/5.0 Mobile Gecko/28 Firefox/32.0'. There's an example in bugzilla of a major site that, not only depends on the file details of that format, but will send the mobile version of the site if and only if the number after Firefox is even and in the range 18 Such examples are not one-offs either. In fact it is so common for sites to screw up here that browser vendors often resort to sending specially crafted UA strings to certain sites in order that the content become accessible. The most extreme example of this was pre-blink Opera which had much better compat than it was given credit for, but was often blocked — acidentially or intentionally — from sites that effectively whitelisted certain browsers. As a result it used an auto-updated list of sites for which it had to send an alternate UA string [1] as well as a sophisticated system of javascript injection to work around more complex bugs in these sites [2].
[1] https://github.com/operasoftware/browserjs/blob/master/deskt... [2] https://github.com/operasoftware/browserjs/blob/master/deskt...