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:
Why Parse the User Agent?
21–30 of 78 posts
Re: Why Parse the User Agent?
#22Isn'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:
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?
#23The 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 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?
#24Earlier 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...
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?
#25Unfortunately, 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…
Re: Why Parse the User Agent?
#26Earlier 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.
https://wpdev.uservoice.com/forums/257854-internet-explorer-...
Re: Why Parse the User Agent?
#27Does 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?
#28Why 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?
#29But 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?
#30Yay! 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'm surprised preview doesn't do WebP, that's too bad.