User Agent Detection Logic

[Fotios]

Re: User Agent Detection Logic

Jim,
[color=blue]
>
> So it will "mess up the script" across the proprietary Microsoft
> object like "document" then? and pray tell me how this is done, the
> code analysis methods would be really useful to me for other things,
> any language is good.[/color]

"mess up the script across the object" ?!

"code analysis methods" when all that would be needed is simple substring
detection?

GeeWiz bro; go read an FAQ or sometin.

F.

[Douglas Crockford]

Re: User Agent Detection Logic

This thread grows tiresome.

[Richard Cornford]

Re: User Agent Detection Logic

"Fotios" <f_bass@yahoo.c om> wrote in message
news:3f735942$0 $215$bed64819@n ews.gradwell.ne t...
<snip>[color=blue]
>"code analysis methods" when all that would be needed is
>simple substring detection?[/color]

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

Richard.

[Jim Ley]

Re: User Agent Detection Logic

On Fri, 26 Sep 2003 00:12:17 +0100, "Fotios" <f_bass@yahoo.c om> wrote:
[color=blue]
>"code analysis methods" when all that would be needed is simple substring
>detection?[/color]

no, that doesn't work...

all='getElement ById'
document[all]()

or even just

document.fred

that uses IE proprietary, yet ain't gonna be found by simple substring
detection.

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

[Fotios]

Re: User Agent Detection Logic

Jim,

it is obvious that it does not have to be a "catch all" right away.

Can't you see that you cannot win this argument as long as I control
Fudgilla?

F.
[color=blue]
>[color=green]
> >"code analysis methods" when all that would be needed is simple substring
> >detection?[/color]
>
> no, that doesn't work...
>
> all='getElement ById'
> document[all]()
>
> or even just
>
> document.fred
>
> that uses IE proprietary, yet ain't gonna be found by simple substring
> detection.
>
> Jim.
> --
> comp.lang.javas cript FAQ - http://jibbering.com/faq/
>[/color]

[Fotios]

Re: User Agent Detection Logic

Richard,
[color=blue]
> And now a browser that supposedly was created to promote web standards
> is in breach of ECMA 262.[/color]

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]

Re: User Agent Detection Logic

On Fri, 26 Sep 2003 01:50:29 +0100, "Fotios" <f_bass@yahoo.c om> wrote:
[color=blue]
>it is obvious that it does not have to be a "catch all" right away.[/color]

replies go after snipped quotes, you showed you knew it before, please
try again.
[color=blue]
>Can't you see that you cannot win this argument as long as I control
>Fudgilla?[/color]

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.javas cript FAQ - http://jibbering.com/faq/

[Richard Cornford]

Re: User Agent Detection Logic

"Fotios" <f_bass@yahoo.c om> wrote in message
news:3f737217$0 $215$bed64819@n ews.gradwell.ne t...[color=blue][color=green]
>>And now a browser that supposedly was created to promote web
>>standards is in breach of ECMA 262.[/color]
>
>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 - ...[/color]

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

Richard.

[Lasse Reichstein Nielsen]

Re: User Agent Detection Logic

"Fotios" <f_bass@yahoo.c om> writes:
[color=blue]
> Have you noticed how you are suddenly on a "should" basis?[/color]

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 - lrn@hotpop.com
Art D'HTML: <URL:http://www.infimum.dk/HTML/randomArtSplit. html>
'Faith without judgement merely degrades the spirit divine.'

[Fotios]

Re: User Agent Detection Logic

[color=blue]
>
> A new JavaScript capable web browser that abandons ECMA 262 "for the
> greater good"? That just about says it all.[/color]

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

F.

[Fotios]

Re: User Agent Detection Logic

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]

Re: User Agent Detection Logic

On Fri, 26 Sep 2003 03:14:56 +0100, "Fotios" <f_bass@yahoo.c om> wrote:
[color=blue]
>I think I have answered the issue of standards compliance[/color]

Nope...
[color=blue]
>Besides this I have also demonstrated that browser discrimination:
>* is required in many cases that are not necessarily scripting related[/color]

Nope, you've not shown that at all, you've not even attempted to.
[color=blue]
>* is supported by such standards by things like the ua string (and probably
>by more in the future)[/color]

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.
[color=blue]
>* Browser discrimination is a real need as long as various browsers do even
>one thing differently.[/color]

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.
[color=blue]
>* 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.[/color]

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.javas cript FAQ - http://jibbering.com/faq/

[HikksNotAtHome]

Re: User Agent Detection Logic

In article <3f738416$0$211 $bed64819@news. gradwell.net>, "Fotios"
<f_bass@yahoo.c om> writes:
[color=blue]
>This is my final post on this thread.[/color]

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

[Richard Cornford]

Re: User Agent Detection Logic

"Fotios" <f_bass@yahoo.c om> wrote in message
news:3f738414$0 $211$bed64819@n ews.gradwell.ne t...[color=blue][color=green]
>>A new JavaScript capable web browser that abandons ECMA 262
>>"for the greater good"? That just about says it all.[/color]
>
>Can you explain how "abandons" becomes synonymous to "violates"?[/color]

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]

Re: User Agent Detection Logic

"Fotios" <f_bass@yahoo.c om> wrote in message
news:3f738416$0 $211$bed64819@n ews.gradwell.ne t...[color=blue]
>I think I have answered the issue of standards compliance[/color]

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.
[color=blue]
>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)[/color]

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.
[color=blue]
>* Is obviously implementable[/color]

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.
[color=blue]
>* Obviously makes object/property detection based scripts
>problematic[/color]

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.
[color=blue]
>Besides this I have also demonstrated that browser
>discrimination :[/color]
[color=blue]
>* is required in many cases that are not necessarily
>scripting related[/color]

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.
[color=blue]
>* is recognised as a possible need by official standards
>(like the HTTP RFC)[/color]

But not by any standards that are applicable to client-side scripting.
[color=blue]
>* is supported by such standards by things like the ua string
>(and probably by more in the future)[/color]

But not by any standards that are applicable to client-side scripting.
[color=blue]
>* is being widely used in the industry (granted, with
>object/property detection on its side but still for browser
>discriminati on purposes)[/color]

<sarcasm>
And we would hate to see the quality of Internet scripting improve.
</sarcasm>
[color=blue]
>I also understand (and have been widely using it myself for
>years) the benefits of object/property testing in scripts.[/color]

Use? Possibly. Understand? Not judging by the logic in the code you
posted to:-

<URL:

http://groups.google.com/groups?threadm=3f6f9093%240%24211%24bed64819%40

news.gradwell.n et >
[color=blue]
>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.[/color]

In a world where browsers cannot be discriminated, identifying a need to
do so is somewhat futile.
[color=blue]
> 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.[/color]

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.
[color=blue]
>* 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.[/color]

Are you in a position to suggest a free alternative for any embedded or
PDA browsers?
[color=blue]
>I state again that the misrendering does not need to be
>related to javascript issues.[/color]

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).
[color=blue]
>This is my final post on this thread.[/color]

I will believe that when I see it.

Richard.