Tek-Tips is the largest IT community on the Internet today!
Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!
-
Congratulations Chris Miller on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
browser compatibility 4
- Thread starter TFfan
- Start date
-
1
- #2
-
1
- #3
My approach is to write valid, standards-compliant HTML and CSS which works fully on modern browsers but will still be legible (if not necessarily pretty) on older browsers. Look at your access logs to see how many people are using older browsers, are there enough to make it worth supporting them?
If you DO decide to sniff out the browser version, do it in the server - PHP, ASP, Perl (via SSI), whatever - rather than Javascript. There are probably as many visitors (if not more) who surf with Javascript switched off as surf with, say NS4.7.
-- Chris Hunt
Extra Connections Ltd
The real world's OK for a visit, but you wouldn't want to LIVE there!
If you DO decide to sniff out the browser version, do it in the server - PHP, ASP, Perl (via SSI), whatever - rather than Javascript. There are probably as many visitors (if not more) who surf with Javascript switched off as surf with, say NS4.7.
-- Chris Hunt
Extra Connections Ltd
The real world's OK for a visit, but you wouldn't want to LIVE there!
I'd go with standard compliant code. Think forwards not backwards! 
Gary Haran
********************************
Gary Haran
********************************
- Thread starter
- #5
Server side detection would be great, but I'm afraid it isn't something I know.
I think you over estimate the number of people surfing with javascript switch off. Since most web surfers are computer simpletons, they wouldn't know how nor think to turn off javascript.
I think you over estimate the number of people surfing with javascript switch off. Since most web surfers are computer simpletons, they wouldn't know how nor think to turn off javascript.
jwenting,
Actually coding for IE5 doesn't mean standard compliance. True standard compliance can be achieved by validating your code at
If you code for IE, Microsoft has put plenty of bugs and "features" that sabotages standard compliant efforts. This would make your pages less compatible with some of the most standard compliant browsers out there (Gecko Based such as Mozilla or Phoenix).
People with truly standard compliant browsers would come less often to your site. If too many sites code only for IE and it's propritary standards many will be forced to use Internet Explorer. Microsoft will love you because that means they will make even more money with their monopoly. I won't love you though! ;-)
Gary Haran
********************************
Actually coding for IE5 doesn't mean standard compliance. True standard compliance can be achieved by validating your code at
If you code for IE, Microsoft has put plenty of bugs and "features" that sabotages standard compliant efforts. This would make your pages less compatible with some of the most standard compliant browsers out there (Gecko Based such as Mozilla or Phoenix).
People with truly standard compliant browsers would come less often to your site. If too many sites code only for IE and it's propritary standards many will be forced to use Internet Explorer. Microsoft will love you because that means they will make even more money with their monopoly. I won't love you though! ;-)
Gary Haran
********************************
- Thread starter
- #8
TFfan,
(I don't even do as I preach, my site doesn't yet validate but I'm in the process of redoing it).
So long as things validate you should feel confident that future browsers can render it properly. It is a good idea to test it in browser you believe are going to want to see your site.
I personally and out of principle never support NS4 because of it's old proprietary implementations. I only worry about 5.x and above browsers as that is generally my audience.
Gary Haran
********************************
(I don't even do as I preach, my site doesn't yet validate but I'm in the process of redoing it).
So long as things validate you should feel confident that future browsers can render it properly. It is a good idea to test it in browser you believe are going to want to see your site.
I personally and out of principle never support NS4 because of it's old proprietary implementations. I only worry about 5.x and above browsers as that is generally my audience.
Gary Haran
********************************
-
1
- #10
ChrisHirst
IS-IT--Management
In reality IE is probably the least standards compliant browser going, many people go for NS bashing but the reason for a lot of problems are using the proprietary attributes in IE and expecting it to work in a strict standards compliant browser.
the only way to go is write standards compliant HTML and CSS and avoid the proprietary 'features' in ALL browsers
As for NS4 (and IE4) users at sometime they have to realise the world moves on.
Chris.
Indifference will be the downfall of mankind, but who cares?
the only way to go is write standards compliant HTML and CSS and avoid the proprietary 'features' in ALL browsers
As for NS4 (and IE4) users at sometime they have to realise the world moves on.
Chris.
Indifference will be the downfall of mankind, but who cares?
I have to give you a star Chris! You put it nicely!
Gary Haran
********************************
You put it nicely! Gary Haran
********************************
-
1
- #12
EdwardMartinIII
Technical User
TFfan,
Your question is a false choice.
Except for occasional bits of weirdness, chances are if you're encountering something that requires you make such a decision, there is probably a third option: avoid that functionality.
If you design your pages and your site from the beginning to pass the w3c tests and to run pleasantly under the basic browser-set (IE, netscap, mozilla), then you'll have a web page/site that will be enjoyed by pretty much everybody who visits it.
For some things, there are browser-specific pecadilloes. Consider it a challenge to work around that crap. Yes, sometimes this can be a pain, but the only way to win the browser-functionality contest is to simply not play. Find a solution that doesn't care which browser runs.
I ran across a thing in a script: I did a JavaScript split command in a string on a character. IE and Netscape handled the results differently if the character didn't exist in the string (which could happen). I almost, in frustration, wrote a what-browser's-running function. But then I realized that was the wrong path. Instead, I assigned the value of the split to a variable and determined the type of the variable. In one case, it was Null, in another case, it was not Null, but it was empty. Aha! So, I used that as my check. Now, instead of checking some kind of name-of-browser string, I simply check for the actual thing that is relevent: how does this browser handle that weird little split. Voila. No checking for browser type.
In short, write for the world, not for Microsoft or Netscape or Mozilla. If you must add a decision-tree in your code, do so based on the actual thing you're checking, not along browser titles.
Cheers,
![[monkey]](/data/assets/smilies/monkey.gif "[monkey] [monkey]")
Edward
"Cut a hole in the door. Hang a flap. Criminy, why didn't I think of this earlier?!" -- inventor of the cat door
Your question is a false choice.
Except for occasional bits of weirdness, chances are if you're encountering something that requires you make such a decision, there is probably a third option: avoid that functionality.
If you design your pages and your site from the beginning to pass the w3c tests and to run pleasantly under the basic browser-set (IE, netscap, mozilla), then you'll have a web page/site that will be enjoyed by pretty much everybody who visits it.
For some things, there are browser-specific pecadilloes. Consider it a challenge to work around that crap. Yes, sometimes this can be a pain, but the only way to win the browser-functionality contest is to simply not play. Find a solution that doesn't care which browser runs.
I ran across a thing in a script: I did a JavaScript split command in a string on a character. IE and Netscape handled the results differently if the character didn't exist in the string (which could happen). I almost, in frustration, wrote a what-browser's-running function. But then I realized that was the wrong path. Instead, I assigned the value of the split to a variable and determined the type of the variable. In one case, it was Null, in another case, it was not Null, but it was empty. Aha! So, I used that as my check. Now, instead of checking some kind of name-of-browser string, I simply check for the actual thing that is relevent: how does this browser handle that weird little split. Voila. No checking for browser type.
In short, write for the world, not for Microsoft or Netscape or Mozilla. If you must add a decision-tree in your code, do so based on the actual thing you're checking, not along browser titles.
Cheers,
Edward "Cut a hole in the door. Hang a flap. Criminy, why didn't I think of this earlier?!" -- inventor of the cat door
a star to edward to add even more to the wonderful world of intelligent cross-browser web developement!
Gary Haran
********************************
Gary Haran
********************************
TFfan
"I think you over estimate the number of people surfing with javascript switch off."
According to , about 9% of users surf with javascript switched off, compared to 2% using version 4 browsers. I know who I'd concentrate my efforts on - it seems crazy to use javascript to serve a special style sheet to users of some crummy old browser, but serve no style sheet at all to (paranoid) users of modern browsers who disable scripting.
As to how to detect browsers on the server side, you do it the same way as through JavaScript - by looking at the environment variables. Take a look at for some examples.
Having said that, I agree with Edward that it's better, if you must sniff something, to sniff out capabilities rather than browser flavours - "can you do this" rather than "are you browser xyz (and thus able to do this)". Better still to avoid browser-specific gew-gaws and concentrate on the content of your site!
-- Chris Hunt
Extra Connections Ltd
The real world's OK for a visit, but you wouldn't want to LIVE there!
"I think you over estimate the number of people surfing with javascript switch off."
According to , about 9% of users surf with javascript switched off, compared to 2% using version 4 browsers. I know who I'd concentrate my efforts on - it seems crazy to use javascript to serve a special style sheet to users of some crummy old browser, but serve no style sheet at all to (paranoid) users of modern browsers who disable scripting.
As to how to detect browsers on the server side, you do it the same way as through JavaScript - by looking at the environment variables. Take a look at for some examples.
Having said that, I agree with Edward that it's better, if you must sniff something, to sniff out capabilities rather than browser flavours - "can you do this" rather than "are you browser xyz (and thus able to do this)". Better still to avoid browser-specific gew-gaws and concentrate on the content of your site!
-- Chris Hunt
Extra Connections Ltd
The real world's OK for a visit, but you wouldn't want to LIVE there!
- Thread starter
- #15
- Status
Similar threads
- Locked
- Question
- Locked
- Question
- Locked
- Question