[ straying OT, so apologies in advance. ] [ also, quite long. double apologies. ]
On Fri, Feb 13, 2004 at 10:29:07AM -0200, [EMAIL PROTECTED] wrote: > > Hopefully you're aware that $HTTP_USER_AGENT is an unreliable variable, > > in that it is sent by the client, and can contain virtually anything. > > Sure, but why would a user want to fake their browser signature? The > worst that could happen is that the offending user would be redirected > to a page that wouldn't look good in her/his browser. Or am I missing > something here? As speculated by Richard Davey: "Although I can't give a specific example, I bet there are some firewalls out there that filter this information out too." I can give a specific example -- Norton Firewall, included with the Norton Internet Security package. An old script of ours (not one I wrote ;) was relying on HTTP_USER_AGENT to do some form interaction, and every so often I would get emails saying that users had received the error page. I couldn't find any connection, until one person happened to mention that they use Norton Firewall product. Sure enough, every person after that that had this problem also (when asked) mentioned that they used Norton Firewall. You can, of course, override Norton's settings. But nobody does that. > > I saw a response letting you know how to do this, but I would > > recommend not sending people to different pages based on which > > browser/OS they're using. > > Why not? Isn't that what most of the big web sites do? If most big web sites jumped off a bridge... okay, sorry, that was dumb. I don't have the numbers/stats/whatever to say whether or not most big websites do or don't do this. However... Are you a big website? Do you have the resources/manpower to maintain two separate versions of each page in your site? Three? Ten? How do you decide when to stop creating OS- or browser-specific versions of your websites? To bring PHP back into this, yes, PHP could lend a hand with some of this. However, you will clearly be doing more work. And what about those browsers with special needs that you *don't* anticipate? What happens to those folks? If your classes of browsers are: - IE/Windows (NT, 2k, 98, XP) - Windows CE - everything else Then where does a user using the JAWS screen reader get sent? My guess is they end up on "everything else", which (again, my guess) is going to try to be a lowest-tech page that attemps to cater to everyone. Will that page be able to be read by JAWS? In 10 years, will the situation be getting better or worse? Will there be only two browsers to code for, or fifty? Do you want to keep trying to code to the idiosyncrasies of each popular new browser that comes out? > > It should be possible to use CSS/(X)HTML to present your content in a > > way that is accessible to whichever browser accesses your site. IMHO, > > browser-sniffing to serve different content is a bad idea. > > What about obsolete browsers that don't handle CSS too well (or not at > all)? We developers would love to have all our visitors use the most > recent browsers, preferably ones with a good implementation of the > JavaScript DOM and XSLT transformations, but that's unfortunately not > what happens in the real world. I agree, it'd be swell if all my users used the latest Mozilla. But you're right, of course -- they don't. And many won't ever upgrade until they get a new OS. So, what's a developer to do? What you first need to decide is what you consider "browser compatibility". By that do you mean that your design needs to look exactly the same in every conceivable browser + OS combination? Or are you more concerned about your users being able to get information and navigate the site? Can you have both? No. It's not possible. Can you make the site look good for 90% of your users, and work well for 100%, all with only one site? Yes. I love this site: http://csszengarden.com/ The exact same HTML is used for each design. The only change is the CSS. Each design in the gallery must work for a majority of major browsers. Head over there, and check it out in IE6/Win, and Mozilla. Browse through a few designs. Then try it out in Netscape 4.x. Your cellphone. NCSA Mosaic. You can browse the site in all of them. The relatively small number of users who use old/incapable browsers: http://www.thecounter.com/stats/2004/January/browser.php can still use the site. Users with modern browsers get beautifully-designed sites, all with the same HTML. Now try using all of those browsers on some of the big websites that do browser sniffing. A real-world gallery: http://cssvault.com/ shows sites that are actually live on the web, using CSS to style their content. And there are indeed some big sites that have decided that a CSS design is viable: http://msn.espn.go.com/ http://news.com.com/ http://www.sprintpcs.com/ I'm not an expert (unfortunately) on the specifics of how to acheive this sort of a design. I'd recommend checking out Jeffrey Zeldman's book "Designing With Web Standards" as a great overview on how to get started on standards-based design. One very brief example of the sorts of thing you could to do allow browsers to use your site would be to use the @import CSS directive to include your stylesheet. Newer browsers can handle this; older ones can't. So when I go to http://csszengarden.com/ in Mozilla, I get a nice site, because it understands @import. When I go there in Netscape 4.78, I get the HTML (which is usable), but not the design. For discussion: http://css-discuss.incutio.com/?page=ImportHack (and I hear that's a great email list for specific CSS-related topics) The key difference in serving designs in this manner is that you are not coding for browsers or platforms; you are coding for capabilities and standards. It's pretty clear that browser rendering/standards support is only getting better, and that the number/variety of browsers is growing. > Could you throw in another 2 cents? :o) I guess that was more like 10 cents. Feel free to continue this off-list if you want to discuss more. This really doesn't have much to do with PHP anymore ;) joel -- [ joel boonstra | gospelcom.net ] -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
