In the comments of a recent article discussing conditional comments someone mentioned that they prefer to use PHP to detect which browser (user agent) and/or operating system is in use, then they display a custom class for the <body> tag and target the browser accordingly in their CSS.
I’ve known for some time now that this is wrong. I was told that a user agent can be faked, so the people I’ve worked with discouraged this method, and I’ve never used it.
In no way am I an expert in this particular area, so I’m not claiming here to be able to fully explain exactly why we shouldn’t do this, but a little bit of quick research on this topic shows that server-side browser detection is not a good idea.
I’m not going to drag each of these points on (mostly because I don’t have the technical expertise in this area), but instead I’m just going to provide brief quotes and links that discourage the use of this method and provide further insight into the matter.
It Can be Done with HTML and CSS
This is the main reason that you shouldn’t use server-side logic for browser detection. Anytime you can deal with a client-side, presentational issue using pure client-side, presentational code, then you should do so. (UPDATE: Thanks to Jacob Gube for pointing out that this really should be the first reason listed.)
Making Code Harder to Maintain
The argument here is that by using server-side logic to affect the presentational layer, you’re unnecessarily creating less maintainable code.
This quote from a post on SitePoint forums sums it up best:
I don’t see why you would intentionally mix the presentation layer with server-side logic and hide away your fix in a non-standard way. For example… Possibly years down the line when you have left the employ of your client they wish to restyle the application and hire a designer to alter the CSS to suit. Why in the world would they look in the PHP source for this magical function of yours that is no longer relevant?
Faking the User Agent
I’ve already mentioned this one, but here is another quote from someone on SitePoint Forums regarding this issue:
I could easily have all the browsers on my computer set up so that the only one that doesn’t contain MSIE in the useragent field is Internet Explorer – if I did that then your code would break in all browsers. Don’t rely on a free format user controlled value that someone might change.
Also, there’s a website called AppTools.com that offers PHP scripts. They’ve removed an older PHP script that detected the user agent. Here is how the page sums up their reasons for removing the script:
Browser detection is an illusive task that is ultimately doomed to fail. Browsers are always changing and keeping up to date with these changes is a continuous job. Some browsers allow the user to alter the way the browser identifies itself, or to not identify itself at all. Some firewalls block the sending of the browser identification, so no browser detection scheme is entirely successful.
Dealing With the Complex User Agent String
Some responses on Stack Overflow about server-side browser detection show how complex this method can be, and how many issues you need to deal with when trying to detect the user agent. Here is a notable quote from one user:
Browser-sniffing on the server side is a losing game. Apart from all the issues of trying to parse the UA string, the browsers that lie, the obscure browsers, and the possibility the header isn’t there at all, if you return different page content for a different browser you must set the Vary header to include User-Agent, otherwise caching proxies may return the wrong version of the page to the wrong browser.
And if you get a chance, please read this hilarious article by Aaron Andersen that documents the history of the user agent string.
Anything to Add?
I think the basic reasons not to use server-side browser detection are covered above. If anyone has any further information, or wants to correct anything I’ve said or quoted here, please do so in the comments.
Like I said, I’m not an expert in this area, but I thought it would be important to point out the weaknesses in this method, and encourage developers to avoid this poor method for serving browser-targeted CSS to the client.
Although I neither agree, nor disagree with this, I do have 2 points to make.
1. “a user agent can be faked” – If someone has the knowledge/ability/desire to fake their user agent then they probably understand why some sites don’t display properly. Since nothing “site critical” is handled by css/styling (i.e. security or login credentials) it’s not as big a deal its been made out to be, from this perspective.
2. “It Can be Done with HTML and CSS” – To a certain extent, yes. I’m finding IPhones/pods do not respect standardized css rules. If you have a handheld stylesheet they read both. I’m considering using php to detect if the device is mobile and then inserting the correct stylesheet to prevent this but I haven’t decided if that’s the root I want to go.
I’m sure the author, and most readers, will disagree but that’s my $0.02
For point #2, if you’re concerned only about the Apple mobile devices and Android devices, use media queries (since their built-in browsers, which use WebKit, supports CSS3 media queries).
I agree with #1 — if you take the trouble to spoof your HTTP request headers, you’ll certainly have a much easier time to work around CSS/HTML/JS detection (simple greasemonkey script will do the trick).
Using a server-side technology does seem a bit heavy handed for browser sniffing. That being said, I include http://rafael.adm.br/css_browser_selector/ in every project. This allows me to ‘tweak’ things across that need to be pixel perfect but may be off by 1-2 pixels.
I entirely agree with what SL said.
I think that php browser detection is needed only when you need to perform advanced tasks like redirecting all visitors using IE 6 to another page.
From my own experience, the best way to change the stylesheet – and works only for IE – is
<!--[if IE 6]>
Special instructions for IE 6 here
<![endif]-->
Firstly, I load the default stylesheet for all browsers, then I load the one specific for IE6, or IE7 which overrides the css values from the default stylesheet.
Yes, user agents can be faked. But so can other aspects of a browser such as whether they can support javascript support or ip/geo location.
Once we are cool with this fact, we must then ask, why would/have we needed to determin aspects of a users setup in the first instance. Usually, the answer to this is to tailor content to best suite the user … afterall, the customer is still always right and a happy customer is good business.
The biggest problem with this conditional trend, is that it generally requires amounts of wasted content to be cached to the user, to then be considered appropriate or not for the user AFTER they have been forced to cache it. This isn’t right to me.
As content becomes richer and richer, larger and larger, can you honestly see broadband going the same way (at least not at the same rate)!? Unlimited broadband rocked several year ago for peansuts … but then everyone wanted it and now we’ve gone back in time to capping and liscencing restrictions. And let us not mention those big corporations that want ISPs to reserve the fasteer internet experience for premium subscribers …
In short, what I am saying is that conditional statements are themselves, not perfect. Sometimes a concept can be so attractive, that we still lose sight of the larger picture.
Yes, we want our code to be easy to maintain, but sometimes content simply is not right for the various users it needs to target. A mobile phone user on a train who quickly needs to see a timetable for his train should not need to cache a document that is also written for a Full HD dual screen who also likes purchasing novels that he sees advertised on these pages, along with several other timetables for comparative reasons.
I think you meant “Don’t use PHP browser detection *for CSS*.” When I read the title, it seemed as if you’re saying not to use PHP browser detection at all. If you can spoof user agents server-side, that’s 10x easier when you’re relying on client-side detection (heck, just disabling JS and CSS in your browser and you won’t be able to detect it).
In fact, this is why JS-based analytics like Google Analytics isn’t going to be as accurate when compared to server-side analytics apps. It’s much easier to trick client-side browser detection versus server-side detection.
If you’re browser-sniffing for data (e.g. an app that tracks how many IE users versus Firefox users visit your site) — you should definitely use PHP over other browser-sniffing devices. Yes it’s not 100% bullet-proof, but nothing is; it will still be more accurate than relying on client-side technologies which are controlled by users.
But, I will agree with not using PHP over CSS/HTML (e.g. media queries, conditional comments) if you’re browser sniffing for visual purposes; it seems overkill and just seems like you’re using the wrong tool for the job.
Hm, this is a little confusing to me, because I don’t see the difference between what I said and what you said.
Isn’t it true that when you use PHP to detect the browser, you’re using PHP to access a client-side variable to find out what browser is being used? So, if that’s the case, then doesn’t that mean the method still suffers from the same problems I summarized (except maybe the maintainability part)?
What I’m saying is the argument against spoofing user agents is invalid if the alternative you are suggesting is client-side (conditional comments).
Harder to maintain and using PHP for something HTML should do — OK.
But the argument against PHP in this particular instance with spoofing is invalid because the alternative is much easier to spoof. It’s an irrelevant reason in this particular instance.
Oh, Jacob! You just love pointing out my logical fallacies! :)
Yes, you might be right about that, assuming of course that conditional comments get their information from the UA string. Is this the case?
I tried to find out how CCs work, but there doesn’t seem to be any technical info on the subject anywhere that describes where CCs get the browser version from. SitePoint’s reference says that using CCs is a “safe” method; this is not normally an expression used for something that can easily fail, as we know is the case with the user agent string.
So, I don’t know what to conclude. I can’t say I agree with you unless you can show me evidence that a conditional comment can fail in the same way that PHP browser detection can fail.
It should also be noted here that conditional comments are used to display custom markup, CSS, and JS.
So, while it’s true that disabling CSS and JS will make the user agent unavailable, it doesn’t matter anyhow, since those technologies are what you’re targeting with the CC.
And just to add: the only reason that’s hard to refute is the last reason, which you ironically put last (I dunno, maybe I just like the inverted pyramid triangle too much, so that I assume the things at the top is more important than things at the bottom — but you did say it’s the “main reason”).
PHP is harder to maintain (with regards to browser detection) is a case-by-case basis as well as a preference of the developer and their client. If you write your app modularly, it would be the same effort or even less effort than taking out a conditional comment reference.
Absolutely, I should have put that first. In fact, I’m going to move it to the top right now. I think I just rushed a bit to put this out. :)
Whoa, I didn’t expect you to do that, now I feel bad for making you put in extra work.
“(…) it will still be more accurate than relying on client-side technologies which are controlled by users.”
Server-side detection also relies on data provided by the user, so there is no difference in accuracy and reliability between server side and client side detection.
Client-side detection is what you should use if the problem you are trying to solve is layout. If it’s for statistics, server-side scripts might be a better solution.
Nice Blog and good information!
I think this is not a great idea on a large scale public site; but on a private application this type of check can be helpful.
As I understand it, both PHP- and JS-based UA detection ask the browser, “Who are you?” The JavaScript version is easier for users to spoof, but faking out the PHP version isn’t too terribly difficult either. The reason that most stats tools, server- or client-side, work at all is that the vast majority of users don’t bother to change their user agent strings or variables.
Conditional comments are an entirely different animal. They are, as part of the name implies, comments, so they are ignored in the vast majority of cases. The special cases where they are used are when different versions of Internet Explorer (and any tool trying to emulate Internet Explorer) ask the page, “Do you have anything special for me?” Having the browser look for extra information in the page is much different than having the server or scripts ask the browser to identify itself. Like some of the previous comments stated, however, having too many conditional comments to restructure your app or page for IE gets messy really quickly, which is why conditional comments are usually best used for CSS and JS targeted at different versions of Internet Explorer.
Hopefully that helps someone.
Thanks, Mike.
So, according to your explanation here, is it possible for the user to make the comment think IE is being targetted? The answer would seem to be “no”, because the UA string is not in use here; the method is inherent in the browser’s rendering engine, which can’t be faked.
So, I think my initial statement in the article that the faking of the UA string is a reason not to use PHP detection is still valid, even though Jacob (in an above comment) seemed to suggest that it was irrelevant where UA string faking was concerned.
Maybe I’m still wrong about this, but it seems to me that if the UA string cannot affect the CC, then CCs are a more reliable method.
AFAIK, you can’t tell Internet Explorer to not use conditional comments; I also don’t know how you would use conditional comments without actually using the IE rendering engine. This makes conditional comments highly reliable for targeting Internet Explorer.
To weigh in on PHP browser detection, it depends. If you are trying to target Internet Explorer, then conditional comments are the way to go as far as CSS and JS are concerned. For everything else (detecting non-IE browsers or changing the HTML depending on browser), server side (PHP) browser detection is really about the best you can do, especially when you weigh ease of maintenance against reliability (conditional comments can be used to serve IE different HTML, but they’re a royal pain to use for this purpose).
That being said, you shouldn’t have to write (much) unique HTML, CSS, or JS for any browser besides IE–almost everything works in every browser except IE. There are exceptions, but most of the time I don’t find myself having to write much special code of any sort to target Chrome or Safari or Opera or Firefox. Some of the new CSS3 that’s out there does require some vendor-specific selectors, but that’s about it.
Oops, forgot to say something about mobile systems. They aren’t running Internet Explorer, so conditional comments don’t work on them. Create a mobile version of your site if you can, otherwise @media targeting is a decent way to go for CSS.
I see your logic here, actually. I mean you can use Greasemonkey for IE, do regexp for conditional comments in the markup, but that just manipulates the DOM; I wonder if the browser still grabs the stylesheet, though.
And even if you do that, why would you (as an end-user)? Probably to lower your risk of a CSS parser vulnerability specific to IE? That sounds to paranoid, low-risk to put yourself to all that trouble (especially since a greasemonkey script parsing markup for conditional comments will slow down page response times of ALL web pages you visit).
There are a lot of questions in this comment thread I’d love answered.
Great article!
We are also not taking into account that older browsers cannot be detected using techniques such as this, that require new browsers to actually execute the techniques. So complete exclusion of backwards-compatible techniques such as server-side php is only forward-thinking … true accessibility to content is about looking both forward and backwards, surely!?
Although I agree with making a site robust enough to not need browser sniffing. I do use php browser sniffing to drop out the 2 or 3 bits of css used to patch up the EI7 margin bugs, I think I just don’t like this bit of untidiness going out if it doesn’t need to.
IMO you should never use any server-side language to do browser detection (I really hate the *.browser files in .NET and the browscap.ini in PHP) server-side business logic should never be mixed with client-side presentation . If anything, you should avoid browser detection altogether, both server-side and client-side. Use feature detection instead whenever applicable and possible.
I’m for feature detection, but putting it in html still moves us away from seperating content from markup and design. Yes HTML and CSS is a step in the right direction in achieving this, but it still fails to keep markup away from content where as server-side methods were (and are) already doing this.
That is why the fad of HTML5 and CSS3 needs to pass us by soon as possible, so that we can get on and do it properly before we go through the whole waste of time that was spent building websites in HTML4 tables. Bring on iHTML and real UI detection methods.
The way I use feature detection is in a separate .js file and rewrite modify the DOM as needed. This keeps my HTML files semantic and allows for a good separation between markup and presentation. In ideal situations it allows me to serve up proper semantic HTML to capable browsers and keeps the hacks out of my CSS. But of course in the real world this is not always possible.
I agree with your method of implementation, but feature detection often requires so much more code to be cached client-side than is required via browser detection. Also keep in mind that older browsers have proven to be more reliable to detect (the benefit of not updating to the new and unknown) … it is the newer browsers that we need to be wary of, with all the different standards and agendas being established that are causing all the uncertainty.
The new playing field is not yet known … it is therefore not reliable. We can however, hope, but trends in technology have never failed to let us down … think HTML4 table design, javascript popup windows and status bar messages, CSS hacks and HTML emails.
Oh … and don’t forget WAP. How much time and money was spent on that, to then be made obsolete by mobile development as we know it. We designers and developers always get screwed … but the consumer has not really noticed that anything has changed but the speed of their internet.
Here is where I would love to see some examples on feature detection to determine if the user is using a browser; and even more what browser they are using.
My humble opinion:
I personally start, both on business logic and layout, by coding respecting well known and assessed standards. Then, only for those browser that really don’t adhere to standards (older IE and some other browsers) I use server side browser detection to link add-on CSS and JS to correct these glitches.
I think that the really good thing about standards is that if you respect them and use them when they are widely supported, you’ll end up with something that works pretty well across any browser, present or future, and then you can spend some time for those bugs that plague those 2 or 3 bad browsers that are still used by many.
In this perspective, saying that browser detection is bad is nonsense: if I cannot detect a new browser, that is NOT a problem, because:
a)if it’s a known good browser, then perfectly standard code works flawlessly, and there’s no need to feed it with patches
b)if it’s a known BAD browser, but disguised as another, then this means the user has actively worked to disguise his browser, then he cannot blame the web designer for not detecting it!
c)if it’s an unknown newer browser, then I think it really SHOULD support correctly all the standards that were common at the time it has been born: if it doesn’t, then simply I will NOT spend time in supporting it.
The only exception to this last rule is IE, but that is because of its wide use is promoted by the Windows OS monopoly; in a really open browser market IE would fade out of sight rapidly… :)
So, my approach is to serve the common known bad browsers with patches for their glitches, and fully adhere to standards for everything else, and in that perspective, server side detection solves this without requiring unneeded bandwidth on the client.
The PHP way is far easier but for me isn’t the only. You can use also javascript, but with this way if the user is blocking javascript then it won’t work.
For me it relies on your user target. So you have to think what is best for your audience. PHP, Javascript, htaccess or HTML+CSS.
Thanks for the great post!
Whenever possible it is best to do it server-side as JavaScript is more often disabled than the user agent being faked. JavaScript must remain the last resort. You know do both, actually.
To summarize: detect with PHP, confirm with JS.
Here’s an example to my above statement: Grab UA with PHP, amend a class (OS + UA), grab it with JS and check by feature. Nearly fool proof.
Hey, Stefan.
Yes, you are correct, but I’m not suggesting doing browser detection with JavaScript. In 99% of cases (but don’t quote me on that — overgeneralizing here), the browser detection is to target IE and its versions. You can do that with Conditional Comments, so no PHP or JS necessary. However, see the comments above by Jacob Gube and a few others who brought up some possible issues of concern.
(PS – I combined your 3 comments into 1 since you seemed to want it as one)
Thanks Louis for combining my comments. If one doesn’t have to target for other legacy browsers (i.e. Firefox, Opera) than your post is entirely legit. I understand that most UA detection is targeted towards towards IE, inappropriately at that, but all legacy browsers have their issues. It just depends upon what scale we’re working with here. Say, if you have a corp. that has an intranet while employing 20,000 and yet refuses to push a policy to upgrade– well, what then? Perhaps in this instance my suggestion still stands.
Yeah, you might be right.
That’s the quirky thing about this industry: There’s so many areas where there really is no right or wrong answer. The answer is inevitably: “It depends on…”
Well, at least I hope I contributed towards others by my suggestion(s). Thank you, Louis.
As Jacob said above, “I think you meant ‘Don’t use PHP browser detection *for CSS*.'”, ans i’m totally agree with. Browser sniffing is not only dedicated to css rules. A simple example is browser detection for html5 video tag support. With php, you can reduce user agent string to it’s simplest expression (ie Safari, version 3xx). Iif browser supports codec and
<video>tag, you can embed the video with html5, or a flash player if browser doesn’t support it. Even if user-agent is faked, the video is displaying. An other way to do this is to user javascript, but to my opinion i should first control my application behavior from server side, not only client side. Browser detection is also used for session storage…etc etc.To generalize the browser detection to css it’s to reduce web apps to it’s design part.
Thanks for explaining. Now i get a better understanding about browser detection. Gonna research more on this :)
A normal user does not know what a user agent is – so why do you care about the 0.1% that will fake it? Detection via PHP is saver than JS cause that can be disabled.
I totally disagree with this article, because CC are useless to detect Opera, Chrome, different versions of Mozilla etc.
CSS hacks are invalid and not worth talking about…
So explain to me how i target only Firefox with just HTML and CSS? Conditional selectors only work in IE. The only way to do it is to interpret the User Agent string. Whether you use Javascript or PHP, it makes no difference, if you are writing an article, you should have at least mentioned Javascript once to state your alternative. How can you expect anyone to accept your “newly found” knowledge if you don’t offer a solution. When it comes down to it, if i want to target a specific browser that is not IE, i am **** out of luck according to you.
Rubbish article. Learn your ****.
Why would you need to target Firefox? For what reason? There’s no reason to do that. Firefox renders stuff just fine. You should only need to target IE6 or IE7, which you can do with Conditional comments.
If you need hacks and workarounds for FF, then you need to reevaluate your CSS and do it differently instead of targeting FF alone. I don’t think people should use PHP or JavaScript for browser detection. Both are bad choices.
So what about mobile device detection? How are you suggesting I target older smartphones with limited javascript support?
How about those phones that don’t support media queries?
Your article is basically saying for ie use conditional comments. Yeo that is fair enough but the title is misleading and the article even more wo
Well, that’s a pretty rare case you’re pointing out there, but it is a good example of something that might be an exception.
Nonetheless, in this post I did not really give my own opinion on the matter, but instead just quoted a number of external sources to compile the reasons that many advise against server-side browser detection.
I should have changed the title to indicate that I’m talking about CSS, so I’m actually going to do that now, seeing as this page continues to get SE traffic for certain keywords. Thanks.
Idiotic. There are legitimate uses for server-side browser detection. There are also legitimate uses for feature detection. This absolutism has to stop.
This idea of ‘rendering’ just fine doesn’t work for an art firm or a major corporation that insists pages be identical in all browsers.
I’ve been developing company website using alot of heavy JS (menus, clocks, galleries) and the Zend Framework (PHP, MVC) which work fine across most browsers and browser versions, except IE version < 7. Therefore, i have to use a different layout (which will load differet JS and CSS files) specifically for IE's sake.
I am a bit unconfortable with this arrangement, and would therefore like to hear you comments on my approach and suggestions for anything better.
Thanks
Just use a Conditional Comment to load the IE CSS/JS. You don’t need back-end programming to do that.
The only reason you would ever need PHP to do your browser detection is if you needed to target something like Firefox 2 or Safari 2. But those browsers are dead, so there’s no reason to do that.
In a perfect world you’d be right. Be careful of absolutes in this business.
I came across this page looking for a unit-tested browser detection class of some kind. My trouble is that I need 2 IE css files: One for all versions of IE, and one for just versions 7 and 8.
Conditional comments? Unfortunately not. It’s a best-practice to include this meta-tag:
meta http-equiv=”X-UA-Compatible” content=”IE=EmulateIE8″
This removes the “Compatibility Mode” button from the IE interface. That button, right beside the address bar, will probably break your page and render it inoperable if you’re developing to modern standards.
However, the existence of that, means that when IE9 is executing its conditional comments, it does so as if it’s version 8. (Or 7 if you chose IE=EmulateIE7).
Now here’s the trouble: IE9 in “EmulateIE8 mode” does not behave EXACTLY like IE8. So what do you do?
Moreover, even if I got rid of that Meta tag, IE9 will sometimes put ITSELF into compatibility mode. This will cause it to report itself as IE7 in the User Agent. The only clue they present is that the UA for IE9 emulating IE7 has Trident/5.0 whereas actual IE7 has Trident/4.0.
And all this, of course, is why many people loathe IE!
As a general rule-of-thumb, you’re right. Conditional comments used to load a CSS (Or in most cases, just applying a conditional to a block of CSS in y our main css file) should be your go-to method of handling IE. But for a truly well-rounded article, you should address some of these issues at the bottom. Keep up the good writing!
You definitely bring up some good points, Shane. I don’t think there is a perfect solution to the problem of forking code for different browsers, but conditional comments and a good understanding of CSS principles will help most developers avoid problems in 95% of cases.
Have a question.
I have a page with a header and textshadow applied to it. It’s actually is a multishadow, sort of this: text-shadow:0 10px 15px #5C5C5C, 0 1px 1px black, 0 0 1px black;
While in FF5 it looks just fine, in Chrome – it doesn’t. I’m not saying this one line is a dealbreaker – I coulda live with no shadow at all. But if there’s a bigger concern than my personal prefrences – what should i do?
Simply this: if FF and Chrome and all fully support one particular property and render it defferent – what should i do?
To me it seems there’s quite a few ways:
1. php (server-side) detection; best choice ‘coz js could be just disabled at client side.
this way i can add a browserChrome class to and the problem’s solved.
*Not sure if it’s “cpu-free”, i.e. if there’s a big performance downgrade on high-traffic sites
2. js detection (client side); best when you sure it’s on in browser and dont introduce any additional server cpu “penalties”
3. other old-school ways, including css hacks which in particlar gets more and more obsolete
So which one is better – not considering 3rd way? Based on your experience?
In a case like that, I wouldn’t have a problem with using PHP. It’s not crucial funcionality anyhow, so who cares if the detection is wrong?
But to be honest, I’d be surprised if Chrome and FF rendered shadows so differently so as to require such a solution.
What’s the point of faking the user-agent?
While I agree with not using PHP to delivering different CSS for layout, if you want to serve different content based on the brower type (really, device type) then the server needs to know the browser capabilities. A common example is a site with a responsive design that scales from iPhone sized to 1,600 pixels wide. You don’t really want to be sending images wider than the viewport of the mobile device to that device and rely on the browser to scale them down – you want to send the appropriately sized images to start with. Unless you have a beter option? This is something I struggle with frequently.
It doesn’t matter if you use php, javascript, or apacher server software to determine what browser user has and to have your app show pages and appropriate data accordingly. It all can be faked.
First, css can “NOT” detect browser support. It can detect whether you have mobile or monitor.
Second, javascript (and so php/Apache) all look at http headers to determine what is the user agent.
And http headers can be modified very easily just go to chrome web store and download HTTP headers modifier or something.
css works only when you need to know that whether its like a smartphone or computer.
Way late to the game, but there are times I DEFINITELY use it. This is pseudocode, btw…
stylesheet_path = with hi res parts images for backgrounds, etc.
if (user agent means small screen and don’t want to do hoops and loops to avoid sending big images){
…. use stylesheet low res path…
end if
now then, if I use a site on my phone, ipad, android, pad, old laptop, etc… and finally on my great big hd screen…
MOST of the css is exactly the same. Just not the big image files, even though I am the same user.
saving alot of bandwidth and keeping the css clean of all the hacks
IF …. someone needs to fake his Browser-ID, so be it. I am not concerned about crap on the screen when the user willingly disguises his “origin”. If it is sooo important to him (the user) to look like a PC Browser, he will get what he desires. Dot.