browsers & standards

[abracad_1999]

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

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

Thank you

[Randy Webb]

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

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

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

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

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

[Mick White]

ab**********@ya hoo.com wrote:

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

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.get ElementById){// do stuff with document.getEle mentById()}

Mick

[RobG]

ab**********@ya hoo.com wrote:

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

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**********@ya hoo.com a écrit :

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

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************ ********@comcas t.com>, dated Sun, 6 Nov
2005 17:03:37, seen in news:comp.lang. javascript, Randy Webb
<Hi************ @aol.com> posted :

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

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

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

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.c om/faq/> JL/RC: FAQ of news:comp.lang. javascript
<URL:http://www.merlyn.demo n.co.uk/js-index.htm> jscr maths, dates, sources.
<URL:http://www.merlyn.demo n.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************ ********@comcas t.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.get ElementById()

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

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.getEle mentById 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.javas cript 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.javas cript FAQ - http://jibbering.com/faq & newsgroup weekly
Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/