Hi, probably a hot potato this or can of worms etc etc. But what is wrong with browser sniffing? I read a lot of posts here (rarely qualified to help but I do my best) and where people are trying to resolve problems they often say "as a work around I can do it this way but don't want to resort to browser sniffing" and they never really say why. Ok a lot of browser sniffing relies on javascript and if the user has it turned off or they are using a mobile browser that doesn't support it then there is a problem but what about scripts written in say PHP or other server side languages. I've just used a php script on a site that, because the site uses png transparency, it basically says if ie6 or below replace parts of the HTML with GIF elements instead of PNGs. I've tested it extensively on as many browsers as I can think of on both mac and pc and don't have any problems.
Any reasons not to use such a script?
Incidently if IE6 vanished off the radar tomorrow then I wouldn't need to browser sniff either. Maybe the question is should we still be spending so much of our time supporting IE6?
Fang
02-26-2009, 02:51 PM
Browsers can fake the user agent string, you could sniff IE6, but in reality it could be Safari.
Use object detection (http://www.quirksmode.org/js/support.html) and conditional comments (http://msdn.microsoft.com/en-us/library/ms537512.aspx).
felgall
02-26-2009, 02:52 PM
Browser sniffing relies on a field that is completely under user control - it can contain anything.
If the browser useragent identifies the browser as Internet Explorer then the browser might be Internet Explorer or it might be Firefox or Opera or Safari or any of hundreds of other browsers pretending to be Internet Explorer.
If the browser useragent identifies the browser as Firefox then the browser might be Firefox or it might be Internet Explorer or Opera or Safari or any of hundreds of other browsers pretending to be Firefox.
If the browser useragent identifies the browser as Opera then the browser might be Opera or it might be Internet Explorer or Firefox or any of hundreds of other browsers pretending to be Opera.
and so on for all the other possible browsers.
Browser sniffing is also completely unnecessary since browsers since Netscape 2 have supported feature sensing meaning that you can test in your code whether the feature your code is trying to use is supported by the browser or not. Unless your browser sniffing includes a lookup table for all the different versions of all of the thousands of different browser as to which support what features you are trying to use and you update it every day for the new browsers that are released, your browser sniffer is not going to accurately determine whether or not certain code is or isn't supported even assuming that it managed to correctly identify the browser in the first place.
You don't need browser sniffers for Internet Explorer anyway as you can use conditional comments either in the HTML or JScript to identify various versions of IE which will be 100% accurate instead of misidentifying many of your visitors by using something as inaccurate and useless as browser sniffing.
Declan1991
02-26-2009, 03:12 PM
Browser sniffing is abhorred because it is effectively useless. A developer doesn't (or shouldn't) care what browser the user is using, but what features are supported by that browser (see Fang's comment). That and the fact that you can only ever check for the latest versions of the most popular browsers, and even if they are who they say they are, you are still excluding plenty of other browsers.
cannon303
02-26-2009, 04:33 PM
ok great feedback so far. Firstly what reason would there be for browsers to fake the user agent string and secondly why would the user set their browser to represent their browser as a different browser from the one they are using?
Maybe someone could set me straight with my conditional comments. I'm using:
<!--[if lte IE 6]>
<link rel="stylesheet" type="text/css" href="ie6_hacks.css" media="screen" />
<![endif]-->
these work fine and did pass w3c validation. However recently w3c now consider the last statement as invalid. So does anyone know how I should write this so that firefox etc will work?
Edit.
P.S. When I use
<!--[if !IE 6]>
...statements...
<![endif]-->
Firefox doesn't impliment the css
Declan1991
02-26-2009, 04:53 PM
ok great feedback so far. Firstly what reason would there be for browsers to fake the user agent string and secondly why would the user set their browser to represent their browser as a different browser from the one they are using?
Because of browser sniffing, some websites started not providing full functionality to browsers other than IE something or other. Thus, Opera started to pretend it was IE etc.
The best way to use conditional comments is
Firefox
<conditional comment for ie>
<others as needed>
That utilises the cascading features of CSS, so the conditional comments overwrite the standard ones. Conditional comments ONLY work in IE, therefore, "if not IE 6" means IE 7 or 5, not Firefox.
TheTeenScripter
02-26-2009, 04:59 PM
I think browser sniffing should be used when appropriate. For example, say I have a website that is W3C-Compatible, but it could look better. The current template is W3C, but you want a better-looking one for the more popular browsers. You could design a template that loads the data from the other pages transparently and integrates it into the page, as well as put in some pretty cool effects (javascript and what-not). This template would only work with certain browsers (with javascript turned on). A javascript browser sniffer could re-direct the page to the "template" page with the cool features and what-not, if the browser is right and javascript is turned on.
As for the user agent thing, if a user decides to change their agent, that is their choice and any problems resulting would be their fault and not the webmasters. Most web-browsers do not automatically "fake" their user-agent, and any that do probably aren't worth the download.
EDIT: Admittedly, IE does kinda fake the mozilla agent, but it still represents itself as Internet Explorer.. But I stand by what I say cuz IE isn't worth the download anyways lmao
cannon303
02-26-2009, 05:00 PM
ok i've read fang's link to conditionals a bit further and it seems I have to use:
<!--[if !IE 6]>
<!--><link rel="stylesheet" type="text/css" href="not_ie6_hacks.css" media="screen" />
<!--<![endif]--> to get around the validator.
And thanks to all replies, I understand about the fact that some websites stopped providing support to various browsers - thanks to Declan1991 for that, I do remember reading something about that now.
And don't worry I won't start a "why should we still support ie6" thread just yet! There's enough to read about that subject in google.
cannon303
02-26-2009, 05:05 PM
I think browser sniffing should be used when appropriate. For example, say I have a website that is W3C-Compatible, but it could look better. The current template is W3C, but you want a better-looking one for the more popular browsers. You could design a template that loads the data from the other pages transparently and integrates it into the page, as well as put in some pretty cool effects (javascript and what-not). This template would only work with certain browsers (with javascript turned on). A javascript browser sniffer could re-direct the page to the "template" page with the cool features and what-not, if the browser is right and javascript is turned on.
As for the user agent thing, if a user decides to change their agent, that is their choice and any problems resulting would be their fault and not the webmasters. Most web-browsers do not automatically "fake" their user-agent, and any that do probably aren't worth the download.
EDIT: Admittedly, IE does kinda fake the mozilla agent, but it still represents itself as Internet Explorer.. But I stand by what I say cuz IE isn't worth the download anyways lmao
Interesting, so use javascript in the DOM if turned on go to differently styled site.
these work fine and did pass w3c validation. However recently w3c now consider the last statement as invalid. So does anyone know how I should write this so that firefox etc will work?
The first two are "downlevel-hidden" comments. The last one is "downlevel-revealed". See this page (http://msdn.microsoft.com/en-us/library/ms537512.aspx) for more details.
Unfortunately downlevel-revealed comments aren't valid. You should use downlevel-hidden comments for IE and the below version for non-IE:
<!--[if !IE]>-->
<link rel="stylesheet" type="text/css" href="not_ie_hacks.css" media="screen" />
<!--<![endif]-->
How IE sees it:
<!--[if !IE]>-->
<link rel="stylesheet" type="text/css" href="not_ie_hacks.css" media="screen" />
<!--<![endif]-->
How non-IE UAs sees it:
<!--[if !IE]>-->
<link rel="stylesheet" type="text/css" href="not_ie_hacks.css" media="screen" />
<!--<![endif]-->
The blue is where the comment starts/ends and the red is the contents of the comment (conditional or otherwise). Obviously the black is normal markup.
I got that from an article on 456 Berea St (http://www.456bereastreet.com/archive/200511/valid_downlevelrevealed_conditional_comments/).
TheTeenScripter
02-26-2009, 05:58 PM
I have an example of a use of browser-sniffing that I find absolutely fitting for the situation. It detects if the browser is IE/FF and if so, loads the template.html file. The template.html file loads the regular .html files in a hidden iframe, and then transfers (the content) onto the screen. It uses extensive javascript and other techniques probably not supported by many browsers, but will have some pretty cool features. I will be working on a template that will be loaded using server-side-includes for the rest of the site (W3C-Strict-Compatible), and this solution will basically give a rich look/feel for the most popular browsers (IE/FF), while still supporting the other browsers and passing W3C-Validation.
The site is up at http://threekordkillers.blackapplehost.com/
If you do happen to check the W3C-Validation on it, the only errors you will find are those of the code that blackapplehost.com puts on it, not my code (do not try to validate the template.html file though lmao)
Declan1991
02-26-2009, 06:33 PM
I haven't looked at exactly what the website uses TheTeenScripter, but I think you are missing the point. Why we are against browser-sniffing is because browser-sniffing doesn't tell you for sure whether or not a feature is available, and it is impossible to browser-sniff for every browser so you have to guess for them. For example, how do you deal with Opera, Safari, and the browser whose name I cannot remember that allows the user to switch between the Trident and Gecko rendering engines at will? They are being served content that doesn't have all the features, even though they possibly can support it.
What is acceptable (and vital in many cases) is object-detection. That actually fulfills the purpose of deciding whether something is possible or not by testing it directly, and not guessing based on the browser. Browser-sniffing is inexact and far more difficult to maintain.
And as forAs for the user agent thing, if a user decides to change their agent, that is their choice and any problems resulting would be their fault and not the webmasters. Most web-browsers do not automatically "fake" their user-agent, and any that do probably aren't worth the download.The reason browsers pretend to be other browsers is because otherwise their users are being discriminated against unfairly. Opera, certainly, faked the user-agent string by default in version 8 and below, and I'm sure other browsers have to copy them now, so the sweeping statement and generalization that "such browsers aren't worth downloading" is preposterous, arrogant and false.
TheTeenScripter
02-26-2009, 07:34 PM
I haven't looked at exactly what the website uses TheTeenScripter, but I think you are missing the point. Why we are against browser-sniffing is because browser-sniffing doesn't tell you for sure whether or not a feature is available, and it is impossible to browser-sniff for every browser so you have to guess for them. For example, how do you deal with Opera, Safari, and the browser whose name I cannot remember that allows the user to switch between the Trident and Gecko rendering engines at will? They are being served content that doesn't have all the features, even though they possibly can support it.
What is acceptable (and vital in many cases) is object-detection. That actually fulfills the purpose of deciding whether something is possible or not by testing it directly, and not guessing based on the browser. Browser-sniffing is inexact and far more difficult to maintain.
And as forThe reason browsers pretend to be other browsers is because otherwise their users are being discriminated against unfairly. Opera, certainly, faked the user-agent string by default in version 8 and below, and I'm sure other browsers have to copy them now, so the sweeping statement and generalization that "such browsers aren't worth downloading" is preposterous, arrogant and false.
Every website that uses browser-sniffing most likely has a very good reason for doing so. It is almost a pre-requisite that every site support both Internet Explorer as well as Firefox. It is unnecessary for a browser to fake it's user-agent IN ANY CASE and it is very wrong for these browsers to do so, because it can make the browser do things for which the webmaster never intended. That is why they are (probably) not worth downloading. Mozilla Firefox is one of the best browsers out there, NO QUESTIONS ASKED. It does not fake the agent, and it is one of most secure browsers out there (and open-source too). Also, I didn't say they aren't worth downloading, I said they PROBABLY aren't worth downloading (because everyone has their own preference).
I'm sure websites aren't trying to discriminate against browsers, but the webmasters of such sites either don't know how to code for those browsers (don't know W3C), they have special features only for those browsers, or they have a different (good) reason for doing so. Whatever their reason, a browser faking a user-agent IS NOT A GOOD IDEA. The user-agent was not designed for that.
Browser-detection should be used when the GUI is involved, and other browsers interpret the GUI differently. Object-detection should be used when a script needs to be run and you don't want to rely on just a select few browsers to run them on, but rather any browser that WILL run it.
My point is that object detection and browser-sniffing should both be used, but ONLY when and where they are needed, and that a browser that fakes a user-agent is trying to conform to ignorant webmasters unnecessarily and are the reason good webmasters have to constantly re-evaluate their code to work on all browsers, just because one browser decides to LIE to a website.
Here is what happens in steps:
- Ignorant webmaster codes only for internet explorer, and uses browser-sniffing to prevent others from accessing the site.
- Somebody trying to get "more compatibility" out of their browser un-necessarily fakes the user-agent, making certain pages load, but without the full-support of that browser's interpretation, it ends-up failing on many sites that use browser-detection the right way.
- Good webmasters end-up having to re-code their website in order to get the website working in the browser, when it probably would have worked if the browser had not faked the user-agent.
- People start having discussions about these problems, with many different points of view, wasting yet more time that could have been put to better use
And to think that all of that could have been avoided had everyone used the user-agent the way it was meant to be used
TheTeenScripter
02-26-2009, 07:37 PM
There aren't many cases where browser-detection should be used, but where it is perfectly logical to use them, a browser with a faked user-agent will most likely FAIL on them, and that's why browsers that fake the user-agent should not be used.
rpgfan3233
02-26-2009, 09:03 PM
There aren't many cases where browser-detection should be used, but where it is perfectly logical to use them, a browser with a faked user-agent will most likely FAIL on them, and that's why browsers that fake the user-agent should not be used.
The fact is that some sites are designed for a specific browser. Some of those sites offer the same content to other browsers, reducing functionality in those browsers. Faking the user-agent string when a certain other browser supports the same functionality as the browser a page is designed for, it's all right to do so. After all, why would you want to be forced to use IE, for example, when your primary browser is Firefox, and that same page works just as well in Firefox as it does in IE. The page was simply designed when Firefox didn't support a certain functionality that IE did. You may not be able to change the behaviour of the page, but you can at least change your UA string to make it work.
As a result, browser sniffing is unreliable. You should check for functionality, not for browsers. After all, what Firefox 3.0 supports isn't the same as what Firefox 1.0 supports. And there are browsers like K-Meleon that would support what Firefox 2.x supports, but your UA filter might not consider that.
IE has conditional comments, which make things easier, but why would you rewrite the same script over and over? Filtering IE versions to check whether you should use document.all or document.getElementById for IE isn't exactly ideal either. Seriously, check functionality, not for browsers.
TheTeenScripter
02-26-2009, 09:24 PM
The fact is that some sites are designed for a specific browser. Some of those sites offer the same content to other browsers, reducing functionality in those browsers. Faking the user-agent string when a certain other browser supports the same functionality as the browser a page is designed for, it's all right to do so. After all, why would you want to be forced to use IE, for example, when your primary browser is Firefox, and that same page works just as well in Firefox as it does in IE. The page was simply designed when Firefox didn't support a certain functionality that IE did. You may not be able to change the behaviour of the page, but you can at least change your UA string to make it work.
As a result, browser sniffing is unreliable. You should check for functionality, not for browsers. After all, what Firefox 3.0 supports isn't the same as what Firefox 1.0 supports. And there are browsers like K-Meleon that would support what Firefox 2.x supports, but your UA filter might not consider that.
IE has conditional comments, which make things easier, but why would you rewrite the same script over and over? Filtering IE versions to check whether you should use document.all or document.getElementById for IE isn't exactly ideal either. Seriously, check functionality, not for browsers.
As i already said, check for functionality where possible. Check for browser-type for HTML/GUI (and depending on the situation, CSS maybe).
All i was saying about the faking of the user-agent being bad is that if there was a page (let's say an optional template) designed for specific browsers (let's say Firefox/Internet Explorer) and all other browsers get a W3C-Compatible page, and a browser comes along and fakes itself as Internet Explorer/Firefox but it maybe displays the page differently or doesn't support the same functions, and it completely messes it up!! Well if the browser didn't fake it's agent, it would have gotten the W3C page and therefore would have displayed perfectly fine, and would have performed exactly as coded. A fake agent makes the page display how the webmaster chose not to.
TheTeenScripter
02-26-2009, 09:28 PM
Basically if the agent doesn't get faked, the pages display as they should. If the agent does get faked, the pages risk getting messed up. Most pages don't check for the user agent, and those that do usually do it for a good reason (or the webmaster has limited knowledge on how to build cross-browser). Browsers should never have to compensate for the limitations of the coders.
Jeff Mott
02-26-2009, 11:06 PM
I don't think browser sniffing is nearly as terrible as most here make it out to be. In fact, I don't think it's terrible at all.
Yes, a user can fake the user agent string. But so what? If a user wants to sabotage their own browsing experience, there's nothing you can do to stop him. I can visit your site and issue JavaScript commands in the address bar. Are you responsible for that? Of course not. And nor are you responsible for the user sending fake headers.
Plus, the vast majority don't send fake headers. Even though the headers may be wrong, most of the time, browser sniffing will give you the correct result.
Feature sensing is preferred if you can use it, but it can't solve every problem. A feature may exist but return buggy results, or you may need to distinguish between the rendering engine rather than JavaScript interpreters. (I once needed to distinguish between FF2 and FF3.)
Bottom line: Feature sensing is slightly better, so use it if you can. But if not, browser sniffing works just fine too.
TheTeenScripter
02-26-2009, 11:30 PM
I don't think browser sniffing is nearly as terrible as most here make it out to be. In fact, I don't think it's terrible at all.
Yes, a user can fake the user agent string. But so what? If a user wants to sabotage their own browsing experience, there's nothing you can do to stop him. I can visit your site and issue JavaScript commands in the address bar. Are you responsible for that? Of course not. And nor are you responsible for the user sending fake headers.
Plus, the vast majority don't send fake headers. Even though the headers may be wrong, most of the time, browser sniffing will give you the correct result.
Feature sensing is preferred if you can use it, but it can't solve every problem. A feature may exist but return buggy results, or you may need to distinguish between the rendering engine rather than JavaScript interpreters. (I once needed to distinguish between FF2 and FF3.)
Bottom line: Feature sensing is slightly better, so use it if you can. But if not, browser sniffing works just fine too.
Exactly my point.. Only, for those browsers that automatically fake the agent, they are sabotaging their users experiences for them, as well as probably giving false statistics for those sites that keep track of what browsers visit them... I mean sure use the object-detection if possible, but sometimes it is necessary (or more efficient) to just use classic browser-sniffing from the user-agent.
Charles
02-27-2009, 08:50 AM
There are, however, like a billion different browsers out there. Which ones are you going to sniff for? MSIE? Firefox? Opera? I think the we can ignore Mac and Linux versions as insignificant.
It's a philosophical, and marketing, difference. If you are sniffing for browsers then it all comes down to who has the greatest market share. Sniffing for capabilities opens up the playing field and encourages browsers to follow the rules. I don't need to tell you which one Microsoft would prefer that you to be using.
Or put another way, sniffing for browsers is kind of like applying the sniff test in search of clean underware. It might get the job done but there is a lot of unpleasantness along the way.
Declan1991
02-27-2009, 09:44 AM
Also, I didn't say they aren't worth downloading, I said they PROBABLY aren't worth downloading (because everyone has their own preference).
Sorry.
Browser-sniffing (except conditional comments and the like), just means using proprietary code. If it were the case that all Firefox 3 instances irrespective of OS worked the same all the time, and Firefox and IE were the only popular browsers, I could condone browser-sniffing when feature sniffing isn't straight-forward. That is not the case. Identifying the browser are Firefox 3 doesn't guarantee anything. Yes, it'll mean that the browser is Firefox 3 the vast majority of times, but unless you are going to check the page for every new edition of the browser that is released for evermore, it guarantees nothing, nothing at all. It also reduces functionality to other browsers possibly unnecessarily. As webdevelopers, the aim has to be to provide the best possible experience to the widest possible audience, irrespective of equipment used. By browser-sniffing, you limit the experience for those that don't use the newest, most popular browsers. They get a W3C compliant page, great, but it's quite possible that they also could support what Firefox can, you don't even give them that chance.
There are two levels of browser-sniffing, the only-use-IE browser-sniff, and the more intelligent, very advanced browser-sniff. The first is obviously wrong, but I'm sure we are all agreed on that, and I want to point out that faked user-agent strings are vital to avoid such sites, which is why they can't be condemned. The second is a trickier issue, and I presume that's where we disagree. I believe that's wrong, and limits choice, which I abhor. I do understand your argument, I just think it's misguided.
Jeff Mott
02-27-2009, 01:48 PM
There are, however, like a billion different browsers out there. Which ones are you going to sniff for?
You ask like this was meant to be a rhetorical question, but the answer is very simple and straightforward.
A-Grade Browser Support Chart (http://developer.yahoo.com/yui/articles/gbs/#gbschart)
I find it funny how easily people distort the truth when trying to sell the anti-sniffing idea. Billions of browsers? There are about 1.5 billion Internet users. Would you have us think there are more browsers than people on the Internet?
Browser-sniffing (except conditional comments and the like), just means using proprietary code.I'm tired of people misusing "proprietary." I'm starting to believe that the majority of developers have no idea what it means. "Prorietary" means privately held with exclusive rights. It's the opposite of free (as in freedom) software.
Browser-sniffing, the idea, isn't copyrighted, so it certainly isn't proprietary. And the actual code to do it is freely available on the Internet, so that also isn't proprietary.
As webdevelopers, the aim has to be to provide the best possible experience to the widest possible audience, irrespective of equipment used.There are limits. Every developer acknowledges those limits. Do you still check your pages in Netscape 4. How about IE 4? How about all the other "billions" of browsers? So we limit ourselves to a certain set of browsers and browser versions. And yes, we are updating this list "evermore."
There are other limits we don't concern ourselves with. I could adjust my FF settings to always render in quirks mode even with a correct doctype. Now your page doesn't work correctly on my equipment. Yes, the doctype means the browser will be in standards mode the vast majority of the time, but it guarantees nothing. Nothing at all. (Does that argument sound familiar?) ;)
Charles
02-27-2009, 02:10 PM
You ask like this was meant to be a rhetorical question, but the answer is very simple and straightforward.
A-Grade Browser Support Chart (http://developer.yahoo.com/yui/articles/gbs/#gbschart)Some years back some guy was keeping a list of different browsers available. The list was about 300 when he gave up. That list of 35 is no less arbitrary than those who would say worry only about MSIE.
Jeff Mott
02-27-2009, 02:31 PM
That list of 35 is no less arbitrary than those who would say worry only about MSIE.
:rolleyes:
TheTeenScripter
02-27-2009, 03:52 PM
The only reason browser-detection should really ever be used is either:
A) To provide a better user-experience based on common browser-types, or to have a better way of accomplishing a task with said browser(s), ie. more integrated look, easier navigation, speed, without having to worry about how your website will perform with all browsers
B) To log statistics to see what browsers the users are using
Basically only use browser-detection if what you need to do is specific only to that browser type, but not just the objects. If the objects are involved, use object-detection. If several different browser-specific objects are involved, either could be utilized.
Declan1991
02-27-2009, 04:12 PM
I'm tired of people misusing "proprietary." I'm starting to believe that the majority of developers have no idea what it means. "Prorietary" means privately held with exclusive rights. It's the opposite of free (as in freedom) software.
Browser-sniffing, the idea, isn't copyrighted, so it certainly isn't proprietary. And the actual code to do it is freely available on the Internet, so that also isn't proprietary.
You misunderstand the point but as it happens I did misuse the term for some cases. The point was, especially for IE, that browser-sniffing is only needed to allow code that is restricted to one particular something or other to run.
TheTeenScripter
02-27-2009, 06:03 PM
You misunderstand the point but as it happens I did misuse the term for some cases. The point was, especially for IE, that browser-sniffing is only needed to allow code that is restricted to one particular something or other to run.
do you get points for pointing out the obvious, yet being vague at the same time?
Declan1991
02-28-2009, 09:13 AM
do you get points for pointing out the obvious, yet being vague at the same time?
Browser-sniffing is needed to allow code that can only run in one particular browser, while allowing the rest not to fail. That is particularly prevalent in the type of browser-sniffing we all abhor. Is that better?
TheTeenScripter
02-28-2009, 02:50 PM
Browser-sniffing is needed to allow code that can only run in one particular browser, while allowing the rest not to fail. That is particularly prevalent in the type of browser-sniffing we all abhor. Is that better?
Two corrections here: Browser-sniffing could be used to check for multiple browsers, not only limited to one. Second correction, I don't abhor browser-sniffing, as it does allow more to be done without being constricted to "standards-compliant" html, but still offers the ability to code "standards-compliant" html for those browsers that do not support the added functionality.
Jeff Mott
02-28-2009, 04:00 PM
Browser-sniffing is needed to allow code that can only run in one particular browser, while allowing the rest not to fail.What makes you think we would allow other browsers to fail? What kind of screwy assumption is that? We use it to provide an alternative for browsers that are either buggy or simply behave differently.
toicontien
03-03-2009, 09:12 AM
There are thousands of user agent strings out there. What happens when you sniff the user agent string, and somebody releases a new browser with a new user agent string. I've seen this creep up from time to time as Safari was released (way back when) and now that Chrome has been released. The insane part is browser sniffing was used to detect specific browsers which then run standard code!
The combination of object detection, conditional comments, and the try-catch block (http://fundamentaldisaster.blogspot.com/2008/10/cross-browser-javascript-creating-dom.html) used efficiently has rendered browser sniffing obsolete, not morally wrong.
We have better, more exacting tools available. Nobody wants to do heart surgery with a cleaver when we have perfectly good scalpels available.
Jeff Mott
03-03-2009, 12:10 PM
What happens when you sniff the user agent string, and somebody releases a new browser with a new user agent string.If that new browser runs standards-compliant code correctly, then there won't be any problem. But if it has browser-specific bugs, then we'll have to write browser-specific workarounds -- all of us, whether sniffing or detecting.
... has rendered browser sniffing obsoleteThe last time there was a long thread about sniffing, I described a specific case where sniffing was the only option. I even provided code. No one could fix it without sniffing, but still no one would acknowledge its necessity. People were more worried about being right than checking the facts.
The fact is: sniffing is not obsolete. Nor is it even an inherently bad option.
TheTeenScripter said it best. If we need to work around the non-existence of an object, then use object detection. But if you need to target a specific browser and version for a reason unrelated to JavaScript objects, then sniffing is exactly what you should do.
toicontien
03-03-2009, 12:54 PM
Just out of blind curiosity, when would a try-catch block be insufficient for getting around browser specific problems? To be honest, I haven't found a case where browser sniffing was the only way to sort out of bug -- not that such a case doesn't exist. Might be a good note for the future. :)
Jeff Mott
03-03-2009, 01:18 PM
when would a try-catch block be insufficient for getting around browser specific problems?Try-catch blocks are useful only when the browser will throw an error. So try-catch in insufficient for every other case.
As has been said, sniffing is needed when the browser differences are not related to JavaScript objects. More specifically and for example: page rendering. Obviously there are rendering differences between IE6, IE7, and other browsers, and we've solved those with conditional comments. But what if there's a rendering quirk in Safari? What if there's a rendering quirk in Chrome? What if there's a rendering difference between FF2 and FF3? We need to identify these browsers to deliver browser-specific fixes, and object detection is inappropriate because neither the problem nor the solution is related to JavaScript objects.
toicontien
03-03-2009, 01:51 PM
Try-catch blocks are useful only when the browser will throw an error. So try-catch in insufficient for every other case.
As has been said, sniffing is needed when the browser differences are not related to JavaScript objects. More specifically and for example: page rendering. Obviously there are rendering differences between IE6, IE7, and other browsers, and we've solved those with conditional comments. But what if there's a rendering quirk in Safari? What if there's a rendering quirk in Chrome? What if there's a rendering difference between FF2 and FF3? We need to identify these browsers to deliver browser-specific fixes, and object detection is inappropriate because neither the problem nor the solution is related to JavaScript objects.
That's a possibility. In fact right off hand I can think of one case where browser sniffing is needed -- and in retrospect the only case I can think of -- and that's when positioning a tooltip by the mouse cursor. Each browser gives slightly different X,Y coordinates for the mouse cursor position, which may even be different depending on the operating system.
In that case, yes. Browser sniffing is needed, or you could just live with the appearance issues. A more accurate argument is to use object detection first, and if that doesn't work, use a try-catch block if the browser encounters an error. Finally, if there is simply no way you can detect the difference, and the difference is a show stopper, use a browser sniffing script.
For 99.9999999999999999999% of the cases, browser sniffing is not recommended.
Jeff Mott
03-03-2009, 02:08 PM
A more accurate argument is to use object detection first, and if that doesn't work, use a try-catch block if the browser encounters an error. Finally, if there is simply no way you can detect the difference, and the difference is a show stopper, use a browser sniffing script.
And that's what I recommended in my very first post in this thread:
Bottom line: Feature sensing is slightly better, so use it if you can. But if not, browser sniffing works just fine too.
It's nice to see we've come full circle. ;)
For 99.9999999999999999999% of the cases, browser sniffing is not recommended.Barring the obvious exaggeration, that's absolutely right. The difference is I don't vilify browser sniffing. It's still a tool in my toolbox, and I'm not afraid to use it when appropriate.
toicontien
03-03-2009, 02:15 PM
And that's what I recommended in my very first post in this thread:
It's nice to see we've come full circle. ;)
If there's one thing I despise about programmers it's that we get stuck in our ways. :)
Barring the obvious exaggeration, that's absolutely right. The difference is I don't vilify browser sniffing. It's still a tool in my toolbox, and I'm not afraid to use it when appropriate.
And that's another great point novice and intermediate programmers should take note of. It's a tool in my toolbox. A carpenter wouldn't use a hammer to put in a screw. Use the tool that's right for the job, because completing the job is your focus, not using your favorite tools.
Jeff Mott
03-03-2009, 02:33 PM
Use the tool that's right for the job, because completing the job is your focus, not using your favorite tools.
Of course. My dispute is with people who treat browser sniffing like it's evil, and especially those who create a double standard or who make untrue statements to justify their conclusion.
toicontien
03-03-2009, 02:41 PM
Yup, and those are the people who focus on using the tools they like, not completing projects. :D
felgall
03-03-2009, 02:54 PM
99.9% of the time feature sensing to detect whether the browser supports the code will work and is 100000000% more accurate than browser sniffing.
At least some of the rest of the time JScript conditional comments within the JavaScript/JScript code itself will allow you to handle exceptions for IE without looking at the useragent at all.
You can assume that almost all browsers except IE and Firefox will have their useragent set most of the time to report the browser as being either IE or Firefox regardless of whether your code will work with them or not simply because most code where browser sniffing is used the code actually works for most of the browsers it would normally exclude if the USER agent correctly reported which of the many thousands of browsers it actually was. Also the next version of whatever browsers don't work probably will work and then your browser sniff is wrong. It isn't so much that browser sniffing is necessarily wrong, it is just that 99.999% of the time there is a more accurate way of testing.
The one instance where browser sniffing is appropriate is capturing statistics where you are only interested in the major browsers and the small percentage of browsers identifying themselves as a different browser will not significantly affect the result. Since in most cases you will need to store the results to be able to make any sense from this the browser sniffing in that case will be better done server side rather than in JavaScript.
I have seen lots of sites that use browser sniffing incorrectly where the site ends up not working as a result of their using that in place of much shorter, simpler and more accurate code that would achieve what they are attempting unsuccessfully to achieve.
Since the main use for browser sniffing is statistics, the main reason for changing your user agent (other than to try to bypass the many crappy browser sniffing scripts that don't work correctly) is to be able to separate out your own visits to your web pages so as to not distort the stats you are capturing due to your visiting your site a lot more frequently than any of your visitors.
If you are going to use browser sniffing then you should set it up to only exclude specific browsers that you know your code doesn't work for so that any useragent you don't test for where your code probably does work will be able to run it (that's assuming you are writing code to the standards and not trying to use proprietary code that only some browsers understand to start with - in which case feature sensing is a better way of hadling that).
Jeff Mott
03-03-2009, 07:09 PM
99.9% of the time feature sensing to detect whether the browser supports the code will work and is 100000000% more accurate than browser sniffing.felgall, you have a bad habit of pulling numbers out of thin air and passing them off as fact. Those numbers you claim are made-up and meaningless.
At least some of the rest of the time JScript conditional comments within the JavaScript/JScript code itself will allow you to handle exceptions for IE without looking at the useragent at all.I described several cases where sniffing is needed, none of which is solved by JScript or conditional comments.
You can assume that almost all browsers except IE and Firefox will have their useragent set most of the time to report the browser as being either IE or FirefoxNo assumptions are needed. Safari, Opera and Chrome all report their name and version, and can be uniquely identified.
Also the next version of whatever browsers don't work probably will work and then your browser sniff is wrong.Sniffers can and do detect the browser version. So, again, no real problem here.
it is just that 99.999% of the time there is a more accurate way of testing.More made-up numbers. But ignoring that part, the rest isn't anything that hasn't already been said and agreed upon -- that feature detection is preferred if applicable.
The one instance where browser sniffing is appropriate is capturing statisticsThere are many more instances. I've described them for you, and in past threads I've even provided you with code. I don't know what you expect to prove by ignoring everything that contradicts your preferred conclusion.
If you are going to use browser sniffing then you should set it up to only exclude specific browsers...Thanks for the recommendation, but I'll do nothing of the sort. I don't use sniffing to exclude any browser. I use it to include more browsers that would otherwise render incorrectly. I'd explain in more detail, but you've repeatedly shown that you will only turn a blind eye to anything contradicting what you want to believe, and I choose not to waste any more time with you.
webdeveloper.com
Copyright Internet.com Inc., All Rights Reserved.