Re: Identifying browsers

Unfortunately, the HTTP_USER_AGENT is not a good way to identify browsers, despite 99% of dot.com business sites that think they can. This is easily faked and could also change if the user is behind a proxy. If you really need to , you can try to match with m#Mozilla/4\.\d#, but do it with full understanding of mislabelled browser.

A better question to ask yourself is why you need to disable CSS for NS4 browser. Yes, I do know that NS4 (paricularly before 4.5) does have some CSS oddities, but a lot of them are a result of poor web page writting or or CSS set up. While it's outside the scope of PM, it might be helpful to know what CSS NS is choking on.

Dr. Michael K. Neylon - mneylon-pm@masemware.com || "You've left the lens cap of your mind on again, Pinky" - The Brain

Comment on Re: Identifying browsers Download Code

Replies are listed 'Best First'.
Re: Re: Identifying browsers by Corion (Patriarch) on Mar 30, 2001 at 18:07 UTC
I disagree - Netscape 4 is horribly broken when it comes to CSS : Netscape loses CSS information when you resize the window. Netscape has coupled JavaScript and CSS, you can't have CSS without allowing JavaScript. css.nu has a looong list of what other problems there are with CSS and Netscape 4. Of course, the solution is to either generate special pages for Netscape 4 or to go back to complete `.jpg` images together with imagemaps for the navigation or creating the pages alltogether in MacroMedia Flash, if you need pixel-exact layout. Other than that, I see no way to give people using broken tools fancy layout.	[reply]
Re: Re: Re: Identifying browsers by Masem (Monsignor) on Mar 30, 2001 at 19:04 UTC
When you get down to it, no browser has good CSS 1 support, much less CSS 2. NS 4 as pointed out has a ton more bugs in CSS rendering as compared to IE5 or Opera. Save for the coupled JS/CSS thing, most of these bugs manifest themselves when you start using positioning features; in otherwords, I've typically found that using CSS to denote font changes, indenting, and other such features is not going to cause NS to blow up at you. But my comment was more towards why one needs to browser detect anyway. Even if you browser detect correctly, and send off a CSS file for that browser, my user CSS that might specify Monospace 40pt where you have Sans Serif 10pt is going to most likely cause your entire page to render incorrectly particularly if you are using CSS to position elements rather than thinking of the items within the stream of text. As Corion states above, if you are looking for pixel-perfect placement , it's best to drop back to graphic files or flash or PDF to do this. As Milly points out in another reply, a link near the top of the page for a non-CSS version (which simply doesn't need to send off a CSS file, as opposed to removing all CSS tags) is a very good solution that works in conjunction with having CSS pages without resorting to browser detection. If I come to a site with NS4 that had something like this, warning that "If the layout of this page is screwed up, try this version of this page", I would think this is just as good if not better than trying to guess the browser and play the same games here. And it would be much less work on the server too. Dr. Michael K. Neylon - mneylon-pm@masemware.com \|\| "You've left the lens cap of your mind on again, Pinky" - The Brain	[reply]
Re: Re: Identifying browsers by Melly (Chaplain) on Mar 30, 2001 at 18:36 UTC
Basically, a link with CSS applied to it stops acting as a link. The url of my script is http://cgi.tomandlu.plus.com/cgi-bin/links.cgi and the CSS is the same domain but /avx/links.css Tom Melly, tom@tomandlu.co.uk	[reply]
Re: Re: Identifying browsers by Melly (Chaplain) on Mar 30, 2001 at 18:43 UTC
BTW I intend to add an option for users to turn off CSS, irrespective of browser ID, so even if I misidentify, the site will still be usable. Many thanks for the advice Tom Melly, tom@tomandlu.co.uk	[reply]