getElementsByTagName in Firefox

Dan

Hi. I've got the following line of code which works fine in IE ...

line_1_numbers [0] = document.getElementsByTagName
('table')[table_index].rows (0).cells (0).innerText;

But it Firefox, it barks saying:

"Error: document.getElementsByTagName("table")[table_index].rows is not a
function"

Any ideas what this means?

Thanks for any help,
Regards,
Dan.

Jul 28 '05 #1

Subscribe Post Reply

19843

Christopher J. Hahn

Dan wrote:

Hi. I've got the following line of code which works fine in IE ...

line_1_numbers [0] = document.getElementsByTagName
('table')[table_index].rows (0).cells (0).innerText;

But it Firefox, it barks saying:

"Error: document.getElementsByTagName("table")[table_index].rows is not a
function"

Any ideas what this means?

Thanks for any help,
Regards,
Dan.

IE is broken by allowing you to address indices in collections using ()
notation. Use [] instead.
line_1_numbers [0] = document.getElementsByTagName('table'
)[table_index].rows[0].cells[0].innerText;
thing() is for functions.
thing[] is for arrays/lists.

Jul 28 '05 #2

RobG

Christopher J. Hahn wrote:
[...]

IE is broken by allowing you to address indices in collections using ()
notation. Use [] instead.
line_1_numbers [0] = document.getElementsByTagName('table'
)[table_index].rows[0].cells[0].innerText;

Support for innerText is limited (pretty much to IE), a regular
expression can be used to remove tags from the cell's innerHTML to
achieve pretty much the same result. Something like:
var re = /<[^>]*>/g;

should do the trick. Or wait for DOM 3 to be widely supported and use
textContent ;-p

<URL:>
http://www.w3.org/TR/2004/REC-DOM-Level-3-Core-20040407/core.html#Node3-textContent>
The cells collection is not supported by all browsers (think
Safari...). The childNodes collection may be a better choice and is
functionally equivalent in this case as only a cell ( TR|TH ) can be a
child of a TR.

var re = /<[^<>]+>/g;
line_l_numbers[0]=...rows[0].childNodes[0].innerHTML.replace(re,'');

[...]

--
Rob

Jul 28 '05 #3

Christopher J. Hahn

RobG wrote:

Christopher J. Hahn wrote:
[...]

IE is broken by allowing you to address indices in collections using ()
notation. Use [] instead.
line_1_numbers [0] = document.getElementsByTagName('table'
)[table_index].rows[0].cells[0].innerText;
Support for innerText is limited (pretty much to IE)

[snip] The cells collection is not supported by all browsers (think
Safari...).
[snip] --
Rob

Both excellent points that I missed entirely even though I knew them.
This is exactly why I'm not a very prolific poster here. ;)

Jul 28 '05 #4

Dan

> > IE is broken by allowing you to address indices in collections using ()

notation. Use [] instead.
line_1_numbers [0] = document.getElementsByTagName('table'
)[table_index].rows[0].cells[0].innerText;
Support for innerText is limited (pretty much to IE), a regular
expression can be used to remove tags from the cell's innerHTML to
achieve pretty much the same result. Something like:
var re = /<[^>]*>/g;

should do the trick. Or wait for DOM 3 to be widely supported and use
textContent ;-p

<URL:>

http://www.w3.org/TR/2004/REC-DOM-Level-3-Core-20040407/core.html#Node3-textContent>

The cells collection is not supported by all browsers (think
Safari...). The childNodes collection may be a better choice and is
functionally equivalent in this case as only a cell ( TR|TH ) can be a
child of a TR.

var re = /<[^<>]+>/g;
line_l_numbers[0]=...rows[0].childNodes[0].innerHTML.replace(re,'');

[...]

Thanks for your replies guys - using the square brackets worked fine. The
innerText function seems to work in Firefox too. I know that everyone who
will be using the website will either be using IE or Firefox.

I've another quick question if that's okay. The next error I'm getting when
running the page in Firefox is that one of my variables has not been
defined. It has been defined though, but it's a global variable. Does
Firefox handle global variables differently? I can't see anything wrong
with what I've done. I've just done a testcase html file to demonstrate the
error. It's on http://dracan.x-1.net/test.html. This works in IE, but not
Firefox.

Thank again,
Dan.

Jul 28 '05 #5

Martin Honnen

Dan wrote:

I've another quick question if that's okay. The next error I'm getting when
running the page in Firefox is that one of my variables has not been
defined. It has been defined though, but it's a global variable. Does
Firefox handle global variables differently? I can't see anything wrong
with what I've done. I've just done a testcase html file to demonstrate the
error. It's on http://dracan.x-1.net/test.html.

The problem is that you use document.write after the document has been
loaded, that way the browser overwrites the current document with a new
one where then variables in the old document are gone, although as you
have found browsers differ as to when that happens, with Mozilla/Firefox
one document.write is enough for that to happen.
If you really want to overwrite the document then construct the function
as follows e.g.

function test_function(table_index)
{
var html = '';
html += "<html>\n";

if (varname >= 3)
{
html += "TRUE<BR>\n";
}
else
{
html += "FALSE<BR>\n";
}

html += "</html>\n";
document.open();
document.write(html);
document.close();
}

That way you have only one document.write() and have constructed the
HTML to write before that call when all variables do still exist.

But of course with modern browsers there are other ways than using
document.write to change/insert text into the document.

--

Martin Honnen
http://JavaScript.FAQTs.com/

Jul 28 '05 #6

RobG

Dan wrote:
[...]

Thanks for your replies guys - using the square brackets worked fine. The
innerText function seems to work in Firefox too. I know that everyone who
will be using the website will either be using IE or Firefox.
But you have been given the opportunity to support a wider range of
browsers, why not take it? You could test for innerText and if
supported, use it. If not, use RegExp or even use DOM to get the text
inside the cell (I'm guessing there's not much in there anyway).

Something like:

var r = document.getElementsByTagName('table')[table_index].rows[0];
var el = r.childNodes[0];

if ( el.innerText ) {
line_1_numbers[0] = el.innerText;
} else {
line_1_numbers[0] = el.innerHTML.replace(/<[^<>]+>/g,'');
}

I've another quick question if that's okay. The next error I'm getting when
running the page in Firefox is that one of my variables has not been
defined. It has been defined though, but it's a global variable. Does
Firefox handle global variables differently? I can't see anything wrong
with what I've done. I've just done a testcase html file to demonstrate the
error. It's on http://dracan.x-1.net/test.html. This works in IE, but not
Firefox.

Here's your page (quote marks added by me):
<script type="text/javascript">
Script elements go in the head or body, *NO* html elements are allowed
outside the page defined by the <html>...</html> element.

Ditch the comments...
</script>

<html>
<body>
<button onclick='test_function(0)'>Run</button>
</body>
</html>
So the issue had nothing to do with global variables at all.

Thank again,
Dan.

You're welcome. :-)
--
Rob

Jul 28 '05 #7

Dan

> > I've another quick question if that's okay. The next error I'm getting
when

running the page in Firefox is that one of my variables has not been
defined. It has been defined though, but it's a global variable. Does
Firefox handle global variables differently? I can't see anything wrong
with what I've done. I've just done a testcase html file to demonstrate the error. It's on http://dracan.x-1.net/test.html.

The problem is that you use document.write after the document has been
loaded, that way the browser overwrites the current document with a new
one where then variables in the old document are gone, although as you
have found browsers differ as to when that happens, with Mozilla/Firefox
one document.write is enough for that to happen.
If you really want to overwrite the document then construct the function
as follows e.g.

function test_function(table_index)
{
var html = '';
html += "<html>\n";

if (varname >= 3)
{
html += "TRUE<BR>\n";
}
else
{
html += "FALSE<BR>\n";
}

html += "</html>\n";
document.open();
document.write(html);
document.close();
}

That way you have only one document.write() and have constructed the
HTML to write before that call when all variables do still exist.

But of course with modern browsers there are other ways than using
document.write to change/insert text into the document.

Ah, I see. Is there a limit to how big that html string can become? What
are these other ways your talking about? I need my code to generate a new
temporary page. It's not just changing/inserting text. Is there a better
way?

Thanks again,
Dan.

Jul 28 '05 #8

Dan

> > Thanks for your replies guys - using the square brackets worked fine.
The

innerText function seems to work in Firefox too. I know that everyone who will be using the website will either be using IE or Firefox.

But you have been given the opportunity to support a wider range of
browsers, why not take it? You could test for innerText and if
supported, use it. If not, use RegExp or even use DOM to get the text
inside the cell (I'm guessing there's not much in there anyway).

Something like:

var r = document.getElementsByTagName('table')[table_index].rows[0];
var el = r.childNodes[0];

if ( el.innerText ) {
line_1_numbers[0] = el.innerText;
} else {
line_1_numbers[0] = el.innerHTML.replace(/<[^<>]+>/g,'');
}

I've another quick question if that's okay. The next error I'm getting when running the page in Firefox is that one of my variables has not been
defined. It has been defined though, but it's a global variable. Does
Firefox handle global variables differently? I can't see anything wrong
with what I've done. I've just done a testcase html file to demonstrate the error. It's on http://dracan.x-1.net/test.html. This works in IE, but not Firefox.

Here's your page (quote marks added by me):
> <script type="text/javascript">

Script elements go in the head or body, *NO* html elements are allowed
outside the page defined by the <html>...</html> element.
> 

Ditch the comments...
> </script>
>
> <html>
> <body>
> <button onclick='test_function(0)'>Run</button>
> </body>
> </html>

So the issue had nothing to do with global variables at all.

Thank again,
Dan.

You're welcome. :-)

Thanks for all that. I put the html comments there because I read that you
should do this to handle browsers that don't understand the <script> tag.
Is this not right?

I put the '\n' at the end of the </html> tag just to format the new
temporary page that my code creates. Presumbly it makes no difference
whether I do this or not? I just want it to look formatted if I do a 'view
source'.

Thanks again,
Dan.

Jul 28 '05 #9

Michael Winter

On 28/07/2005 20:21, Dan wrote:

[snip]

I put the html comments there [in the SCRIPT element] because I read
that you should do this to handle browsers that don't understand the
<script> tag. Is this not right?
It was several /years/ ago, but it's redundant now. All browsers in
current use understand the SCRIPT element, even if they don't execute
client-side scripts.

If you ever move to XHTML (which isn't currently viable on the Web
without content negotiation), adding comments in that fashion will hide
your script from /all/ XHTML-conforming browsers, even if they /can/
execute client-side scripts!
I put the '\n' at the end of the </html> tag just to format the new
temporary page that my code creates. Presumbly it makes no
difference whether I do this or not?

No.

The writeln method can be used to add a new line for you automatically.

[snip]

Mike

--
Michael Winter
Prefix subject with [News] before replying by e-mail.

Jul 28 '05 #10

Richard Cornford

Christopher J. Hahn wrote:
<snip>

IE is broken by allowing you to address indices in collections
using () notation. Use [] instead.

<snip>

IE is not really broken in this respect. The collections are host
objects and so can do pretty much anything they like. And those
collections that are present in W3C DOM standards are required to
implement an interface in order to be compliant, they may provide any
facility they like in addition to that interface and still be fully
compliant.

All Microsoft have done is implement their collections on an object that
can be called, and when called with an argument will return the same
result as a bracket notation property accessor what uses the argument as
its expression instead.

The only issue is that this is a decision by a single browser
manufacturer and is not repeated by all others, so calling a collection
is not cross-browser, while using a property accessor notation is.

It is interesting that Microsoft promotes the use of its collection
implementations by calling them. On the face of it that looks like they
intend to promote the creation of non-cross-browser code (and maybe they
do) but it occurs to me that most of these collections are supposed to
be read-only. A read only object is not a concept that sits well with
javascript but if you promote only accessing the properties of a
collection through a function call then it is obvious that you should
not be assigning new/different values to the properties of the
collection object; it is impossible as assigning to the result of a
function call.

Richard.

Jul 28 '05 #11

Christopher J. Hahn

Richard Cornford wrote:

Christopher J. Hahn wrote:
<snip>
IE is broken by allowing you to address indices in collections
using () notation. Use [] instead. <snip>

IE is not really broken in this respect. The collections are host
objects and so can do pretty much anything they like. And those
collections that are present in W3C DOM standards are required to
implement an interface in order to be compliant, they may provide any
facility they like in addition to that interface and still be fully
compliant.

All Microsoft have done is implement their collections on an object that
can be called, and when called with an argument will return the same
result as a bracket notation property accessor what uses the argument as
its expression instead.

[snip] It is interesting that Microsoft promotes the use of its collection
implementations by calling them. On the face of it that looks like they
intend to promote the creation of non-cross-browser code (and maybe they
do) but it occurs to me that most of these collections are supposed to
be read-only. A read only object is not a concept that sits well with
javascript but if you promote only accessing the properties of a
collection through a function call then it is obvious that you should
not be assigning new/different values to the properties of the
collection object; it is impossible as assigning to the result of a
function call.

Richard.

My understanding is that
a) they *do* want to promote IE-dependent code and
b) they do it this way to make it more like VB[Script], which (*if* I
remember correctly) accesses array indices using parentheses.

"Broken" is really a personal opinion of mine, just as I consider
global referencing of element IDs broken, in that it behaves in a way
that is not "predictable" or "typical" in light of language and
dev-community conventions. Microsoft is appealing to their own
proprietary community to remain theirs and theirs alone, as I see being
typical of their methodology.

Granted, these are "extensions" in that they don't go against the
standard but add functionality to it, but I see that it is a deliberate
attempt to subordinate the standard, in the same way that they did with
innerHTML, HTMLElement.all, and others that don't fit the *vision* of
existing standards.

Just as in other languages one should try to develop one's libraries,
objects, and so forth such that they suit *convention* (i.e. in JS
using ObjectName case, functionName case, et cetera; or in PERL using
ALLCAPSCONSTANTS, CamelCasePackages, and small subs that are each good
at one small thing), ECMAScript implementors should try to stick to
convention even when extending standards.

Jul 29 '05 #12

Martin Honnen

Dan wrote:

But of course with modern browsers there are other ways than using
document.write to change/insert text into the document.

Ah, I see. Is there a limit to how big that html string can become? What
are these other ways your talking about? I need my code to generate a new
temporary page. It's not just changing/inserting text.

If you really want to create a new page then
document.open()/write()/close() is the way to go, the other way I
mentioned is simply DOM manipulation of the existing document.
--

Martin Honnen
http://JavaScript.FAQTs.com/

Jul 29 '05 #13

Jim Ley

On 28 Jul 2005 20:43:55 -0700, "Christopher J. Hahn"
<cj****@gmail.com> wrote:

ECMAScript implementors should try to stick to
convention even when extending standards.

but IE's DOM is not tied to ECMAScript, so why should it follow
ECMAScript conventions, surely including conventions related to all
the likely languages is appropriate - which is exactly what they've
done.

Jim.

Aug 2 '05 #14

Christopher J. Hahn

Jim Ley wrote:

On 28 Jul 2005 20:43:55 -0700, "Christopher J. Hahn"
<cj****@gmail.com> wrote:
ECMAScript implementors should try to stick to
convention even when extending standards.

but IE's DOM is not tied to ECMAScript, so why should it follow
ECMAScript conventions, surely including conventions related to all
the likely languages is appropriate - which is exactly what they've
done.

Jim.

Sure, the DOM isn't at all tied to ECMAScript. But the JScript
interface to it is (albeit loosely). It is appropriate to follow
conventions for the language that is interacting with the interface
being exposed by the DOM implementor, regardless of the language. It
would certainly not be appropriate for IE to provide

$object->property
or
# comment

notations though I see no reason why that wouldn't be considered
"extending the standard to work within the conventions of more likely
languages". It would be even more inappropriate for MS to promote the
use of such a proprietary way of doing things, and yet more so to do it
without telling the user that it won't work anywhere else.

I understand what you're saying-- they haven't really done anything
"wrong" by allowing it. "Broken" is a personal opinion of mine. But
they promote it and don't bother to tell you that it's IE-only, and
that's definitely inappropriate.

If we still disagree, we'll have to leave it at a matter of perspective.

Aug 3 '05 #15

Richard Cornford

Christopher J. Hahn wrote:

Jim Ley wrote:
Christopher J. Hahn wrote:
>ECMAScript implementors should try to stick to
>convention even when extending standards.
but IE's DOM is not tied to ECMAScript, so why should
it follow ECMAScript conventions, surely including
conventions related to all the likely languages is
appropriate - which is exactly what they've done.

Sure, the DOM isn't at all tied to ECMAScript. But the
JScript interface to it is (albeit loosely). It is
appropriate to follow conventions for the language that
is interacting with the interface being exposed by the
DOM implementor, regardless of the language.

With regard specifically to the ability to call a collection in IE in
addition to using a property accessor to achieve the same effect, that
is completely within the ECMAScript language conventions. Because an
ECMAScript function is an object (an augmented instance of the native
ECMAScript object) it may have any number of named properties, including
methods. So it would be relatively easy to create an object that behaved
in exactly the way the IE collections do. A simplified example might
go:-

document.all = function(IdOrName){
return document.all[IdOrName];
}
document.all.item = function(index){
return this[index];
}
document.all[0] = document.all['elementName'] = elementRef1;
document.all[1] = document.all['elementName2'] = elementRef2;
....
//used as:-
var a = document.all('elementName2');
var b = document.all.item(1);
var c = document.all[0];
var d = document.all['elementName1'];
var e = document.all.elementName2;
It would certainly not be appropriate for IE to provide

$object->property
or
# comment

notations though I see no reason why that wouldn't be
considered "extending the standard to work within the
conventions of more likely languages".
They couldn't be considered as extending the standard because they would
represent syntax errors to ECMA 262 compliant implementations. Any
extension must be capable of complying with the syntax rules. IE's
'conditional comments' might be regarded as such an extension, because
they conceal themselves within the existing syntax rules.

Other extensions, in the form of additional methods, object and
properties might produce runtime errors if assumed to exist in
environments that do not support them, but they do not result in syntax
errors.
It would be even more inappropriate for MS to promote the
use of such a proprietary way of doing things, and yet more
so to do it without telling the user that it won't work
anywhere else.
I don't like the way in which the term 'user' is used sometimes. To my
mind the user is the individual at the receiving end, and the user of
javascript/ECMAScript is the _programmer_. And the programmer has some
responsibility to find out what works, where and why, and to do some
testing of what they create appropriate to the context in which it will
be used.

Jim may bemoan the low standards of QA on the Internet (and/or its
apparent total absence in many cases) but the programmer should be doing
some testing prior to sending anything on to QA (particularly as
reasonable QA will be keeping track of which developers are responsible
for which bugs, how many bugs and the time it takes them to fix their
bugs, and passing that information on to management).
I understand what you're saying-- they haven't really done
anything "wrong" by allowing it. "Broken" is a personal
opinion of mine. But they promote it and don't bother to
tell you that it's IE-only, and that's definitely
inappropriate.

<snip>

Microsoft has no reason to be documenting other people's browsers. If
they accurately state what is available in the various versions of their
own browsers, and which features appear in various standards, they are
probably doing what should be expected of them (and more than many other
browser manufacturers do). It is a pity that Microsoft's documentation
is erroneous in some respects, but at least it will tell you what IE is
capable of, and usually shows at lest one way of achieving it.

That Microsoft's examples usually show the various collections being
called is perhaps unfortunate, and it does directly promote non-cross
browser scripting, but it might be questioned whether the fault here is
Microsoft's or the W3C's. When, earlier in the thread you wrote:-

| Granted, these are "extensions" in that they don't go against
| the standard but add functionality to it, but I see that it is
| a deliberate attempt to subordinate the standard, in the same
| way that they did with innerHTML, HTMLElement.all, and others
| that don't fit the *vision* of existing standards.

- you cite examples of Microsoft trying to "subordinate ... existing
standards" that pre-date the DOM standards you assert they try to
subordinate. IE 4 had a DOM that featured - all - collections, innerHTML
and callable collections before there was even a Core DOM standard.

At the time of the release of IE 4 the only other significant scriptable
browser was Netscape 4. Their DOMs differed, and if either inspired the
W3C's DOM thinking it was the IE 4 DOM, with its tree-like structure and
access to all of the elements within the document.

By the time the W3C got around to the HTML DOM, and defining the
interface for the HTMLCollection, Microsoft already had callable
collections. The W3C could have specified in the ECMAScript bindings
that the HTMLCollection interface could be called, after all they had no
problem doing so for the ECMAScript binding of the EventListener
interface. And that would have removed the current issue at a stroke
(except with regard to dinosaurs like Netscape 4).

Richard.

Aug 6 '05 #16

getElementsByTagName in Firefox

Similar topics