Re: Browser Identification - From a designer's perspective
From: C. A. Upsdell (cupsdellXXX_at_-@-@XXXupsdell.com)
Date: 12/15/04
- Next message: Jan Il: "Re: Problems with IE6"
- Previous message: Jan Il: "Re: Missing componets"
- In reply to: Rohan: "Browser Identification - From a designer's perspective"
- Messages sorted by: [ date ] [ thread ]
Date: Wed, 15 Dec 2004 11:46:12 -0500
"Rohan" <Rohan@discussions.microsoft.com> wrote in message
news:BF0A2AE3-31CA-4790-A636-BC52500DC2E7@microsoft.com...
>A feature that would be VERY much appreciate from a designers perspective
>is
> reliable browser identification. Its easy to check the User Agent in HTTP
> headers from almost any web-language, but they aren't reliable. Not only
> do
> several of the competing browsers falsely identify themselves as IE, but
> some
> even allow custom User Agents in their setup options.
userAgent strings are more reliable than you may think. It is mainly a
question of parsing the strings correctly. E.g., when Opera is configured
to mimic IE, the substring 'Opera' may still be found in the userAgent
string: the parser should therefore look for 'Opera' before looking for
'MSIE'. Unfortunately, in my experience, too many people use primitive
browser sniffers that fail to sniff correctly.
As for browsers that let the user set the userAgent string: iCab can do
this, but how many use iCab?; Mozilla and Firefox can do this with a
plug-in, but this is intended to be used only with sites that insist on
finding 'MSIE' in their userAgent strings.
It is also possible to fake the userAgent string in Windows by modifying the
registry: but how many people are going to do this?
> The problem is - not all browsers are created equally. It is frustrating
> when Opera and Firefox butcher portions of website designed for IE, and it
> reflects poorly on the designer. There are times when it would be very
> useful to verify that a user is in fact running Internet Explorer, and not
> a
> competitor desguised as IE.
Opera and Firefox do not, for the most part, butcher sites designed for IE:
instead, IE tends to butcher sites written to the standards. The proper
approach IMO is to design sites for standards-conforming browsers, and then
to make the (usually) minor tweaks needed to circumvent IE's defects.
Working the other way -- designing for IE, and afterwards making tweaks for
standards-conforming browsers -- is another approach, a very tempting
approach in view of the fact that most people use IE. The problem is that
this encourages sloppy thinking among designers, e.g. can make them
misunderstand the box model, or misunderstand how z-index is supposed to
work. This will result in needless wasted time when the designer goes to
deal with standards-compliant browsers ... including future versions of IE.
> I'm sure that at least when communicating with an IIS server, it should be
> doable? Somehow, there should be a method of verifying that IE is in fact
> IE
> from an ASP or ASP.NET script.
A reliable server-side sniffer would indeed be a good thing: a client-side
sniffer works only if the user has not disabled JavaScript; whereas a
server-side sniffer works all the time.
Better still would be for Microsoft to fix IE: by the time Longhorn comes
out, IE will have been stagnant for 5-6 years. Wouldn't it be nice to
design pages that work, without worrying about defective browsers?
- Next message: Jan Il: "Re: Problems with IE6"
- Previous message: Jan Il: "Re: Missing componets"
- In reply to: Rohan: "Browser Identification - From a designer's perspective"
- Messages sorted by: [ date ] [ thread ]
Relevant Pages
|
