[thelist] PHP multiple style switcher

kasimir-k kasimir.k.lists at gmail.com
Fri Nov 23 15:28:16 CST 2007


DAVOUD TOHIDY scribeva in 23/11/2007 20:04:
> yes that is correct but why not? and if browser detection is going
> to happen client side like the one that I have in my portfolio:

To start with, as others have said, browser detection is not a good 
solution (most of the time*) because any result of such detection can 
not be trusted 100%.

> 1-what if somebody has disabled Javascript

Then javascript detection doesn't work - but it's ok, as it doesn't work 
anyway 100% even if javascript is enabled.

> 2-is there any browser detection method which does not
> involve javascript in client side?

With PHP, you have the browser's user agent string in superglobal 
$_SERVER['HTTP_USER_AGENT'] - just read it from there. But remember that 
it can not be trusted - a user who has changed their browsers UA string 
might get unsuitable styles.

And people actually do sometimes change the UA string - because of 
browser detections. E.g. there are sites requiring MSIE, even if say, 
Safari would work perfectly well - so Safari users change their UA 
string to look like IE's. Sometimes the entire UA string is removed for 
security or privacy reasons.

So if you end up doing browser detection even though you shouldn't, 
prepare at least for:
- no UA string at all
- false MSIE UA string
- bogus strings like "my browser is none of your business"

Especially if you do it server side, remember also that the UA string 
*is user input*, so handle it accordingly, sanitize etc.

The UA string is the only thing which allows server side browser 
detection - no other browser identifying data is sent in HTTP requests. 
Client side some javascript methods one could use to detect browser, 
e.g. detecting objects and properties that exist in only certain 
browsers. But these are no better than the UA string - which btw, can't 
be trusted :-)

.k

(*) I actually once encountered a situation where browser detection was 
the only option: Opera interprets the HTTP spec differently to others 
regarding caching (can't remember details now), and my ajax-thingy was 
getting stale results in Opera. Fortunately, as the broken functionality 
required javascript, I was able to test window.opera (not 
window.navigator.userAgent!).



More information about the thelist mailing list