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]

(e-mail address removed) 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.

 

[Mick White]

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]

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

 

[Dr John Stockton]

JRS: In article <[email protected]>, dated Sun, 6 Nov
2005 17:03:37, seen in Randy Webb

(e-mail address removed) said the following on 11/6/2005 4:54 PM:

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.

 

[Gérard Talbot]

(e-mail address removed) 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-developer/upgrade_2.html

Accessing Elements with the W3C DOM:
http://www.mozilla.org/docs/web-developer/upgrade_2.html#dom_access

Gérard

 

[Randy Webb]

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

JRS: In article <[email protected]>, dated Sun, 6 Nov
2005 17:03:37, seen in Randy Webb



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.

 

[Dr John Stockton]

JRS: In article <[email protected]>, dated
Mon, 7 Nov 2005 17:55:15, seen in Randy Webb

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

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.

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



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

 

[Matt Kruse]

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.

 

[Thomas 'PointedEars' Lahn]

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:




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.

 

[Matt Kruse]

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?

 

[Thomas 'PointedEars' Lahn]

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 <[email protected]>, dated Tue, 8 Nov 2005
09:58:14, seen in Matt Kruse

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.

 

[Randy Webb]

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

JRS: In article <[email protected]>, dated
Mon, 7 Nov 2005 17:55:15, seen in Randy Webb



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.

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.

 

[Dr John Stockton]

JRS: In article <[email protected]>, dated
Thu, 10 Nov 2005 22:33:21, seen in Randy Webb

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


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.

 

[Richard Cornford]

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]

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.

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!

 

[Randy Webb]

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

JRS: In article <[email protected]>, dated
Thu, 10 Nov 2005 22:33:21, seen in Randy Webb



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.

 

[Richard Cornford]

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.

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.

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.

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.