browsers & standards

[abracad_1999]

I'm told the standards way of referencing page content is
document.getElementById()

What is the lowest version of each browser type with which this will
work?

Thank you

[Randy Webb]

ab**********@yahoo.com said the following on 11/6/2005 4:54 PM:

I'm told the standards way of referencing page content is
document.getElementById()

What is the lowest version of each browser type with which this will
work?

The lowest version that will support it is the lowest version that will
pass this test:

if (document.getElementById)

Meaning, you do object/feature detection and it doesn't matter.

--
Randy
comp.lang.javascript FAQ - http://jibbering.com/faq & newsgroup weekly
Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/

[Mick White]

ab**********@yahoo.com wrote:

I'm told the standards way of referencing page content is
document.getElementById()

What is the lowest version of each browser type with which this will
work?

Even the most recent browsers may not support it. You need to test for it

if(document.getElementById){// do stuff with document.getElementById()}

Mick

[RobG]

ab**********@yahoo.com wrote:

I'm told the standards way of referencing page content is
document.getElementById()

What is the lowest version of each browser type with which this will
work?

General advice is that getElementById is supported by most browsers that
emerged *after* Netscape 4 and IE 4. Nearly all browsers that have been
released in the last few years support it - it's more widely supported
than document.all and document.layers is pretty much dead.

But take heed of Randy & Mick's advice: just because a browser is new or
supports JavaScript does not mean it supports any particular method or
interface, which seems to be particularly true of mobile browsers.
Feature detection and graceful fall-back is always required.

There are other ways of getting references to elements that may be more
appropriate depending on the circumstance such as the links, images and
forms collections or traversing the DOM (parent & child nodes, siblings,
etc.).
--
Rob

[Gérard Talbot]

ab**********@yahoo.com a écrit :

I'm told the standards way of referencing page content is
document.getElementById()

What is the lowest version of each browser type with which this will
work?

These references answer all your questions and more:

Using Web Standards in Your Web Pages
http://www.mozilla.org/docs/web-deve...upgrade_2.html

Accessing Elements with the W3C DOM:
http://www.mozilla.org/docs/web-deve...tml#dom_access

Gérard
--
remove blah to email me

[Dr John Stockton]

JRS: In article <Wt********************@comcast.com>, dated Sun, 6 Nov
2005 17:03:37, seen in news:comp.lang.javascript, Randy Webb
<Hi************@aol.com> posted :

ab**********@yahoo.com said the following on 11/6/2005 4:54 PM:

I'm told the standards way of referencing page content is
document.getElementById()

What is the lowest version of each browser type with which this will
work?

The lowest version that will support it is the lowest version that will
pass this test:

if (document.getElementById)

Meaning, you do object/feature detection and it doesn't matter.

One may not be able to do object/feature detection.

It can be used in javascript so that the javascript knows whether to use
the native method or to use some emulation.

It cannot be used in a code review meeting when Big Boss asks "What is
the lowest version of each browser type with which this code will work?"
unless each browser type, in all versions, and the time to do the tests,
are available at the meeting.

One should always consider the actual meaning of the question asked;
and, if possible, answer that in addition to answering the question as
it *might* better have been asked.

If the answer is equivalent to "all browser releases since 1999/01/01,
and some earlier", and Big Boss has a Policy of ignoring all twentieth-
century browsers, then the answer to Big Boss's question could be "Don't
know, Sir; but I do know that it works with all that, according to
Policy, it needs to work with, Sir.".

I expect that your test process will be perfectly satisfactory in code
for getElementById; but it will not be entirely satisfactory for
toFixed, since for that it is known (FAQ 4.6) that "works right" is a
subset of "exists".

<FAQENTRY> to enable sound feature detection on toFixed, ISTM that the
FAQ should indicate a test value that can be used to prove toFixed to be
good, or at least to have no known error. 0.77.toFixed(0) may be such a
test, or a part thereof.

--
© John Stockton, Surrey, UK. ?@merlyn.demon.co.uk Turnpike v4.00 IE 4 ©
<URL:http://www.jibbering.com/faq/> JL/RC: FAQ of news:comp.lang.javascript
<URL:http://www.merlyn.demon.co.uk/js-index.htm> jscr maths, dates, sources.
<URL:http://www.merlyn.demon.co.uk/> TP/BP/Delphi/jscr/&c, FAQ items, links.

[Randy Webb]

Dr John Stockton said the following on 11/7/2005 8:48 AM:

JRS: In article <Wt********************@comcast.com>, dated Sun, 6 Nov
2005 17:03:37, seen in news:comp.lang.javascript, Randy Webb
<Hi************@aol.com> posted :

ab**********@yahoo.com said the following on 11/6/2005 4:54 PM:

I'm told the standards way of referencing page content is
document.getElementById()

What is the lowest version of each browser type with which this will
work?
The lowest version that will support it is the lowest version that will
pass this test:

if (document.getElementById)

Meaning, you do object/feature detection and it doesn't matter.

One may not be able to do object/feature detection.

Example of not being able to object/feature detect? I know you can't
test for try/catch but I am unaware of anywhere that you can not
object/feature detect document.getElementById even if it is emulated.
And in order to emulate it, you *must* be able to understand the
emulation, and in understanding it, the OQ would never have been asked.
It can be used in javascript so that the javascript knows whether to use
the native method or to use some emulation.
And again, it order to be able to emulate it, you would have to know the
alternatives to it and be able to write that emulation. If you can
emulate it, you don't have to ask where it is supported. And even then,
you do not *ever* need to know the browser version to determine it.
It cannot be used in a code review meeting when Big Boss asks "What is
the lowest version of each browser type with which this code will work?"
unless each browser type, in all versions, and the time to do the tests,
are available at the meeting.
"Big Boss, that question can not be answered truthfully, but I can
programatically determine if a browser supports it, without errors in
the code if it doesn't".

Either Big Boss will understand that, or, s/he wouldn't know if you were
lying even if you weren't.
One should always consider the actual meaning of the question asked;
and, if possible, answer that in addition to answering the question as
it *might* better have been asked.
IE4, with an updated JS engine, supports gEBI. It is not the browser
version but rather the scripting engine that determines support or lack
thereof.
If the answer is equivalent to "all browser releases since 1999/01/01,
and some earlier", and Big Boss has a Policy of ignoring all twentieth-
century browsers, then the answer to Big Boss's question could be "Don't
know, Sir; but I do know that it works with all that, according to
Policy, it needs to work with, Sir.".
If Big Boss has enough sense/knowledge to ask the question in the first
place, he should have enough sense/knowledge to know the answer, or
where to find it. Your example is lacking.
I expect that your test process will be perfectly satisfactory in code
for getElementById; but it will not be entirely satisfactory for
toFixed, since for that it is known (FAQ 4.6) that "works right" is a
subset of "exists".
Yes, and that is why it is in the FAQ. But since I don't use, and have
no need, for toFixed, it doesn't matter to me.
<FAQENTRY> to enable sound feature detection on toFixed, ISTM that the
FAQ should indicate a test value that can be used to prove toFixed to be
good, or at least to have no known error. 0.77.toFixed(0) may be such a
test, or a part thereof.

The thread started just yesterday about FAQ Updates would have been a
better place for that. It would have gotten immediate attention and it
has *nothing* to do with this thread.

Second, since toFixed is known to be buggy, and it has a prototype
solution, the best solution to that problem is not to test for but
rather to simply prototype anyway and then you don't have to worry about
it anymore. Besides, it would execute faster without the testing.

--
Randy
comp.lang.javascript FAQ - http://jibbering.com/faq & newsgroup weekly
Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/

[Matt Kruse]

Dr John Stockton wrote:

One may not be able to do object/feature detection.
...
<FAQENTRY> to enable sound feature detection on toFixed, ISTM that the
FAQ should indicate a test value that can be used to prove toFixed to
be good, or at least to have no known error. 0.77.toFixed(0) may be
such a test, or a part thereof.

I think most people understand that feature detection can only decide if
features are available. There is, of course, no way to determine if a
feature behaves according to standards or expectations. This is definitely a
limitation of the "feature detection" strategy. In some cases, in addition
to using feature detection, it can be required to do browser detection to
sort through quirks in implementations of features in specific browsers.

IMO, though, if a browser implements a feature but does so incorrectly, and
the user sees an error, that doesn't bother me. If a browser has bugs, the
user should either live with it, upgrade, or pick a different browser. The
only exception, unfortunately, is IE. It has bugs and quirks, but it's so
widely used that they almost certainly need to be taken into consideration.

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

[Thomas 'PointedEars' Lahn]

Matt Kruse wrote:

Dr John Stockton wrote:

One may not be able to do object/feature detection.
...
<FAQENTRY> to enable sound feature detection on toFixed, ISTM that the
FAQ should indicate a test value that can be used to prove toFixed to
be good, or at least to have no known error. 0.77.toFixed(0) may be
such a test, or a part thereof.

I think most people understand that feature detection can only decide if
features are available. There is, of course, no way to determine if a
feature behaves according to standards or expectations.

That assumption is not generally true and it does not apply here.
One can test if Number objects have the toFixed() method and one
can test if it returns the expected result on a selected fixed
number before applying it to a variable.
PointedEars

[Randy Webb]

Thomas 'PointedEars' Lahn said the following on 11/8/2005 2:51 PM:

Matt Kruse wrote:

Dr John Stockton wrote:

One may not be able to do object/feature detection.
...
<FAQENTRY> to enable sound feature detection on toFixed, ISTM that the
FAQ should indicate a test value that can be used to prove toFixed to
be good, or at least to have no known error. 0.77.toFixed(0) may be
such a test, or a part thereof.

I think most people understand that feature detection can only decide if
features are available. There is, of course, no way to determine if a
feature behaves according to standards or expectations.

That assumption is not generally true and it does not apply here.
One can test if Number objects have the toFixed() method and one
can test if it returns the expected result on a selected fixed
number before applying it to a variable.

But that still won't guarantee that it will work in all instances.

--
Randy
comp.lang.javascript FAQ - http://jibbering.com/faq & newsgroup weekly
Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/

[Matt Kruse]

Thomas 'PointedEars' Lahn wrote:

One can test if Number objects have the toFixed() method and one
can test if it returns the expected result on a selected fixed
number before applying it to a variable.

You can test that it works as expected in your pre-determined test case, but
you can't be sure it will behave the same way when applied to your variable.
That's the nature of browser quirks and bugs, after all.

Plus, testing for the existence of a feature and then testing it on a known
test case before using it would certainly add to code bloat and slow down
code execution.

And would you propose testing the accuracy of every method? For example, how
would you check for the accuracy of getElementById? Wouldn't that be
over-kill? And if so, how would you decide which methods to test and which
methods not to test?

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

[Dr John Stockton]

JRS: In article <Js******************************@comcast.com>, dated
Mon, 7 Nov 2005 17:55:15, seen in news:comp.lang.javascript, Randy Webb
<Hi************@aol.com> posted :

Dr John Stockton said the following on 11/7/2005 8:48 AM:

JRS: In article <Wt********************@comcast.com>, dated Sun, 6 Nov
2005 17:03:37, seen in news:comp.lang.javascript, Randy Webb
<Hi************@aol.com> posted :

Meaning, you do object/feature detection and it doesn't matter.

One may not be able to do object/feature detection.

Example of not being able to object/feature detect?

It was given in the paragraph "It cannot ...". Please read and
*understand* an article in full before starting to reply.

It cannot be used in a code review meeting when Big Boss asks "What is
the lowest version of each browser type with which this code will work?"
unless each browser type, in all versions, and the time to do the tests,
are available at the meeting.

"Big Boss, that question can not be answered truthfully, but I can
programatically determine if a browser supports it, without errors in
the code if it doesn't".

Either Big Boss will understand that, or, s/he wouldn't know if you were
lying even if you weren't.

The question can be answered truthfully if the programmer is well-
prepared; as I indicated, it can be answered exactly enough for
practical purposes and its limitations if any indicated.

And he will understand that it is not the answer to the question asked.
He may well have asked the question because he wanted an answer to it.
If it is a final review, your answer cannot indicate whether the product
is actually ready for release. A proper answer would do so.

One should always consider the actual meaning of the question asked;
and, if possible, answer that in addition to answering the question as
it *might* better have been asked.

In particular, the OP's actual question cannot be answered by advice to
feature detect unless he has access to "each browser".

--
© John Stockton, Surrey, UK. ?@merlyn.demon.co.uk Turnpike v4.00 IE 4 ©
<URL:http://www.jibbering.com/faq/> JL/RC: FAQ of news:comp.lang.javascript
<URL:http://www.merlyn.demon.co.uk/js-index.htm> jscr maths, dates, sources.
<URL:http://www.merlyn.demon.co.uk/> TP/BP/Delphi/jscr/&c, FAQ items, links.

[Thomas 'PointedEars' Lahn]

Matt Kruse wrote:

Thomas 'PointedEars' Lahn wrote:

One can test if Number objects have the toFixed() method and one
can test if it returns the expected result on a selected fixed
number before applying it to a variable.
You can test that it works as expected in your pre-determined test case,
but you can't be sure it will behave the same way when applied to your
variable.

But I can be pretty much sure then. For example, it is highly unlikely
that a toFixed() method that correctly returns a 3-digit number will not
return an appropriate 2-digit number if passed `2' instead of `3'.
That's the nature of browser quirks and bugs, after all.
It would be quirks and bugs of the language implementation here.
Plus, testing for the existence of a feature and then testing it on a
known test case before using it would certainly add to code bloat and
slow down code execution.
In client-side scripting, that is always a part of the bargain required
for a result that is stable in most cases.
And would you propose testing the accuracy of every method? For example,
how would you check for the accuracy of getElementById?
I don't need to. It is specified that (if it can be called) it returns
either an object reference if there is an element with that ID, `null' if
there is no such element or an undefined value otherwise. If it does not
return what I expect, I have to consider the DOM tree or itself to be
broken and have to move on to the next probably viable DOM accessing
method if there is any.
Wouldn't that be over-kill?
It would simply be not possible. As I wrote before, if either the vendor
or the user decides to cripple the language or the DOM, I seldom can do
anything about it (some techniques have their equivalents, some have not).
So it is a waste of resources to bother with it.
And if so, how would you decide which methods to test and which methods
not to test?

Using past experience to determine the cases that would probably cause
problems under certain circumstances.
PointedEars

[Dr John Stockton]

JRS: In article <dk*********@news4.newsguy.com>, dated Tue, 8 Nov 2005
09:58:14, seen in news:comp.lang.javascript, Matt Kruse
<ne********@mattkruse.com> posted :

Dr John Stockton wrote:

One may not be able to do object/feature detection.
...
<FAQENTRY> to enable sound feature detection on toFixed, ISTM that the
FAQ should indicate a test value that can be used to prove toFixed to
be good, or at least to have no known error. 0.77.toFixed(0) may be
such a test, or a part thereof.

I think most people understand that feature detection can only decide if
features are available. There is, of course, no way to determine if a
feature behaves according to standards or expectations.

There is *no* reasonable way to tell reliably whether a feature works as
expected under *all* circumstances. And that applies to *all* features
(remember how Easter Eggs are often invoked).

An anti-French browser writer could, for example, impose a limit on the
number of cedillas on a page. Or 4195835/3145727 might give
1.333739068902037589.

However, where it is known that a particular "error" occurs, and that
error affects more than just rendering, it can easily be tested for.

AIUI, new Date(1e12).getYear() may return any of 2001, 101, 1 (example
of the last requested). It's perfectly easy to test which it gives, and
to adapt operations accordingly (though there are better solutions in
that case).

I think that OK = !!+(0.77.toFixed(0)) is a sound test for the
goodness of toFixed() - but I cannot confirm that, whereas the FAQ
writer might know or ask to be told, and then we could all know.

--
© John Stockton, Surrey, UK. ?@merlyn.demon.co.uk Turnpike v4.00 IE 4 ©
<URL:http://www.jibbering.com/faq/> JL/RC: FAQ of news:comp.lang.javascript
<URL:http://www.merlyn.demon.co.uk/js-index.htm> jscr maths, dates, sources.
<URL:http://www.merlyn.demon.co.uk/> TP/BP/Delphi/jscr/&c, FAQ items, links.

[Randy Webb]

Dr John Stockton said the following on 11/8/2005 10:42 AM:

JRS: In article <Js******************************@comcast.com>, dated
Mon, 7 Nov 2005 17:55:15, seen in news:comp.lang.javascript, Randy Webb
<Hi************@aol.com> posted :

Dr John Stockton said the following on 11/7/2005 8:48 AM:

JRS: In article <Wt********************@comcast.com>, dated Sun, 6 Nov
2005 17:03:37, seen in news:comp.lang.javascript, Randy Webb
<Hi************@aol.com> posted :
Meaning, you do object/feature detection and it doesn't matter.

One may not be able to do object/feature detection.
Example of not being able to object/feature detect?

It was given in the paragraph "It cannot ...". Please read and
*understand* an article in full before starting to reply.

I would, if you would post an argument that makes a half an ounce of
sense John. You came up with a wild ass theoretical situation that just
doesn't happen in the real world.

<snip>
In particular, the OP's actual question cannot be answered by advice to
feature detect unless he has access to "each browser".

Nonsense. I do not need access to "each browser" to do feature
detection. That is the sole purpose of feature detection is to prevent
me from having to test in every browser.

--
Randy
comp.lang.javascript FAQ - http://jibbering.com/faq & newsgroup weekly
Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/

[Dr John Stockton]

JRS: In article <6s******************************@comcast.com>, dated
Thu, 10 Nov 2005 22:33:21, seen in news:comp.lang.javascript, Randy Webb
<Hi************@aol.com> posted :

Dr John Stockton said the following on 11/8/2005 10:42 AM:

JRS: In article <Js******************************@comcast.com>, dated
Mon, 7 Nov 2005 17:55:15, seen in news:comp.lang.javascript, Randy Webb
<Hi************@aol.com> posted :

Dr John Stockton said the following on 11/7/2005 8:48 AM: One may not be able to do object/feature detection.

Example of not being able to object/feature detect?

It was given in the paragraph "It cannot ...". Please read and
*understand* an article in full before starting to reply.

I would, if you would post an argument that makes a half an ounce of
sense John.

Your experience is finite.

Programmed feature detection can be used in code.

It can only be used in code.

That's what you've failed to recognise; there's a world outside your
coder's cubicle.

--
© John Stockton, Surrey, UK. ??*@merlyn.demon.co.uk Turnpike v4.00 MIME. ©
Web <URL:http://www.merlyn.demon.co.uk/> - FAQish topics, acronyms, & links.
Check boilerplate spelling -- error is a public sign of incompetence.
Never fully trust an article from a poster who gives no full real name.

[Richard Cornford]

Matt Kruse wrote:

Dr John Stockton wrote:

One may not be able to do object/feature detection.
...
<FAQENTRY> to enable sound feature detection on toFixed, ISTM
that the FAQ should indicate a test value that can be used
to prove toFixed to be good, or at least to have no known
error. 0.77.toFixed(0) may be such a test, or a part thereof.
I think most people understand that feature detection can
only decide if features are available.

What most people understand often significantly diverges from reality.
Feature detection is an environment testing strategy that certainly does
extend to the actual behaviour/characteristics of features in addition
to their mere existence.
There is, of course, no way to determine if a feature
behaves according to standards or expectations.
In many cases it is entirely possible to verify that a feature behaves
in accordance to the standards. It is rarely necessary to do so, and
such testing is likely to be impractical much of the time. For example,
having verified the precise behaviour of the mathematical functions and
operators involved it is possible to implement the toFixed algorithm and
test all of the possible parameters against all of the representable
numeric values looking for differences between its results and those of
Number.toFiexed, but that test would take lifetimes to run and so is
certainly not practical.

However, it is a mistake to think that verifying correct behaviour is
the problem here. It would be sufficient to identify aberrant behaviour.
And for that task a small number of tests on sample numbers to see if
they return the expected string values should be satisfactory.

This is particularly true in the case of toFixed as the observed issues
relate to the faulty behaviour of JScript's current implementation.
Specifically the way in which JScript's toFixed rounds down if the digit
after the last that is to be output is 5 to 9 while the digits above the
are all zero, a single test can identify that fault reliably. E,G.:-

if(0.0055.toFixed(2) != '0.01'){
... // erroneous toFixed implementation.
}

And that one test to identify known faults in JScript could be
meaningfully extended with a small number of samples of other boundary
conditions, such as a number on each side of rounding up and rounding
down, and each side of the transition across a whole number (with
precision appropriate to the application, i.e. toFixed(2) if
presenting currency amounts).
This is definitely a limitation of the "feature detection"
strategy.
If feature detection could only verify the existence of a feature then
that would be a limitation. As it can be applied to the behaviour of a
feature as well then this is not an example of a limitation. In this
case the impracticality of verifying 100% correct behaviour of toFixed
is significantly mitigated by being able to identify known incorrect
behaviour, and the alternative of using a function in its place that
does have known behaviour.
In some cases, in addition to using feature detection, it
can be required to do browser detection to sort through quirks
in implementations of features in specific browsers.
That the feature detection strategy does have limitations is undoubtedly
true. The main reason for its recommendation as a strategy is that it
has fewer limitations than all other available strategies. It is
certainly superior to browser detection in every sense. Mostly because
there is no browser detection strategy that can accurately and
discriminatingly identify all browsers.

In this particular case identifying the browsers that are known to be
problematic, IE versions, would be significantly less effective than the
feature detection test proposed above. That test will identify toFixed
implementations that exhibit the problem known to be exhibited by
current (and past) JScript versions. While even if you could identify
all IE browsers that have used those JScript versions (and I am yet to
see a browser detection test that could deliver that information) the
results of such a test would still be wrong if Microsoft release a
JScript 7 version with the issue fixed, as JScript can be retro-fitted
to older browsers. And again, even if you could identify all IE browsers
that exhibit the problem you will not be detecting other browsers that
have the same issue in their ECMAScript implementations.

In the past, and generally, when assertions that feature detection is an
inadequate strategy are rendered concrete it becomes apparent that
feature detection tests can be discriminatingly applied, and in the rare
cases where they cannot it has never been demonstrated that browser
detection could be applied to produce more discriminating results.
IMO, though, if a browser implements a feature but does so
incorrectly, and the user sees an error, that doesn't bother me.

<snip>

If you are rounding money presenting inaccurate information has
potentially serious legal consequences.

Richard.

[Matt Kruse]

Richard Cornford wrote:

Feature detection is an environment testing strategy that certainly
does extend to the actual behaviour/characteristics of features in
addition to their mere existence.
Would that not more accurately be called "Feature verification"?
To me, detecting something merely checks that it exists, not that it behaves
as expected.
In many cases it is entirely possible to verify that a feature behaves
in accordance to the standards.
Yes, and in many cases it is not possible.
That the feature detection strategy does have limitations is
undoubtedly true. The main reason for its recommendation as a
strategy is that it has fewer limitations than all other available
strategies. It is certainly superior to browser detection in every
sense.
Agreed. My point is, doing feature detection like

if (document.someFeature) { document.someFeature(); }

is merely detection, and cannot make any guarantee of correct results. In
fact, a browser could have the feature, but its use could throw an error
every time. Simple "feature detection" can't check that.
In this particular case identifying the browsers that are known to be
problematic, IE versions, would be significantly less effective than
the feature detection test proposed above.
Of course, but you're arguing against a point I'm not making.
In the past, and generally, when assertions that feature detection is
an inadequate strategy are rendered concrete it becomes apparent that
feature detection tests can be discriminatingly applied, and in the
rare cases where they cannot it has never been demonstrated that
browser detection could be applied to produce more discriminating
results.

In the cases where specific browser versions have bugs which cannot be
programmatically deduced by feature detection/verification, checking the
user agent being used (and assuming it's accurate) may allow some
functionality to behave correctly in those browsers also.

IMO, though, if a browser implements a feature but does so
incorrectly, and the user sees an error, that doesn't bother me.

If you are rounding money presenting inaccurate information has
potentially serious legal consequences.

If you are rounding money with javascript in a context where it may have
serious legal consequences, you're already making a big mistake!

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

[Randy Webb]

Dr John Stockton said the following on 11/12/2005 3:06 PM:

JRS: In article <6s******************************@comcast.com>, dated
Thu, 10 Nov 2005 22:33:21, seen in news:comp.lang.javascript, Randy Webb
<Hi************@aol.com> posted :

Dr John Stockton said the following on 11/8/2005 10:42 AM:

JRS: In article <Js******************************@comcast.com>, dated
Mon, 7 Nov 2005 17:55:15, seen in news:comp.lang.javascript, Randy Webb
<Hi************@aol.com> posted :
Dr John Stockton said the following on 11/7/2005 8:48 AM:
One may not be able to do object/feature detection.

Example of not being able to object/feature detect?
It was given in the paragraph "It cannot ...". Please read and
*understand* an article in full before starting to reply.
I would, if you would post an argument that makes a half an ounce of
sense John.

Your experience is finite.

As is yours. But that has nothing to do with this thread.
Programmed feature detection can be used in code.
Without a doubt.
It can only be used in code.
You are a master of the obvious John.
That's what you've failed to recognise; there's a world outside your
coder's cubicle.

This group, and its default assumption, is that questions are related to
scripting for the WWW, not for answering questions in a meeting. That is
what *you* failed to recognise. Besides, I don't have a cubicle, its a
~16x~24 office of my own.
--
Randy
comp.lang.javascript FAQ - http://jibbering.com/faq & newsgroup weekly
Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/

[Richard Cornford]

Matt Kruse wrote:

Richard Cornford wrote:

Feature detection is an environment testing strategy that
certainly does extend to the actual behaviour/characteristics
of features in addition to their mere existence.
Would that not more accurately be called "Feature verification"?

It is only a name.
To me, detecting something merely checks that it exists, not
that it behaves as expected.
The name has its roots in 'object detection' which was the preferred
term until it stated to be applied to - var ie = document.all; - style
browser detection. Feature detection may not be the optimum term to be
using.

In many cases it is entirely possible to verify that a feature
behaves in accordance to the standards.

Yes, and in many cases it is not possible.

But it always seems many fewer cases than some seem to think. You, for
example, have not raised any concrete cases that have not proved
amenable to feature detection once examined.

That the feature detection strategy does have limitations is
undoubtedly true. The main reason for its recommendation as a
strategy is that it has fewer limitations than all other
available strategies. It is certainly superior to browser
detection in every sense.

Agreed. My point is, doing feature detection like

if (document.someFeature) { document.someFeature(); }

is merely detection,

That certainly is detection alone.
and cannot make any guarantee of correct results.
But it can avoid erroneous actions, which is a much more significant
problem in most cases.
In fact, a browser could have the feature, but its
use could throw an error every time. Simple "feature
detection" can't check that.
No it cannot, but fortunately that just doesn't happen sufficiently
often for it to be a problem.

<snip>

In the past, and generally, when assertions that feature
detection is an inadequate strategy are rendered concrete
it becomes apparent that feature detection tests can be
discriminatingly applied, and in the rare cases where they
cannot it has never been demonstrated that browser detection
could be applied to produce more discriminating results.

In the cases where specific browser versions have bugs which
cannot be programmatically deduced by feature
detection/verification,

So not at all a common circumstance.
checking the user agent being used (and assuming it's
accurate) may allow some functionality to behave correctly
in those browsers also.

<snip>

But the caveat "assuming it's accurate" kills the proposition dead on
the spot as no strategy exists that can accurately identify the user
agent.

Richard.

[Mick White]

Richard Cornford wrote:

But it always seems many fewer cases than some seem to think. You, for
example, have not raised any concrete cases that have not proved
amenable to feature detection once examined.

Safari, for instance supports the "rowObject.cellIndex" property, but
always returns 0 (zero).

Mick

[Richard Cornford]

Mick White wrote:

Richard Cornford wrote:

But it always seems many fewer cases than some seem to think.
You, for example, have not raised any concrete cases that have
not proved amenable to feature detection once examined.

Safari, for instance supports the "rowObject.cellIndex"
property, but always returns 0 (zero).

Are you saying you cannot work out how to test for that? If two cells in
the same row give the same cellIndex then cellIndex is useless (and if
there are not two cells in the same row it doesn't matter much). And of
course if Safari ever fix the problem it simultaneously starts passing
the test, while browser detection keeps on assuming that cellIndex is
useless (and on any other browser that spoofs Safari, while missing
browsers that have the same problem).

Feature detection is not that difficult, you work out what you need to
know and then work out which questions will tell you the answer, then
you code the questions.

Richard.

[Dr John Stockton]

JRS: In article <dl*******************@news.demon.co.uk>, dated Sun, 13
Nov 2005 22:27:50, seen in news:comp.lang.javascript, Richard Cornford
<Ri*****@litotes.demon.co.uk> posted :

Feature detection is not that difficult, you work out what you need to
know and then work out which questions will tell you the answer, then
you code the questions.

ISTM that it might be useful to use "feature detection" as the general
term, comprising such as "method detection", "bug detection", etc.; and
to use also the more specific term when practicable.

Example : IE4 has no native toFixed, and "method detection" detects that
class of browser, as opposed to the class including IE6. IE6 has a
known error in toFixed, sensed by "bug detection". We do not for sure
know how to detect all bugs that it may have, but we do know how to
detect one, and AFAIK know of no other.

Then there's "behaviour detection" - the output of some toString methods
(date) is specified as unspecified by ECMA, and there may be examples
where a specification is interpreted in more than one way though not
specified as such,

--
© John Stockton, Surrey, UK. ?@merlyn.demon.co.uk Turnpike v4.00 IE 4 ©
<URL:http://www.jibbering.com/faq/> JL/RC: FAQ of news:comp.lang.javascript
<URL:http://www.merlyn.demon.co.uk/js-index.htm> jscr maths, dates, sources.
<URL:http://www.merlyn.demon.co.uk/> TP/BP/Delphi/jscr/&c, FAQ items, links.

[Mick White]

Richard Cornford wrote:

Mick White wrote:

Richard Cornford wrote:

But it always seems many fewer cases than some seem to think.
You, for example, have not raised any concrete cases that have
not proved amenable to feature detection once examined.

Safari, for instance supports the "rowObject.cellIndex"
property, but always returns 0 (zero).

Are you saying you cannot work out how to test for that? If two cells in
the same row give the same cellIndex then cellIndex is useless (and if
there are not two cells in the same row it doesn't matter much).

It's easy enough to test for it (once you know it may be problematic).
But I agree, Safari may decide to fix this in future versions, so
sniffing for "Safari" in the UA string is pointless.
I stumbled across this bug whole writing an application, I can find no
documentation from Apple at all.
Mick

[Matt Silberstein]

On Sun, 13 Nov 2005 08:36:05 -0600, in comp.lang.javascript , "Matt
Kruse" <ne********@mattkruse.com> in <dl*********@news2.newsguy.com>
wrote:

[snip]

is merely detection, and cannot make any guarantee of correct results.
There is no way to guarantee correct results. You can't even always
know what "correct results" means. This is a stopping problem
question, web based stuff, since you don't control most of the path,
just makes it worse than other systems.
In
fact, a browser could have the feature, but its use could throw an error
every time. Simple "feature detection" can't check that.
Or fail when particular inputs are provided.

[snip]
In the cases where specific browser versions have bugs which cannot be
programmatically deduced by feature detection/verification, checking the
user agent being used (and assuming it's accurate) may allow some
functionality to behave correctly in those browsers also.

In theory. Is this practical? IMNO you could have some "finite" set of
platforms in a table and only run if the system meets some standard.
Of course it is not that easy and not as simple as work/don't work.
[snip]
--
Matt Silberstein

Do something today about the Darfur Genocide

http://www.beawitness.org
http://www.darfurgenocide.org
http://www.savedarfur.org

"Darfur: A Genocide We can Stop"