things missing from the FAQs: which browser is this

L

Lee

lawrence said:
How is it possible that the question "How do I detect which browser
the user has" is missing from this FAQ:

http://www.faqts.com/knowledge_base/index.phtml/fid/125

and is only here on this with a link to old information that suggests
use of "navigator":


http://developer.irt.org/script/43.htm

Because it's generally a bad idea to try to guess which browser
the user has. That's rarely useful information. Different
versions of the same browser may be very different, and the same
version may behave differently on different platforms or with
different user preferences. The navigator attribute can't be
trusted even to reliably report the browser name.

It's better to detect whether or not the browser your code is
running in supports whatever specific features you're interested
in.
 
K

kaeli

How is it possible that the question "How do I detect which browser
the user has" is missing from this FAQ:

http://www.faqts.com/knowledge_base/index.phtml/fid/125

Browser detection for anything other than IE using the proprietary IE
conditional code is bound to fail horribly.
They should have that question there with all the reasons why one *shouldn't*
do it.

No one with any experience does browser detection any more. That's a
throwback from the days when only IE and Netscape were around.
Use object detection instead.

--
--
~kaeli~
Murphy's Law #2030: If at first you don't succeed, destroy
all evidence that you tried.
http://www.ipwebdesign.net/wildAtHeart
http://www.ipwebdesign.net/kaelisSpace
 
M

Michael Winter

[snip]
<testing recently gained knowledge>
The term 'object detection' should really be changed to
'feature detection', as to say 'object detection' without
qualification leads to confusion between 'feature detection'
and 'object inference'* ( which is a bad thing, ..mmkay? ;-).
</testing recently gained knowledge>

I'd agree that it's a better term. Feature detection applies to testing
the presence - and possibly the behaviour - of objects, methods and
properties. Object detection seems more limited in scope.

[snip]

Mike
 
K

kaeli

[snip]
<testing recently gained knowledge>
The term 'object detection' should really be changed to
'feature detection', as to say 'object detection' without
qualification leads to confusion between 'feature detection'
and 'object inference'* ( which is a bad thing, ..mmkay? ;-).
</testing recently gained knowledge>

I'd agree that it's a better term. Feature detection applies to testing
the presence - and possibly the behaviour - of objects, methods and
properties. Object detection seems more limited in scope.

[snip]

Can one of you lovely gentlemen explain the difference please?

I know what *I* meant, but I'm not sure what you all mean. *smiles*

Is this object or feature detection:

if (document.getElementById)
{
e = document.getElementById("myDiv");
if (e.style.visibility)
{
e.style.visibility = "hidden";
}
}

To me, it's object detection, since I'm testing for objects and properties of
objects.
Feature detection seems too much like looking for plugins, to me, anyways. If
someone said "Feature detection", I'd think of Flash and applets, not DOM.
Could be my bad, though. My brain breaks now and then.

--
 
M

Michael Winter

Can one of you lovely gentlemen explain the difference please?

We're not being too pedantic, are we? :p
I know what *I* meant, but I'm not sure what you all mean. *smiles*

We all mean the same thing. :)

The debate here is that the phrase, object detection, seems too much like,
object inference. The latter being a form of browser detection which uses
one or more objects that the author thinks is unique to a browser (and
usually isn't).
Is this object or feature detection:

I'd call it feature detection because you're not just looking at objects.
I also think it gives the clear indication that you're looking at the user
agent's capabilities.
if (document.getElementById)
{
e = document.getElementById("myDiv");
if (e.style.visibility)

I assume that this was a quick example, but I thought I'd mention that
that test might fail even when the visibility property is supported.
That's because the value could be an empty string, indicating that there
is no inline style in effect, and evaluate as false. Moreover, is misses a
crucial test: is the style object supported?

I'd write:

if(e && e.style) {

If that test passes, you can write to the visibility property. Nothing may
actually happen when you do so, but you can't really tell if it would,
anyway. If you did want an explicit check for the property, add

&& ('string' == e.style.visibility)

By this point, it might be worth saving a reference to the style object to
reduce look-ups.

[snip]
To me, it's object detection, since I'm testing for objects and
properties of objects.
Feature detection seems too much like looking for plugins, to me,
anyways. If someone said "Feature detection", I'd think of Flash and
applets, not DOM.
Could be my bad, though. My brain breaks now and then.

I suppose everyone reads into it a different way. The main thing would be
to make clear what the objective is: to test for functionality before
using it. As long as that message gets across, the method of delivery is
less important.

Mike
 
K

kaeli

We're not being too pedantic, are we? :p

Who, me?
*heh*
We all mean the same thing. :)

The debate here is that the phrase, object detection, seems too much like,
object inference. The latter being a form of browser detection which uses
one or more objects that the author thinks is unique to a browser (and
usually isn't).

Ah, okay.
I know what you mean, but have never heard that term for it. I just
considered it a really bad way of doing browser detection. Actually, it's the
way I see it most, aside from the navigator object. And it usually fails
utterly in older versions of Opera, notably. *laughs*
I'd call it feature detection because you're not just looking at objects.
I also think it gives the clear indication that you're looking at the user
agent's capabilities.


I assume that this was a quick example,

It was. A really, really quick example. I'd normally test for style, too.
But the tip about the empty string was interesting. I didn't think about that
one. Actually, I don't use the style object at all for my stuff, but couldn't
think of a quicker example to type at the time. *grins*

I still like the term 'object detection' better. Probably because I'm weird.

--
 
R

Randy Webb

kaeli wrote:

Can one of you lovely gentlemen explain the difference please?

Object Detection, you are checking for the existence of an object, not
its methods. With feature detection (which I think should be called
"method detection") is when you are checking for a feature/method.
I know what *I* meant, but I'm not sure what you all mean. *smiles*

Is this object or feature detection:

if (document.getElementById)

feature detection.
{
e = document.getElementById("myDiv");

if (e)

object detection.
if (e.style.visibility)

Thats checking for a property.
{
e.style.visibility = "hidden";
}
}

To me, it's object detection, since I'm testing for objects and properties of
objects.
Feature detection seems too much like looking for plugins, to me, anyways. If
someone said "Feature detection", I'd think of Flash and applets, not DOM.
Could be my bad, though. My brain breaks now and then.

If I could get my brain to work more than 2% of the time, I would be
overly ecstatic :)
 
D

Dr John Stockton

JRS: In article <[email protected]>, dated Fri, 1 Oct 2004
01:52:52, seen in Lee
lawrence said:

Because it's generally a bad idea to try to guess which browser
the user has. That's rarely useful information.
...

That's an invalid refutation.

"How do I detect which browser the user has" *is*, in those or
sufficiently similar words, a frequently-enough asked question;
therefore, there should be a subject line in Sec. 4 that manifestly
corresponds - and the OP's wording seems as good as any (except that
"has" should be "is using"; consider "which browser does LRN have?").

Compare Section 4.1, "How do I protect my javascript code?".

The answer *should* include something on browser detection, since the
identity claim of the browser may be of legitimate interest whatever the
browser might be.

IMHO, a browser claiming to be FrogSpawn v.19 has a valid claim
to be treated as such; a user is entitled to the consequences of
his choices (note that, using feature detection, a page can be
made to show "You claim to be using FrogSpawn v.19; since method
'window.tadPole' does not exist, that is a manifest
terminological inexactitude.").

It's only nasty commercial sites that insist on ignoring such
statements in order to force their content through.

But the answer should include a paragraph on the merits of feature
detection, with perhaps a link to more detail, perhaps in the Notes.

IMHO, the FAQ should include a complete list of the Notes, linking.

I now see the Subject of 4.26 - it is too specific.

Sec 4.12 "Why does parseInt('09') give an error?" should cite 4.21, with
a statement that parseInt is used too often.
 
R

Richard Cornford

Can one of you lovely gentlemen explain the difference please?

I know what *I* meant, but I'm not sure what you all mean.
*smiles*
<snip>

In English the meanings of words, labels and terms are determined by no
more than what people use them to mean. And very few words or terms have
a single distinct meaning anyway. Meanings change with time and usage
and, while you can regret the corruption of the meanings of word as they
change, there is nothing that can be done to stop it. People also
suggest and invent new terms, some of which may be seen as preferable to
those currently in use and so become more widely adopted



This doesn't really matter, as the important thing is being able to
communicate. So, so long as I understand what is meant communication has
successfully happened, and if not I can ask for clarification.



The insistence upon the application of over-literal rigid definitions to
ordinarily communication (as opposed to technical specifications) that
characterises, for example, many of Thomas Lahn's posts, seriously gets
in the way of communication. Partly because arguing about the meaning of
words in English is infinitely recursive (as all words are defined with
words, which can themselves be subject to the same arguments), but
mostly because people expect some level of co-operation in understanding
from the person they are communication with and get frustrated when the
recipient isn't willing to try to understand.



This makes me unwilling to insist that any particular set of terms
represent the true and correct labels for use in this context. When I
read regulars on this group suggesting "object detection" I know what is
meant, because I know they are not advocating what I would currently
term 'object inference'.



However, I do have a strong attitude toward which terms are best suited
to the various activities and strategies that apply to browser
scripting. So I apply that attitude to what I write on the subject and
would leave it to others to make up their own minds as to whether my
preferred terminology best suits the situation.



The primary context for the application of this terminology is the
handling of the variations in the execution environment of browser
scripts. That is; the strategy used to cope with the fact that an
Internet browser script must be written without any foreknowledge of the
environment in which it may be executed.



The attempted strategies have been:-



1. Ignoring to problem and writing for some individual
browser/browser

version(s) + browser configuration(s) that appear to satisfy some

ill-defined (usually "statistical") criteria.

2. Browser detecting; by UA string or by object inference
(sometimes

termed 'object detection' in this context).

3. Attempting to match the behaviour of scripts to the specific
capabilities

of any web browser by examining the execution environment to see
if

it provides the facilities that the script would like to employ.



The third strategy is currently the preferred approach to the creation
of cross-browser Internet scripts. The first obviously never results in
a cross-browser script and the second is demonstrably unreliable to the
point of being useless, while the third (properly applied) can get the
maximum out of any browser environment while doing the most to
facilitate controlled 'clean degradation' (another term we could argue
about the exact meaning of).



Applying labels to those strategies is convenient and useful when
talking about them. We don't really need a label for the first, though
it might be refereed to as "Intranet scripting" (the alternatives being
somewhat unkind ;-). The second can be lumped together behind the term
"browser detection" (as that is a well established, self-explanatory and
fairly obvious term to use). The third being variously labelled "feature
detection" and "object detection".



My preference is to apply the label "feature detection" when talking
about the *strategy* for handling the differences between browsers. I
prefer it in part because the actual testing done in order to implement
the strategy is not restricted to objects (or even objects + methods,
which are both objects in ECMAScript terms anyway), but mostly because
searching the internet for "object detection" will turn up web pages
that describe the problems with browser detection by user agent string
and then go on to advocate browser detection by 'object inference',
applying the label "object detection" to that approach. This makes me
think that a distinct term is needed for a distinct strategy.



The next level of the application of the terminology under discussion is
to the testing itself. And this is where the term 'object inference'
enters the picture. As I recall it was Lasse Reichstein Nielsen who
first described an example test as "object inference", and I like that
term as it implies that the test is indirect. However, 'object
inference' features in both the 'browser detection' and 'feature
detection' strategies. It is the wrong approach for 'feature detection'
(as a strategy for handling browser differences) as there is always a
more direct test available.



So we have:-



isIE5Pluss = Boolean(document.all && document.getElementById);



- which is 'browser detection' by object inference, and:-



if(document.images){

img = new Image();

img.src = 'some.gif';

}



- which is an attempt to match the execution of code to the environment,
so a 'feature detection' strategy, but it is a test that infers the
existence of one feature from the existence of another.



Unfortunately a search of the Internet for "object detecting" will also
turn up pages that talk about the unreliability of browser detecting and
propose 'object detecting' as an alternative, but then go on to list
examples of this type of object inference testing as object detection.



The 'correct' alternative test would be something like:-



if(window.Image){ // or:- if(typeof Image == 'function'){

img = new Image();

img.src = 'some.gif'

}



- and I would label that 'feature detection'. It is a test of an object
(assuming functions are to be classed as objects, as per ECMAScript's
internal attitude towards them) but the distinction that I see as
significant is that this test has a direct one-to-one relationship
between the test made (the object tested) and the code that is to employ
the result of that test.



"Feature detection" is also a good term to be used to describe the test
used to implement a "feature detection" strategy in cross-browser
scripting because testing can involve subjects considerably more diverse
than just objects (including or excluding functions and methods).



Code such as:-



if(typeof normalisedStyleObject.display == 'string'){

// assume the switching of the display property is

// available in this environment.

}else{

// don't expect this environment to support display switching.

}



-or:-



if(!('a'.replace(/a/, (function(){return '';})))){

... //function references OK with String.replace method.

}else{

... //no function references with replace method.

}



- are tests of a browser environment to examine its level of support for
something, that could not be easily categorised as 'object detection'
tests as they do not test objects at all. Rather a property in the first
case and a method's behaviour in the second. They do qualify as tests
where the environment's support for a particular feature is examined in
a way that is directly related to that feature. Making them well suited
to an implementation of a 'feature detection' strategy, and so 'feature
detection' tests.



Taking 'feature detection' as a label for tests suited to the
implementation of a 'feature detection' strategy, 'object detection'
(and 'method detection', and others) could be regarded as appropriate
labels for sub-sets of 'feature detection' tests. Though I would still
be inclined not to use the term 'object detection' in this context
because of its use in the other contexts previously mentioned.



When I use these terms I mean something along the lines of the
following:-





Browser Detection.

A strategy for handling the differences in
the execution environments of web browsers where an attempt is made to
match the script code executed to a set of known environments by
identifying the browser in which the script is executing.

Originally attempted through the examination of properties of the
browser's 'navigator' object, particularly the 'userAgent' string but
because those properties ceased to discriminating as more browsers came
into existence the thrust of the browser detection strategy shifted to
examining the browser's environment for features (objects) considered to
be indicative of a single browser type (see: Object Inference).

Currently deprecated as a practice because it is demonstrable that
scripts do not have access to sufficiently discriminating information to
allow accurate browser identification, and/or scripts authors do not
have knowledge of the range of browsers necessary to accurately identify
features that could be genuinely indicative of particular
types/versions.



Feature Detection.

1. A strategy for handling the differences
in the execution environments of web browsers where an attempt is made
to match the script code executed to the browser's ability to facilitate
its requirements by the application of direct testing to various
features of the environment needed by the individual script.

Currently considered the only viable strategy for the handling of
the differences between browser environments that is required by
cross-browser scripting.

2. Any test applied to a property, method,
object, etc, the behaviour of such, or the outcome of the use of such,
that is used to control the execution (and clean degradation) of
client-side javascript code, where the test performed has (to the
maximum extent possible) a direct (preferably one-to-one) relationship
with the code that would be executed as a result of the test.



Object Inference.

A style of testing in which the behaviour
facilitated by a client-side execution environment (or aspects of that
environment) is inferred from the results of tests made on a limited
sample of features of that environment, or on features that are only
related to those subsequently employed in the script by an observed
coincidence in a limited set of browsers.

Often employed in Browser Detection or as an (Inappropriate)
implementation of Feature Detection (1) which fails to satisfy the
desire for Feature Detection (2) tests to have a close/direct
relationship with the code executed as a result of those test.





Given those definitions a definition of 'object detection', based on the
various ways in which the term has been used might go:-





Object Detection.

1. A strategy for handling the differences in
the execution environments of web browsers where an attempt is made to
match the script code executed to the browser's ability to facilitate
its requirements by the application of testing to various features of
the environment (see: Feature Detection (1)).

2. A style of Browser Detection in which the
type and/or version of the browser is inferred by testing for a limited
set of features considered indicative of that browser (see: Object
Inference and Browser Detection).

3. Any test applied to a property, method,
object, etc, the behaviour of such, or the outcome of the use of such,
that is used to control the execution (and clean degradation) of
client-side javascript code (See: Feature Detection (2)).

4. A sub-set of Feature Detection (2) testing
in which the subject of the tests are objects (possibly including
functions/methods as those are Objects in ECMAScript).

5. A style of testing in which an aspects of
a client-side execution environment is inferred from the results of test
made on a feature of that environment that is only related to any
subsequently executed code by an observed coincidence in a limited set
of browsers (see: Object Inference).





Given such a wide ranging possible definition I can know what is meant
when I see the term 'object detection' used (by individuals who I know
to understand the issues sufficiently to be using definitions 1 and 3)
but it concerns me that individuals without previous experience who
attempt to research the subject on the Internet might encounter
information that would turn good advice into misdirection. So I won't
use 'object detection' to describe anything, and instead I will employ
terminology that is more descriptive (and/or less abused).



However, the observation that 'object inference' is a relatively
recently coined term in this context, and an appreciation that the
labels applied are ultimately nominal, leaves me open to suggestions of
other, and better, terminology to apply to our context.

Richard.
 
D

Dr John Stockton

JRS: In article <[email protected]>, dated Sat, 2 Oct 2004
09:27:37, seen in Lee
Dr John Stockton said:


Wasn't intended as such, but rather as an explanation
for why it doesn't appear there. In general, we're more
likely to document how to do things, rather than what not
to try.

But it is what readers want to do that they will be seeking; so such
should be provided as subject lines (or in a "Bad Ideas, and What To Do
Instead" section, linking to the appropriate 'real' entries). One must
remember what FAQ stands for, and that a FAQ is not itself a tutorial.
 
L

lawrence

kaeli said:
Browser detection for anything other than IE using the proprietary IE
conditional code is bound to fail horribly.
They should have that question there with all the reasons why one *shouldn't*
do it.

No one with any experience does browser detection any more. That's a
throwback from the days when only IE and Netscape were around.
Use object detection instead.

Nice. Real good to know. Kind of confusing. But I'll get used to it.
 
T

Thomas 'PointedEars' Lahn

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,483
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top