Live data from Hacker News

Why Parse the User Agent?

jefftk.com

21–30 of 78 posts

Re: Why Parse the User Agent?

#21
post #18

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

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:

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

Re: Why Parse the User Agent?

#22
post #18

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

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:

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.

Re: Why Parse the User Agent?

#23

The 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…

Saving the query in localStorage won't make it any faster. If anything it will make it slower.

The performance issue the article mentions is that deciding which format to use in JavaScript breaks preload scanning and essentially serializes resource requests that would otherwise be parallel.

Doing the check itself is fast. It's just decoding a very small image in memory. Storing the result of that check persistently just adds more cost.

Re: Why Parse the User Agent?

#24
post #19

Earlier quoted context omitted.

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

That doesn't explain what it actually is, though. How it does multiple frames.

It does clarify that it's at least not quite WebM, but it doesn't explain how far away it is.

Re: Why Parse the User Agent?

#25
post #10

Unfortunately, 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…

There's a whole class of old ASP sites that break if you take "like Gecko" out of the UA. It would be funny if it hadn't made me cry so often.

Re: Why Parse the User Agent?

#26
post #22
post #18

Earlier quoted context omitted.

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:

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

Re: Why Parse the User Agent?

#27
It seems, for many of the reasons stated below, that feature detection in JavaScript will never be a sufficient solution. But clearly asking web developers to manually parse and interpret UA strings is asking for trouble.

Does anyone know if there is an authoritative database of user agent string, their associated browsers and the features of those browsers?

Re: Why Parse the User Agent?

#28
Asp.Net 2.0 (and up to 3.5, which is still framework 2.0) sites use UA sniffing to determine which markup to emit for many built-in controls, like Asp:Menu. When Yosemite / iOS 8 / Safari 8 was released, anyone with a SharePoint 2007/2010 site had their navigation get all screwy. I know first hand how infuriating someone's badly designed UA sniffing can be; it happened to me, and I wrote up a fix for it [0].

Why did it happen in the first place? Where did the UA sniffing fall apart?

A poorly designed RegExp looking for "60" in Safari's UA without a word boundary or EOL check. The new Safari UA includes "600" in the relevant section, and suddenly SharePoint sites were sending markup intended for (now) ancient browsers - browsers that weren't even on the compatibility list for SharePoint in the first place.

UA sniffing does need to go away for determining what structure your markup sends to the user agent.

[0]: http://blog.sharepointexperience.com/2014/10/did-safari-or-i...

Re: Why Parse the User Agent?

#29
I agree this is a decent solution, and the one OP compares to is not.

But I would have javascript feature detect, and set a cookie based on what it found. Now, for all but the first page, the server can look at the cookie instead of the User-Agent string. Server just needs to sniff user-agent string if it doesn't (yet) have a cookie.

Re: Why Parse the User Agent?

#30

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

yet another? What others are there on the web?

I'm surprised preview doesn't do WebP, that's too bad.

Post reply on HN