User Agent Detection Logic

You won't be jailed, but it seriously harms both your insight

maybe, but it helps uncalcify my thinking.

and our
sympathy if you don't.

awwwww! Please? Pretty Please?

I have also heard that no scripter really knows what he/she is doing.
What
do you think about that?

No one can speak but for themselves, especially if they spend their time
behind computer screens. I for one haven't a clue.

This philosophy of yours is very deep.

The bottom line is the navigator agent string thing can be
changed at will both by browser-makers and end-users. Mine is a
Shakespeare
quote.

my friend, you are too kewl!

If I want my script to bark up the document.images tree, I will not test
for
document.styleSheets or screen.availWidth or navigator.anyThing.

In your limited universe (browser detection) = (browser detection for
javascript running purposes)

Regards,
Ivo

More regards,
Fotios

Not to mention credibility. He multi-posted these same thoughts in the
microsoft.public.scripting.jscript NG
snip

I do not see what credibility has to do with posting in two groups instead
of one.
Then again, if it is so, I wonder how this original theory of yours applies
to multi-NG whiners.

You too?

hey, you found company! You guys should build on this.

F.

On Mon, 22 Sep 2003 06:23:59 +0100, "Fotios" <f_bass (AT) yahoo (DOT) com> wrote:

Isn't it still a fact that most script that goes around is not
cross-browser?

Who knows.

I have also heard that no scripter really knows what he/she is doing. What
do you think about that?

I think that sounds like flame bait. I think that if you believe
that, then you just insulted yourself. I think you need better
sources of information. I think that if you stick around the
newsgroup for a while you will discover that statement is wrong.

2. I don't want to build a detector every time depending on what I want to
use.

Yeah, if you want to test whether the browser is capable of doing,
say, image rollovers, writing
var fSupportsScriptableImages = (document.images ? true : false);
sure is a real pain.

3. A generic feature based browser detector seems to be much more work than
the one I posted. If you build one let me know and I will give it a try.

No one would ever write a "generic feature based browser detector".
Whatever that is. You don't need to know every feature the browser
supports; you only need to know if it supports the specific feature(s)
you are trying to use.

This isn't an argument you'll win; feature/object detection has long
been recommended over browser detection. It's less prone to error and
it requires less maintenance because it's backward and FORWARD
compatible.

Regards,
Steve

JRS: In article <3f6e6b22$0$216$bed64819 (AT) news (DOT) gradwell.net>, seen in
news:comp.lang.javascript, Fotios <f_bass (AT) yahoo (DOT) com> posted at Mon, 22
Sep 2003 06:23:59 :-

So you haven't bothered to read the comp.lang.javascript FAQ before
posting then:-

URL: http://jibbering.com/faq/#FAQ4_26

I do not need to read the FAQ before or after I post.

It would, however, be a useful precaution against appearing to be a
person of inadequate sagacity. Of course, that appearance would in that
case not be misleading.

--
© John Stockton, Surrey, UK. ?@merlyn.demon.co.uk Turnpike v4.00 IE 4 ©
<URL:http://jibbering.com/faq/> Jim Ley's FAQ for news:comp.lang.javascript
<URL:http://www.merlyn.demon.co.uk/js-index.htm> JS maths, dates, sources.
<URL:http://www.merlyn.demon.co.uk/> TP/BP/Delphi/JS/&c., FAQ topics, links.

I have also heard that no scripter really knows what he/she is doing.
What
do you think about that?

I think that sounds like flame bait. I think that if you believe
that, then you just insulted yourself. I think you need better
sources of information. I think that if you stick around the
newsgroup for a while you will discover that statement is wrong.

Looks like you are biting. BTW, I have been around this group for years.

Yeah, if you want to test whether the browser is capable of doing,
say, image rollovers, writing
var fSupportsScriptableImages = (document.images ? true : false);
sure is a real pain.

Wouldn't you rather skip that part?

No one would ever write a "generic feature based browser detector".
Whatever that is.

Yeah, I suppose it is not mentioned in the FAQ; so FAQ puppies get
short-circuited.

This isn't an argument you'll win; feature/object detection has long
been recommended over browser detection.

This world is not black and white. Browser detection using the useragent
string still has a place and a function for the reasons I mentioned and
without claiming it is a panacea.

BTW, I am still waiting for your answer on the rest of my points about why
one would use useragent string based detection.

F.

It would, however, be a useful precaution against appearing to be a
person of inadequate sagacity. Of course, that appearance would in that
case not be misleading.

This is a javascript group doc. If you are looking for sagacity per se maybe
you are looking in the wrong place. If your way of achieving sagacity is
reading JS FAQs then maybe you ought to wonder if something is wrong with
you. Finally, if you wish to rephrase the syntactic and semantic abomination
you just posted, I'll still read it (although I don't know if I really
should).

F.
--
http://fotios.cc/

"Fotios" <f_bass (AT) yahoo (DOT) com> wrote

So you haven't bothered to read the comp.lang.javascript
FAQ before posting then:-

URL: http://jibbering.com/faq/#FAQ4_26

I do not need to read the FAQ before or after I post.

- as it says essentially the same thing. (Still, I don't
expect you would consider that a document that is subject
the scrutiny and review of all of the regular poster to
this group as having anything accurate to say on the
subject of browser scripting.)

I don't know what to answer to you as I have not read
the FAQ.

You could try to explain why you "do not need to read the FAQ". It
certainly isn't because you are already familiar with its contents, or
that you know JavaScript and browser scripting better than its
collective authors (though it may be because you believe one, or both,
of those to be the case).

<snip>

Isn't it still a fact that most script that goes around
is not cross-browser?

Yes, it is also a fact that some scripts do not even manage to be
multi-browser (which is all that your scripting actually aspires to be,
judging by your other posts in this thread). But why would
comp.lang.javascript promote the lowest common denominator as the
acceptable standard in a world where the norm is so poor? In fact the
poverty of the mass of current Internet script authoring is probably the
best justification for promoting only the highest standards in browser
scripting: True cross-browser scripting; authoring for any and every
browser, including the ones that will not execute JavaScript at all. And
the only strategy that is capable of delivering scripts that function,
or gracefully degrade (as appropriate), in JavaScript enabled browsers
is feature detecting to determine browser support for the features
required by the script.

I have also heard that no scripter really knows what
he/she is doing. What do you think about that?

If you did hear that it will have been from the lips of someone who did
not know what they were doing and was looking to justify their
unwillingness to find out.

A detector is about "what is" not about "what ought to be".

So test "what is" not "what ought to be" which is what
you are testing by assuming that the navigator.userAgent
string ought to be a discriminating indicator of the type
and version of a web browser. It is not and has not been
for quite some time now.

One can easily write a lynx-like user agent that supplies
any user string he/she damn pleases.

It appears (from existing web browsers) that it is not too difficult to
write an IE-like web browser that supplies whatever user agent string
the user chooses (or its authors prefer). It has been done, many times.

Why does that shatter the status of things? (The status being
that all major browsers have - and should have - distinctive
default strings)

Of what value is it that some browsers have default user agent string
that are distinct from each other when they are indistinguishable from
the user agent strings of a cluster of other browsers? Of what value is
it when those strings are only the default values and the user has easy
access to mechanisms for changing them; mechanisms that (usually) have
zero impact on the actual abilities of the browser? And why "should
have"? Because it suites you?

The status of things is that the navigator.userAgent string is no longer
a discriminating identifier of web browsers and, if it ever was, it
never will be again.

As it is your code will identify Konqueror 3 as IE,
Netscape, Opera Konqueror and unknown depending on which
of the userAgent string I choose form the list of 20 odd
provided in the drop-down in the preferences.

Well, if you change the string you are on your own.

Web browsers are user configurable software. If the user has the options
in the software preferences then it is just unrealistic not to expect
them to configure their browser to reflect their preferences. In all of
the web site/application specifications I have seen to date I have seen
requirements to work with only a limited set of named browsers/versions
and even requirements to work only with JavaScript enabled browsers but
I have never seen it stated that scripts were only required to work with
those browsers in their _default_ configurations.

Of course your "browser detecting" followed by the assumption that
everything is then going to be the way that you are expecting it is
going to fall down with many non-default configurations even on IE.

While the same script will be absolutely convinced that
my Palm OS web browser is IE 6, but a script that treats
it as IE 6 will fail horribly. To qualify as a "detector"
a script should be expected to produce discriminating
results. The navigator.userAgent string just cannot provide
that.

Only because you were naughty and you changed the string.

No I did not. Pals OS web browser is just one of a number of browsers
that use a user agent string that is indistinguishable from an IE user
agent string, and it doesn’t give the user any direct access to
alternatives. And indistinguishable means indistinguishable, there is no
telling substring that can be used to distinguish them from IE versions
(on the Palm even the reported OS is fictional).

What is the motivation in coding for the miniscule percentage
of users who not only use virtually non-existent browsers
but also play with their user agent strings?

Because feature detecting does not have any interest in the type or
version of the web browser so there is no extra effort or work involved
in coping with any minority browser. (assuming of course that these
browsers that are indistinguishable from IE are actually minority
browsers. It is impossible to tell if they always appear in the browser
statistics as IE). You just write the script and if the browser supports
the required features then you are in business and if not its time to
gracefully degrade.

But, as I said, it is almost never necessary to know the
browser type or version. Feature detection ...
snip

1. Detecting a browser type is not necessarily for scripting
purposes. For instance, you may not like the way something
renders in gecko.

Rendering is presentation, so CSS. Use CSS solutions for CSS problems,
involving scripting is unnecessary (and unreliable) but you cannot make
a discriminating identification of a Gecko browser from its user agent
string anyway as several Gecko variants (most notably Gostzill) are ser
up to report any of a range of preference settable userAgent strings
(including spoofing IE 100%) and a few even provide the user with the
option to type in anything they want as a user agent string. (these are
normal GUI configuration settings available under preferences not some
devious hack. However, all Gecko userAgent strings are amenable to
alteration by devious hack as well).

2. I don't want to build a detector every time depending
on what I want to use.

You are still thinking in terms of browser detecting. Feature detecting
is an integral part of scripting; there is no distinct "detector" at
all.

3. A generic feature based browser detector seems to be
much more work than the one I posted. If you build one
let me know and I will give it a try.

The reason that I use the term "feature detecting" as opposed to the
more common term "object detecting" (apart from the fact that you also
have to be testing functions, properties with primitive values and
sometimes language implementation characteristics) is that "object
detecting" is associated with attempts to detect browser types and
versions based on objects present in their DOMs. That technique was
widely adopted when it initially became clear that browser detecting
based on userAgent strings was no longer viable and initially produced
code like:-

var isIE = document.all?true:false;
var isNet4 = document.layers?true:false;

The response to this type of browser detecting (attempts at a generic
object detecting based browser detector) was that other browser
manufacturers started implementing document.all collections, or
document.layers collections or any other object/feature that someone had
hit upon as a discriminating indicator of a particular browser. And they
did this for exactly the same reasons that they started spoofing each
other’s user agent strings in the first palace. We now live in a world
where as many browsers have a document.all collection as don’t and the
last thing that its presence in a DOM means is that the browser is IE.

And it goes on; someone hits upon the idea of using the ActiveXObject
constructor as a discriminating indicator of IE 5+ and then uses that to
exclude non-IE 5+ browsers, and then we find that IceBrowser 5 has an
ActiveXObject constructor.

Pick a feature as a discriminating indicator of a browser and implement
your browser detecting based on that and the next thing you know a
couple of other browsers will have implemented that feature, or faked
it, and your browser detecting script is no longer doing what it was
designed to do.

The recurring theme here is that the purpose that you, and most others,
put browser detecting to motivates the browser manufacturers (including
Microsoft; witness the "Mozilla 4.0" that its userAgent string starts
with) to do what ever it takes to sidestep that browser detection.

The result is that browser detection as a practice has resulted in its
own invalidity.

The solution is to abandon browser detection as an idea and concentrate
on detecting the specific features that a script actually needs in order
to run. Never interested in the type of version of the browser, never
assuming that the existence of on feature implies the presence of
another and resulting in scripts that do what they can when they can and
fail cleanly when they can't, even on the browsers that will not be
released until next year and whose names are as yet unknown.

Richard.

You could try to explain why you "do not need to read the FAQ".

Sure. For the same reason I do not need to read the bible in order to be a
good Christian.
I suppose one can find many similar ways to explain what you asked.

I'll tell you the truth tho. I have read the FAQ about 2 years back.
Since then so much has happened that I do not even remember what was in
there and what not.

It
certainly isn't because you are already familiar with its contents, or
that you know JavaScript and browser scripting better than its
collective authors
(though it may be because you believe one, or both,
of those to be the case).

I don't even ponder over such questions. It is just that I like solving
problems on my own. I am in this business strictly for the fun that this
entails.

snip
Isn't it still a fact that most script that goes around
is not cross-browser?

Yes, it is also a fact that some scripts do not even manage to be
multi-browser (which is all that your scripting actually aspires to be,
judging by your other posts in this thread).

Well, the scripts that I have posted are certainly multi-browser so what you
say here is obviously wrong.

True cross-browser scripting; authoring for any and every
browser, including the ones that will not execute JavaScript at all. And
the only strategy that is capable of delivering scripts that function,
or gracefully degrade (as appropriate), in JavaScript enabled browsers
is feature detecting to determine browser support for the features
required by the script.

Read below for an answer to that.

I have also heard that no scripter really knows what
he/she is doing. What do you think about that?

If you did hear that it will have been from the lips of someone who did
not know what they were doing and was looking to justify their
unwillingness to find out.

You sound hurt. Why don't you tell us what else you do well except scripting
(if we assume that you even do that well).
Maybe you can prove that you don't have any ego-related reason in making
this claim.

Of what value is it that some browsers have default user agent string
that are distinct from each other when they are indistinguishable from
the user agent strings of a cluster of other browsers? Of what value is
it when those strings are only the default values and the user has easy
access to mechanisms for changing them; mechanisms that (usually) have
zero impact on the actual abilities of the browser? And why "should
have"? Because it suites you?

Have you ever wondered why the user agent string is there at all? Why was it
introduced and kept in countless versions and builds?

I quote from RFC 2616:
----
14.43 User-Agent

The User-Agent request-header field contains information about the
user agent originating the request. This is for statistical purposes,
the tracing of protocol violations, and automated recognition of user
agents for the sake of tailoring responses to avoid particular user
agent limitations. User agents SHOULD include this field with
requests. The field can contain multiple product tokens (section 3.8)
and comments identifying the agent and any subproducts which form a
significant part of the user agent. By convention, the product tokens
are listed in order of their significance for identifying the
application.

User-Agent = "User-Agent" ":" 1*( product | comment )

Example:

User-Agent: CERN-LineMode/2.15 libwww/2.17b3
----

After all the computer world only revolves because there are standards that
are followed by majorities.

The status of things is that the navigator.userAgent string is no longer
a discriminating identifier of web browsers and, if it ever was, it
never will be again.

The point is that it should be.On the other hand perhaps your faith that
object/property testing will remain a good way to test is overly inflated.

Web browsers are user configurable software. If the user has the options
in the software preferences then it is just unrealistic not to expect
them to configure their browser to reflect their preferences. In all of
the web site/application specifications I have seen to date I have seen
requirements to work with only a limited set of named browsers/versions
and even requirements to work only with JavaScript enabled browsers but
I have never seen it stated that scripts were only required to work with
those browsers in their _default_ configurations.

You are not supposed to fake user agent strings. Period.
This feature has only become available in various browsers and only because
it is very easily implementable.

Of course your "browser detecting" followed by the assumption that
everything is then going to be the way that you are expecting it is
going to fall down with many non-default configurations even on IE.

What percentage do you think? I say it works 99%.

No I did not. Pals OS web browser is just one of a number of browsers
that use a user agent string that is indistinguishable from an IE user
agent string, and it doesn't give the user any direct access to
alternatives. And indistinguishable means indistinguishable, there is no
telling substring that can be used to distinguish them from IE versions
(on the Palm even the reported OS is fictional).

Too bad. I think Opera also had the unfortunate idea of defaulting to
completely faking the IE ua string a few versions back. It seems they did
not keep it up for long.

(assuming of course that these
browsers that are indistinguishable from IE are actually minority
browsers. It is impossible to tell if they always appear in the browser
statistics as IE).

Heh, sorry but this reminds me of comical Ali.

1. Detecting a browser type is not necessarily for scripting
purposes. For instance, you may not like the way something
renders in gecko.

Rendering is presentation, so CSS. Use CSS solutions for CSS problems,

Yeah but CSS does not always work the way one wants and the detection is
done in JS not CSS.

You are still thinking in terms of browser detecting. Feature detecting
is an integral part of scripting; there is no distinct "detector" at
all.

wow, that is tew kewl (and deep).

A few points to keep you busy:

* Should every browser preferably have a distinctive user agent string or
not? Don't read the RFC just use your common sense.

* You are trying to make a rule out of the exception (exception being the
faked strings)

* I can write a user agent that fakes the existence of certain JS objects
but provides others while for the faked ones has Shakespeare quotes as the
return value of various methods. I could name this product Fudgilla (create
say 10 variants of it under different names like Geekzilla), make it freely
available to the geek crowds and then argue that because these products
exist the feature detection method is no good anymore for deciding what kind
of browser we got.

Don't scratch your head too hard.

F.

"Fotios" <f_bass (AT) yahoo (DOT) com> writes:

Yes, it is also a fact that some scripts do not even manage to be
multi-browser (which is all that your scripting actually aspires to be,
judging by your other posts in this thread).

Well, the scripts that I have posted are certainly multi-browser so what you
say here is obviously wrong.

Uhm, no. He said that it is multi-browser, but not cross-browser, so
you agree with him.

Have you ever wondered why the user agent string is there at all? Why was it
introduced and kept in countless versions and builds?
....

User-Agent = "User-Agent" ":" 1*( product | comment )

Example:

User-Agent: CERN-LineMode/2.15 libwww/2.17b3
----

After all the computer world only revolves because there are standards that
are followed by majorities.

It is *not* followed by the majorities. Internet Explorer doesn't follow it!

IE claims to be Mozilla/4.0 and then adds a comment saying that it is really
(Compatible; MSIE 6,0;...).

Every time someone makes a page that restricts access to some
browsers, most likely including IE, a browser will change, or allow
the user to change, how it identifiers itself. It does that, not because
it doesn't care about the standard, but because it has to work in a world
where page authors force them to lie.

The status of things is that the navigator.userAgent string is no longer
a discriminating identifier of web browsers and, if it ever was, it
never will be again.

The point is that it should be.

The point is also that browser detection shouldn't be necessary.

But it isn't. Browsers should support standards, but the most widely
used browser doesn't understand proper CSS 2 and doesn't follow the W3C
DOM specifications.

On the other hand perhaps your faith that object/property testing
will remain a good way to test is overly inflated.

Care to explain why?

You are not supposed to fake user agent strings. Period.

You are not supposed to restrict access to a page based on the
browser. That is counter to the very basic concept of the web.
But they do, and browsers adapt.

It is sad that faking your user agent string is necessary, but
blame the page authors, not the browser vendors or users. They
started it.

This feature has only become available in various browsers and only
because it is very easily implementable.

And not because there was a need?
Do you really mean that?

* Should every browser preferably have a distinctive user agent string or
not? Don't read the RFC just use your common sense.

They should.
Do they? No.
Your code is meant to solve a real life problem: That browsers are different.
In an ideal world, your program is not necessary.
In the real world, it should consider the real life problem that the user
agent string can not be trusted in all cases.

I don't know the percentage of people faking their user agent string.

I do when I access MSDN, because otherwise they won't show me the
page. I am smart enough to handle it in Proximitron, so not all pages
are affected. Not everyone is.

I do know that your program would have problems with detecting Netscape 4,
since it identifies itself as Mozilla/4, and so does IE.

Your test relies on the comment part of the userAgent string to identify
IE, which is not following the standard anyway.

Built-in user-agent strings in the browsers you try to identify.
Opera:
Opera/7.20 (Windows NT 5.1; U) [en]
Mozilla/5.0 (Windows NT 5.1; U) Opera 7.20 [en]
Mozilla/4.78 (Windows NT 5.1; U) Opera 7.20 [en]
Mozilla/3.0 (Windows NT 5.1; U) Opera 7.20 [en]
Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1) Opera 7.20 [en]

Netscape 4.08:
Mozilla/4.08 [en] (WinNT; I ;Nav)

Mozilla Firebird 0.6
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4b) Gecko/20030516 Mozilla Firebird/0.6
Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)
Mozilla/4.8 [en] (Windows NT 5.0; U)
Opera/7.11 (Windows NT 5.1; U) [en]

Internet Explorer 6:
Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; MyIE2; .NET CLR 1.1.4322)

This doesn't count browsers on other platforms, still mostly Mac and
Unix, but increasingly also mobile devices.

/L
--
Lasse Reichstein Nielsen - lrn (AT) hotpop (DOT) com
Art D'HTML: <URL:http://www.infimum.dk/HTML/randomArtSplit.html>
'Faith without judgement merely degrades the spirit divine.'

Well, the scripts that I have posted are certainly multi-browser so what
you
say here is obviously wrong.

Uhm, no. He said that it is multi-browser, but not cross-browser, so
you agree with him.

yup, I misread that part. I guess I do agree with him on this one.

It is *not* followed by the majorities. Internet Explorer doesn't follow
it!

IE claims to be Mozilla/4.0 and then adds a comment saying that it is
really
(Compatible; MSIE 6,0;...).

The mozilla string is there because of known historical reasons. What you
should ask yourself is why the MSIE
part is there. Is it by chance?

Every time someone makes a page that restricts access to some
browsers, most likely including IE, a browser will change, or allow
the user to change, how it identifiers itself. It does that, not because
it doesn't care about the standard, but because it has to work in a world
where page authors force them to lie.

And has to do that because there are millions of scripts that are blocking
access to various browsers.
In your js circumscribed world you fail to see that as long as a browser
cannot claim to work in every aspect of its rendering and runtime behavior
exactly as a different one then it should not (and is not in its interest)
fake the string of the other browser or the results will be embarrasing.
Furthermore as long as two browsers fail to be identical in their behavior
the motivation for distinguishing between them is *very* real and with it
the motivation for writing discriminating browser detection scripts.

A couple of facts:
-----------------

* Faked strings by browsers (and not robots) are a *very* rare occurence
overall.

* When the ua string is faked the standard is not followed properly.

The point is also that browser detection shouldn't be necessary.

Yes, and also pain and poverty in this world.

But it isn't. Browsers should support standards, but the most widely
used browser doesn't understand proper CSS 2 and doesn't follow the W3C
DOM specifications.

So, you are a proponent of non-compliance with the standards then?

On the other hand perhaps your faith that object/property testing
will remain a good way to test is overly inflated.

Care to explain why?

I did explain at the very end of my previous message but you seem to have
skipped that part.
Let us know when you read it. Dying to hear your comments!

You are not supposed to fake user agent strings. Period.

You are not supposed to restrict access to a page based on the
browser. That is counter to the very basic concept of the web.
But they do, and browsers adapt.

Can you please quote an official standard that says that?
In my house I don't let in people who have stepped on dirt.
A site is somebody's house of sorts.

It is sad that faking your user agent string is necessary, but
blame the page authors, not the browser vendors or users. They
started it.

Ah, that reminds me of the days I was playing Hide n Seek.
Those were the days!

This feature has only become available in various browsers and only
because it is very easily implementable.

And not because there was a need?
Do you really mean that?

Sure there is a need. There is also a need behind cracking.

* Should every browser preferably have a distinctive user agent string
or
not? Don't read the RFC just use your common sense.

They should.
Do they? No.
Your code is meant to solve a real life problem: That browsers are
different.
In an ideal world, your program is not necessary.
In the real world, it should consider the real life problem that the user
agent string can not be trusted in all cases.

yes, but it works at a very high percentage of cases. No?
Isn't percentage of success the measure in Internet related systems?
Why would this be perfect? (although I certainly would like it to be).
As for the "real world" read the end of this message (don't skip it this
time)

I do know that your program would have problems with detecting Netscape
4,
since it identifies itself as Mozilla/4 , and so does IE.

Sure. There are cases that this script will not work properly. The addition
of some feature based detection logic for discriminating between certain
browsers would help it. Maybe version 2. The raison d'etre of this script is
browser discrimination and the easy and quite efficient way to do that (with
a very high percentage of success) is the ua string. As for the reason for
discrimination I have briefly explained it above and will explain it more
below.

About the need to disciminate browsers
----------------------------------------

* This is a real need as long as various browsers do even one thing
differently. This thing does not necessarily have to do with how scripts
execute. It may have to do with how things render, what is supported and
what not and even various bugs.

* In this quest there are no perfect solutions but there are good solutions
and there are solutions that can become even better.

* It is better to deny services to a particular browser (and suggest a free
alternative instead) than have your site misrender embarrassingly on various
untested browsers.
I state again that the misrendering does not need to be related to
javascript issues.

* Most commercial sites currently have similar detection logic for either
excluding browsers or varying their services depending on the browser.

* I can see how circumscribing one's Internet experience to things that
revolve around a single technology (or a couple) can create confusion and
questions that tend to be metaphysical in nature.

F.