User Agent Detection Logic

[Fotios]

Richard,

your lengthy mantras serve to prove my point perfectly. On the other hand
your attempt to prove that my point is of no real significance is pathetic.
Anyone who can think straight can see how a browser like the one I have
described would make the detection style you are a proponent of a big
problem in many cases. Perhaps I should I write an FAQ for you in order to
understand.

F.

 

[Fotios]

A browser that implements W3C DOM perfectly[1], but which maliciously
distorts proprietary IE features, will work perfectly with object
detection ... because you should always test for W3C DOM first.

Lasse,

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

F.

 

[Fotios]

Well you're the perfect example of how people don't understand object
detection... what other word than SHOULD do you think Lasse should be
using? it can't be MUST, we have no control over people, so what
exactly do you suggest?

No, it should be SHOULD which is exactly my point. To make it more explicit
for you, gone is the certainty that object and property checking just works.

BTW, the first Fudgilla Service Pack was released. Fudgilla will now check
for instances of proprietary Microsoft objects/properties anywhere in the
script and if it finds even one it will mess up the script anyway.

F.

 

[Jim Ley]

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.

 

[Fotios]

Jim,

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.

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

 

[Richard Cornford]

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]

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

 

[Jim Ley]

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.

 

[Fotios]

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.

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

no, that doesn't work...

all='getElementById'
document[all]()

or even just

document.fred

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

Jim.

 

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

 

[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

 

[Richard Cornford]

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]

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.

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?threadm=3f6f9093$0$211$bed64819@
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]

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