User Agent Detection Logic

[Fotios]

Hi guys,

I have put together a flexible client-side user agent detector (written in
js). I thought that some of you may find it useful. Code is here:

http://fotios.cc/software/ua_detect.htm

The detector requires javascript 1.0 to work. This translates to netscape
2.0 and IE 3.0 (although maybe IE 2.0 also works with it)

Cheers,
Fotios

--
http://fotios.cc/

[Fotios]

Richard,

And now a browser that supposedly was created to promote web standards
is in breach of ECMA 262.

It is common knowledge that if you wish to make a list of current products
that do not violate ANY standard then your list will be very long indeed.
Besides, our hypothetical developer does this for the greater good - much
like the guys who implement ua string faking. No?

F.

[Jim Ley]

On Fri, 26 Sep 2003 01:50:29 +0100, "Fotios" <f_****@yahoo.com> wrote:

it is obvious that it does not have to be a "catch all" right away.
replies go after snipped quotes, you showed you knew it before, please
try again.
Can't you see that you cannot win this argument as long as I control
Fudgilla?

You constrained yourself to a W3 DOM and ECMAScript compliance, if you
want to throw that away, of course, nothing will work, but with those
requirements in, we can gracefully degrade any script with object
detection.

Jim.
--
comp.lang.javascript FAQ - http://jibbering.com/faq/

[Richard Cornford]

"Fotios" <f_****@yahoo.com> wrote in message
news:3f*********************@news.gradwell.net...

And now a browser that supposedly was created to promote web
standards is in breach of ECMA 262.

It is common knowledge that if you wish to make a list of
current products that do not violate ANY standard then your
list will be very long indeed. Besides, our hypothetical
developer does this for the greater good - ...

A new JavaScript capable web browser that abandons ECMA 262 "for the
greater good"? That just about says it all.

Richard.

[Lasse Reichstein Nielsen]

"Fotios" <f_****@yahoo.com> writes:

Have you noticed how you are suddenly on a "should" basis?

Obviosuly, you can make stupid code that fails object detection even
on standard browsers. You shouldn't make stupid code.

Object detection *done right* will work for your hypothetical browser.

/L
--
Lasse Reichstein Nielsen - lr*@hotpop.com
Art D'HTML: <URL:http://www.infimum.dk/HTML/randomArtSplit.html>
'Faith without judgement merely degrades the spirit divine.'

[Fotios]

A new JavaScript capable web browser that abandons ECMA 262 "for the
greater good"? That just about says it all.

Can you explain how "abandons" becomes synonymous to "violates"?

F.

[Fotios]

I think I have answered the issue of standards compliance

Let me now take this opportunity to summarize my contribution to this
thread.

In any case, the point is that building something like Fudgilla:

* Now is shown to have possible motivation (and I can quote Richard
swearing this could not be)

* Is obviously implementable

* Obviously makes object/property detection based scripts problematic
Besides this I have also demonstrated that browser discrimination:

* is required in many cases that are not necessarily scripting related

* is recognised as a possible need by official standards (like the HTTP RFC)

* is supported by such standards by things like the ua string (and probably
by more in the future)

* is being widely used in the industry (granted, with object/property
detection on its side but still for browser discrimination purposes)
I also understand (and have been widely using it myself for years) the
benefits of object/property testing in scripts. My position is that this is
not a panacea and that there are still many real cases where browser
discrimination may be needed or preferred. This is because:

* Browser discrimination 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 (besides scripting) and even various bugs.

* 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.

This is my final post on this thread.

Many thanks,

Fotios

[Jim Ley]

On Fri, 26 Sep 2003 03:14:56 +0100, "Fotios" <f_****@yahoo.com> wrote:

I think I have answered the issue of standards compliance
Nope...
Besides this I have also demonstrated that browser discrimination:
* is required in many cases that are not necessarily scripting related
Nope, you've not shown that at all, you've not even attempted to.
* is supported by such standards by things like the ua string (and probably
by more in the future)
The UA string is not a standard, if you'd care to discuss CC/PP and
similar you can feel free to, first you need to demonstrate you
understand it, and the motivations behind it.
* Browser discrimination is a real need as long as various browsers do even
one thing differently.
Except you repeatedly demonstrate that you do not understand any of
the issues - IE 6.JFW renders pages very differently to normal IE6
which is much more similar to Konq. so UA string does nothing to
indicate how a page renders (UA settings, platform settings etc. all
have much larger impact on that)

So if you would care to demonstrate how to differentiate between IE6
and IE6 JFW or IE6 HPR then please go ahead, it would as always be
useful, however showing us scripts that include such things as the
script enabled versions of linux.
* 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.

Except you don't even understand the quite radical difference between
2 versions of Opera with near identical UA strings (even if not
spoofing) or between 2 browsers in different combinations. You've
failed to demonstrate any knowledge of web authoring beyond your own
troll nature.

I don't know why you feel the need to repeatedly troll the group in
your different guises, I know why I care that you don't spread this
disinformation that is showing that you really don't understand web
authoring.

Of course if you have real input to make, you could supply some URLs
which use your techniques and meet your aims.

Jim.

--
comp.lang.javascript FAQ - http://jibbering.com/faq/

[HikksNotAtHome]

In article <3f*********************@news.gradwell.net>, "Fotios"
<f_****@yahoo.com> writes:

This is my final post on this thread.

Hes kidding, right? Finally, his babbling about the superiority of browser
detection is over? Say it isn't so?
--
Randy

[Richard Cornford]

"Fotios" <f_****@yahoo.com> wrote in message
news:3f*********************@news.gradwell.net...

A new JavaScript capable web browser that abandons ECMA 262
"for the greater good"? That just about says it all.

Can you explain how "abandons" becomes synonymous to "violates"?

ECMA 262 is a comprehensive specification for a programming language.
You cannot re-define significant (and non-optional) aspects of that
specification and claim that the result conforms to the standard. And if
your implementation does not conform to ECMA 262 in what way could it be
said to not have abandoned ECMA 262?

Richard.

[Richard Cornford]

"Fotios" <f_****@yahoo.com> wrote in message
news:3f*********************@news.gradwell.net...

I think I have answered the issue of standards compliance
Which standard would that have been then?
ECMA 262? You proposed abandoning it.
W3C DOM? No userAgent strings in that.
RFC 2616? Not relevant to client-side scripting and still makes no
requirement for a user agent header string to uniquely identify the user
agent software.
Let me now take this opportunity to summarize my contribution
to this thread.

In any case, the point is that building something like Fudgilla:

* Now is shown to have possible motivation (and I can
quote Richard swearing this could not be)
Your proposed motivation for the creation of Fudgzilla (discouraging the
use of the Microsoft DOM in favour of W3C DOM standards) does not result
in a browser on which feature/object detecting is not completely
successful. In order to negatively impact on feature detecting as a
technique you have had to abandon the ECAM script specification. Which,
in terms of promoting W3C browser scripting standards, is throwing the
baby away with the bath water.

You also have not effected anywhere near all feature/object detecting
scripts but you have still killed off probably the majority of browser
detection based scripts.

So your hypothetical developer of Fudgzilla has taken the irrational
course of action of attempting to promote the use of the W3C DOM
standard in scripting by abandoning the standard for the language in
which browsers are scripted and still has not made a browser in which
feature/object detecting is less successful than browser detecting.
* Is obviously implementable
Did anyone ever say that it could not be implemented. But the final
version you described does not result from your proposed motivation for
its author (unless he is insane) and the earlier versions which could
have been authored with the motivation described were not a problem for
feature detecting scripts.
* Obviously makes object/property detection based scripts
problematic
Only by abandoning the language specification and the result is still
more problematic for browser detection based scripts. So favouring
feature/browser detection as the more robust, reliable and rational
alternative is still indicated.
Besides this I have also demonstrated that browser
discrimination: * is required in many cases that are not necessarily
scripting related
No, so far you have only mentioned rendering glitches and that belief of
yours seems to be down to a combination of an ignorance of CSS and an
unrealistic attitude towards Internet authoring in general.
* is recognised as a possible need by official standards
(like the HTTP RFC)
But not by any standards that are applicable to client-side scripting.
* is supported by such standards by things like the ua string
(and probably by more in the future)
But not by any standards that are applicable to client-side scripting.
* is being widely used in the industry (granted, with
object/property detection on its side but still for browser
discrimination purposes)
<sarcasm>
And we would hate to see the quality of Internet scripting improve.
</sarcasm>
I also understand (and have been widely using it myself for
years) the benefits of object/property testing in scripts.
Use? Possibly. Understand? Not judging by the logic in the code you
posted to:-

<URL:
http://groups.google.com/groups?thre...%24bed64819%40
news.gradwell.net >
My position is that this is not a panacea and that there
are still many real cases where browser discrimination
may be needed or preferred.
In a world where browsers cannot be discriminated, identifying a need to
do so is somewhat futile.
This is because:
* Browser discrimination 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 (besides scripting) and even various bugs.
So it is a good thing that you have not yet identified a *need* to do
so, just insufficient knowledge to identify and tackle the real problem.
* 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.
Are you in a position to suggest a free alternative for any embedded or
PDA browsers?
I state again that the misrendering does not need to be
related to javascript issues.
Rendering is presentational so that is still CSS and still should be
tackled with CSS not JavaScript. You can repeat this rendering point as
often as you like but when (or if) you can get your head round the
concepts related to the application of CSS you will find that your
problem evaporates (and if you have any conscience you will find
yourself embarrassed that you ever even proposed using JavaScript to
address CSS problems).
This is my final post on this thread.

I will believe that when I see it.

Richard.

[Richard Cornford]

"Richard Cornford" <Ri*****@litotes.demon.co.uk> wrote in message
news:bl*******************@news.demon.co.uk...
<snip>

... . So favouring feature/browser detection as the
more robust, reliable and rational alternative
is still indicated.

<snip>

Obviously that should have read:-
So favouring feature/object detection as the more robust, reliable and
rational alternative is still indicated.

Richard.