browser tests

What is the recommended code to test browser type, for conditional
processing in Javascript? I have seen tests for "document.all". I have
seen tests for the actual browser name, or substrings in the browser name.
What do you all recommend? Thanks...Jim...

re: browser tests

Jimnbigd wrote:[color=blue]
> What is the recommended code to test browser type, for conditional
> processing in Javascript? I have seen tests for "document.all". I have
> seen tests for the actual browser name, or substrings in the browser name.
> What do you all recommend? Thanks...Jim...
>[/color]

<URL:http://www.jibbering.com/faq/#FAQ4_26>

The name of the game is 'feature detection'. Even if you could
reliably detect the browser from the UA string, you would then make
assumptions about what that particular browser does or doesn't support
that could be equally erroneous.

The most common result of browser sniffing is the possible exclusion of
any browser that you fail to take into account, even if it does support
the features you are using.

And that is the primary reason why browser developers faked UA strings
in the first place (heck, IE used to masquerade as Netscape).


--
Rob

re: browser tests

RobG wrote:
[...][color=blue]
> And that is the primary reason why browser developers faked UA strings
> in the first place (heck, IE used to masquerade as Netscape).[/color]

Much to the chargrin of those who wish it to be reliable for perfectly
honourable reasons.

--
Zif

re: browser tests

Jimnbigd wrote:[color=blue]
> What is the recommended code to test browser type, for conditional
> processing in Javascript?[/color]

There are no recommended tests for browser type or version. Indeed the
recommendation is not to care about the browser type or version at all,
because it is impossible to acquire that information.

Conditional execution tests are determined by reason for making the
execution conditional. So, for example, if one branch in code is going
to use a set of features that are only supported by a sub-set of
browsers then the test that controls the branching should be verifying
the existence of those features in the current execution environment
(and possible aspects of the behaviour of those features). So, for
example, given a desire to read the scroll offsets of a document, one
group of browsers will make that information available as global
pageXOffset
and pageYOffset properties, which would be numeric where implemented and
undefined otherwise. The test would be:-

if('number' == pageXOffset){
...// code that reads global pageX/YOffset
}

- and the block of the if statement would never be executed in an
environment that does not implant the specific feature of interest.
And - else - branches with other conditional tests could test for
alternative features and conditions that apply to other environments,
again testing for the features/conditions that represent the reason for
the existence of the branches.
[color=blue]
> I have seen tests for "document.all".[/color]

With the exception of code that tests for - document.all - as a
condition that has to be satisfied prior to the use of -
document.all -(only), that is termed "object inference"; The inferring
of all the features of an object model form a test on one particular
feature. Object inference is an invalid strategy because it is based on
invalid assumptions (that are more often than not actually untrue in
reality). The inference that a browser is Microsoft IE based on the
environment implementing - document.all - is particularly bogus.
[color=blue]
> I have seen tests for the actual browser name, or
> substrings in the browser name.[/color]

There is no available DOM property that represents the browser name. The
nearest being the much spoofed - navigator.appName -. Usually these
tests are based on the navigator.usetAgent - property, which reflects
the HTTP User-Agent header being used by the browser. HTTP 1.1
User-Agent headers are not specified as providing any information about
the client. And in reality User-Agent headers of different browsers are
often indistinguishable; they cannot be examine to provide
discriminating information, so the User-Agent header cannot be used to
identify the browser type or version.
[color=blue]
> What do you all recommend?[/color]

Feature detection, as no browser detection strategy works and in the
vast majority of cases feature detection does. Making Feature detection
a far superior strategy.

Richard.

re: browser tests

Zif wrote:[color=blue]
> RobG wrote:
> [...][color=green]
>> And that is the primary reason why browser developers
>> faked UA strings in the first place (heck, IE used
>> to masquerade as Netscape).[/color][/color]

IE still does masquerade as Netscape 4, it just does it in a way that
makes it obvious that it is really not Netscape 4, at least by default.
[color=blue]
> Much to the chargrin of those who wish it to be
> reliable for perfectly honourable reasons.[/color]

Not to the chagrin or those who wish to be reliable. Only to the chagrin
of those who wish to be reliable and have not yet learnt how to do that.

Richard.

re: browser tests

Richard Cornford wrote:
<snip>[color=blue]
> if('number' == pageXOffset){[/color]

Should be:-

if('number' == typeof pageXOffset){
^^^^^^
Richard.

re: browser tests

Richard Cornford wrote:[color=blue]
> Object inference is an invalid strategy because it is based
> on invalid assumptions (that are more often than not actually untrue
> in reality).[/color]

I've been working on a generalized (cross-browser) way of find the absolute
coordinates of an object on the page. There are a lot of quirks with
different browsers and CSS/positioning, and I've found no positioning script
so far that correctly considers objects with overflow:scroll when
calculating screen position (among other things). I've found that in order
to be accurate in as many browsers as possible, I need to use
feature/objection detection and infer other things based on that.

For example, looking for window.opera or document.compatMode and inferring
different quirks about how object positions are calculated. Opera already
consider's an element's scroll when it has overflow:scroll into the
offsetLeft/offsetTop values, while other browsers do not. So for other
browsers, you need to consider the scrollLeft/scrollTop values, while for
Opera you do not. I know of no way to "detect" this behavior other than
knowing a browser's behavior and attempting to infer that the browser in use
exhibits this behavior by examining its DOM.

Do you have a better idea?

--
Matt Kruse
http://www.JavascriptToolbox.com

re: browser tests

[color=blue]
> Richard Cornford wrote:
> Feature detection, as no browser detection strategy works and in the
> vast majority of cases feature detection does. Making Feature detection
> a far superior strategy.[/color]

Makes sense to me. I have always wondered about some of the scripts I have
seen that test for "document.all". Who knows -- Some day Netscape or
another browser might decide to support "document.all", and then everything
breaks. Thanks...Jim...

re: browser tests

Jimnbigd wrote:[color=blue][color=green]
>>Richard Cornford wrote:
>>Feature detection, as no browser detection strategy works and in the
>>vast majority of cases feature detection does. Making Feature detection
>>a far superior strategy.[/color]
>
>
> Makes sense to me. I have always wondered about some of the scripts I have
> seen that test for "document.all". Who knows -- Some day Netscape or
> another browser might decide to support "document.all", and then everything
> breaks. Thanks...Jim...[/color]

Case in point: Firefox already has 'undetectable' support for
document.all in quirks mode (and will also access elements by name & id
in global scope - send shivers up your spine?).


--
RobG