...

View Full Version : getElementById returning no length for existing id



]|V|[agnus
11-26-2004, 11:01 PM
Is there something wrong with my script? Typo?



function accite() {
bq = document.getElementById("content").getElementsByTagName("blockquote");
q = document.getElementById("content").getElementsByTagName("q");
alert(
"<blockquote /> = " + bq.length +
"<q /> = " + q.length
);
}


It's saying "document.getElementById('content') has no properties", and yes, I definitely have a <div id="content" />.

liorean
11-26-2004, 11:04 PM
Show us more of your source. Specifically, show us the HTML in question.

]|V|[agnus
11-26-2004, 11:44 PM
Here is an example page: http://sethrasmussen.com/index.php?p=86

I should note that I am having the problem in Firefox and IE. It actually seems to work fine in Opera, though. Dunno about more yet.

hemebond
11-26-2004, 11:59 PM
If you only have one instance of the blockquote or q elements, getElementsByTagName will return that object instead of an array of objects.
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
<html lang="en">
<head>
<title>48059</title>
</head>
<body>
<div id="content">
<blockquote></blockquote>
<q></q>
</div>

<script type="text/javascript">
var bq = document.getElementById("content").getElementsByTagName("blockquote");
if(bq.length == undefined)
{
bq = new Array(bq);
}

var q = document.getElementById("content").getElementsByTagName("q");
if(q.length == undefined)
{
q = new Array(q);
}

alert(
"<blockquote /> = " + bq.length +
"<q /> = " + q.length
);
</script>
</body>
</html>

]|V|[agnus
11-27-2004, 12:00 AM
Well, okay, but the problem is that IE and Firefox are choking before they even get to that. They bomb on "getElementById('content')"

Willy Duitt
11-27-2004, 12:02 AM
For one, your calling the function window.onload is premature and the content division has not yet been written to the page... Sans the error... Try body.onload instead...



function accite() {
bq = document.getElementById("content").getElementsByTagName("blockquote");
q = document.getElementById("content").getElementsByTagName("q");
alert(
"<blockquote /> = " + bq.length +
"<q /> = " + q.length
);
}

// init
function init () {accite();}
window.onload=init();


.....Willy

]|V|[agnus
11-27-2004, 12:05 AM
"body is not defined"

Willy Duitt
11-27-2004, 01:11 AM
You can't change window.onload = init() with body.onload = init() in the HEAD because well.... the body has not been written to the page yet...

Try: <body onload="init()">

]|V|[agnus
11-27-2004, 01:44 AM
very well, but how can i avoid adding the event handler to the structure?

document.getElementsByTagName("body").onload=init(); doesn't seem to work.

perhaps, document.getElementById("sethrasmussen-dot-com").onload=init(); ?

assuming of course that's the name of the body element?

]|V|[agnus
11-27-2004, 01:45 AM
no no that doesn't work... perhaps i include a file at the end of every page with sort of _exit scripts?

Willy Duitt
11-27-2004, 02:06 AM
|V|[agnus']very well, but how can i avoid adding the event handler to the structure?

document.getElementsByTagName("body").onload=init(); doesn't seem to work.

perhaps, document.getElementById("sethrasmussen-dot-com").onload=init(); ?

assuming of course that's the name of the body element?

getElementsByTagName returns an array....
Try: document.getElementsByTagName("body")[0].onload=function(){init()};

]|V|[agnus
11-27-2004, 03:06 AM
well i'm just doing the onload attribute for now. what i'm trying to do with my script is to insert links after blockquotes and quotes that have their href's generated by the blockquote or quote's cite attributes. i'm getting no errors with the following, but no links are inserted:



function accite() {
d = document;
bq = d.getElementById("content").getElementsByTagName("blockquote");
q = d.getElementById("content").getElementsByTagName("q");
// cite blockquotes
for(i=0;i<bq.length;i++){
newP=d.createElement("p");
newA=d.createElement("a");
newA.setAttribute("href",bq[i].getAttribute("cite"));
newP.appendChild(newA);
bq[i].appendChild(newP);
}
}


that code is being run on the same link from above.

Willy Duitt
11-27-2004, 03:02 PM
Although you are now calling the accite function body.onload.... You are still using window.onload to call the init function which in turn calls the accite and thus is still throwing the aforementioned error...

This could be causing a conflict but is hard for me to tell since your entire page does not work for me using IE6... There is much text overlayed upon other text, I can not scroll, view source does not open notepad although the context menu is there and the page seems to take a lot of cpu to display....

Anyways, it is hard for me to see what is going on or what it is supposed to look like...

.....Willy

]|V|[agnus
11-27-2004, 05:03 PM
Although you are now calling the accite function body.onload.... You are still using window.onload to call the init function which in turn calls the accite and thus is still throwing the aforementioned error...

No, I'm not.


This could be causing a conflict

What conflict? I am not getting any errors anymore, but the desired effect is not happening. I think it's because I am trying to use appendChild on a new element that has not been added to the tree yet itself. Yes?


but is hard for me to tell since your entire page does not work for me using IE6... There is much text overlayed upon other text, I can not scroll, view source does not open notepad although the context menu is there and the page seems to take a lot of cpu to display....

Anyways, it is hard for me to see what is going on or what it is supposed to look like...

...

:rolleyes:


That said, users of Internet Explorer can expect persistent bugginess, as this site makes use of modern techniques, the bulk of which IE only partially supports. Despite its massive market share, I've decided not to go out of my way to accomodate this archaic browser since the rest of the competition has continued to innovate and move forward. This site is about progress, not market share.

Willy Duitt
11-27-2004, 05:20 PM
If you are no longer calling the init function window.onload you changed it since I last looked at it shortly after you posted "that code is being run on the same link from above".... the window.onload = init() is in your external javascript file...

And FWIW: What you call modern browsers I call equally buggy if not moreso than IE... Heck, if Firefox is so wonderful why did this latest release break nearly every plugin that was made in the past? Now, all those plugins need to be patched... How long can we expect that to continue?

Besides, IE is one of the most forgiving browsers there is... If your code completely breaks using IE, there is something wrong and the quick look I took at your code shows no indication of cutting-edge code writing.... :p

That being said, I was only trying to help you by pointing out some obvious mistakes... If you have removed the window.onload from the external file, great for you but roll your eyes at someone else....

.....Willy

]|V|[agnus
11-27-2004, 05:27 PM
If you are no longer calling the init function window.onload you changed it since I last looked at it shortly after you posted "that code is being run on the same link from above".... the window.onload = init() is in your external javascript file...


Uh... which one is that now?


And FWIW: What you call modern browsers I call equally buggy if not moreso than IE... Heck, if Firefox is so wonderful why did this latest release break nearly every plugin that was made in the past? Now, all those plugins need to be patched... How long can we expect that to continue?

Dunno, don't care.


Besides, IE is one of the most forgiving browsers there is... If your code completely breaks using IE, there is something wrong and the quick look I took at your code shows no indication of cutting-edge code writing.... :p

And no claims have been made that should lead you to expect such.


That being said, I was only trying to help you by pointing out some obvious mistakes...

You mean intentional mistakes? (Otherwise known not as mistakes but simple decisions...) And I know what you're *trying* to do. It's really amusing, but I'm not interested in it. You know why IE looks like crap. If you can help me in the context I'm interested in *at the moment*, then great, I'd love that, but I'm not interested in playing around with you.

Willy Duitt
11-27-2004, 05:45 PM
Uh... which one is that now?

Yes, I now see that you made changes and removed that accite function to its own external file and removed the window.onload from the general external js file... However, these changes are recent and since you did not indicate that you once again made changes since your last post, I did not bother checking your code again...

FWIW: I did not respond last night because I was awaiting to see if someone else would jump in and after pointing out that "body is not defined" was obviously caused by changing window.onload to body.onload in the HEAD before the body was ever written to the page... I was reluctant to point out another obvious mistake or error in intentional decision, lest you think I was being petty...

But I'm sorry I can not help you further because I use my own custom debugger ported to IE and since your page does not work with IE, I can only spot the obvious mistakes....

Good Luck;
.....Willy

]|V|[agnus
11-27-2004, 05:52 PM
Just as you were posting this, I was figuring out my problems.

The main one being that I was failing to create a new text node for the text content of the <a />s I wanted to insert. I was setting their href attributes just fine and everything, etc.

Everything works great now(even in IE!:eek::eek::eek:). I'm going to post something about it on my site soon if anybody is interested in the script.

(Oh, and about the updates as we went along, Willy... I guess I assumed that people would keep checking back regardless of whether or not I say I updated here in the thread. I figured the fact that I'd be working on it until I figured it out would be assumed. Sorry for the confusion, I guess??)

Thanks for everybody's help.

jbot
11-29-2004, 03:40 PM
if Firefox is so wonderful why did this latest release break nearly every plugin that was made in the past? Now, all those plugins need to be patched... How long can we expect that to continue?

don't sit on the fence or anything. anyway, thought you were fan of FF. or have i mistaken your ultra-strong security policy as support for the ultra-secure FF web browser. :D

Willy Duitt
11-29-2004, 04:31 PM
don't sit on the fence or anything. anyway, thought you were fan of FF. or have i mistaken your ultra-strong security policy as support for the ultra-secure FF web browser. :D

Fence Sitting.. Tee Hee... :D

Actually, IE is my preferred browser.... Although it does not have tabbed browsing, I can open two or three instances of IE and then several child windows of each and IE still takes less resources than FF (besides, I have yet to find why FF opens two ports which security wise concerns me)....

Don't get me wrong, I do like FF for developement purposes but I prefer to surf with IE and security wise, I have IE locked down pretty tight... Also, although it is easier to write plugins for FF, I also write pluins for IE although with IE you need to jump thru a few hoops and inevitably edit the registry which is a PITA, especially when it comes to sharing those plugins with others... In fact, I have manged to port Mozilla's DOM Inspector to IE and am currently working on a compiled app to automate the setup....

Cheers;
.....Willy

BTW: Glad to hear you worked the problems out ]|V|[agnus... And now that you pointed out the missing anchor textNode I can see that it was missing from your first example... :p

liorean
11-29-2004, 04:44 PM
Magnus: The initial problem was that you executed the init function and made the return value the onload handler.
window.onload=init();
// should have been
window.onload=init;




hemebond: Wrong. Element.prototype.getElementsByTagName always return either a NodeList or an HTMLCollection, and it does so consistently in all browsers since ie5.5w. (Haven't tested ie5.0, but I assume both Mac and Windows versions behave like ie5.5w does.)




Willy: First of all, stop picking fights with everybody. I'm getting tired of it.

Second, a little nitpicking: ff1.0 didn't break one single plugin that wasn't already broken by ff0.10.1. (The release of nn6/moz0.6 did, however, but that change was announced more than a year ahead...) Ff1.0 broke a lot of extensions, though.

Third, it broke extensions at many times up to the 1.0 release. That's because they had not frozen the extension mechanism yet, as the browser hadn't been released. Now they have frozen it - expect less breakage in the future.

Fourth, the most common cause for breakage was that they changed the version from 0.10 to 1.0, a change known since the start of the m/b project and which had been announced by Ben about two months in advance, as to prepare extension writers. Most extensions that worked before still worked perfectly, but their makers had not changed the maxVersion of their extensions, so the extension mechanism didn't think the extension was compatible with ff1.0. The few that really broke (E.g. Mozilla Calendar) did so because of structural changes for interfaces and behaviors that they relied on - that's something you expect in at least a few cases for any new browser release, especially a first release.

Fifth, are you saying that the WinXPSP2 update didn't break any ie6w ActiveX controls either? It did, and that's one of the causes for it having so low adoption in corporate environments - the environments that uses ActiveX the most.

Willy Duitt
11-29-2004, 05:47 PM
Willy: First of all, stop picking fights with everybody. I'm getting tired of it.

Excuse me... Seems to me this was an amiable discussion which ended with all parties parting on agreeable terms and it is you coming in after the discussion was concluded, intent upon starting your own arguement...

.....Willy

Oh, btw... I previously pointed out the errant () in: window.onload=init() when I bolded them several times above... But no, that was not the original problem since the function was still being called prior to the division ever being written to the page....

jbot
11-29-2004, 06:30 PM
are you saying that the WinXPSP2 update didn't break any ie6w ActiveX controls either? It did, and that's one of the causes for it having so low adoption in corporate environments - the environments that uses ActiveX the most.

there are a quite a few security problems with SP2, too. also (tho unrelated) anyone hear of the Bofra virus which the Finnish government consider so strong as to tell their people to stop using IE altogether. :eek:

liorean
11-29-2004, 06:30 PM
Excuse me... Seems to me this was an amiable discussion which ended with all parties parting on agreeable terms and it is you coming in after the discussion was concluded, intent upon starting your own arguement...Well, it was just that you've been provoking meaningless arguments multiple times lately, in more threads than this one.
Oh, btw... I previously pointed out the errant () in: window.onload=init() when I bolded them several times above...Ah, I didn't see that. It seems my font doesn't contain bold parenteses and the like.
But no, that was not the original problem since the function was still being called prior to the division ever being written to the page....No. The div is part of the HTML and not written by script, the onload event is triggered by the parser completing the entire HTML source. Thus, the div would exist at the time that script was triggered.

Willy Duitt
11-29-2004, 07:25 PM
Well, it was just that you've been provoking meaningless arguments multiple times lately, in more threads than this one.

I fail to see where I started an arguement in this thread and in regards to any other instance you may be referring to, I beleive there is a difference in opinions there and what I see as making a point you are over critically assessing as an arguement. Meaningless or otherwise....

Regardless, I was somewhat taken back with your shot across my bow with your comment:


Willy: First of all, stop picking fights with everybody. I'm getting tired of it.

And can not help but think that since you obviously believe me to be arguementative as of late that you felt that it would be a simple matter to take a shot across my bow and have me respond in a negative manner which would quantify your opinion... Then again, I suppose you could have been acting as a kindly advisor but it is so hard to tell someones true intentions across montiors which is so impersonal and without aide of body language or infliction of voice....

Therefore, I will choose to take your comment as kindly advice offered by a trusted advisor.... But I would just like to say that I was disappointed when I seen that you responded to this thread and that you were not the least bit interested in how I ported the DOM Inspector to IE.... But, kindly advice has its merits also...

Cheers;
.....Willy

liorean
11-29-2004, 09:10 PM
Therefore, I will choose to take your comment as kindly advice offered by a trusted advisor.... But I would just like to say that I was disappointed when I seen that you responded to this thread and that you were not the least bit interested in how I ported the DOM Inspector to IE.... But, kindly advice has its merits also...Well, I don't think it would be that hard, really. Loads of work, though. I've tried to extend iew with a DOM Tree Viewer/Modifier at least twice, but didn't get especially far before more important things needed be done. Now, I'm more interested in how you deal with the fact that iew allows a child to have several parents, and similar technical things.

jbot
11-29-2004, 10:09 PM
I'm interested in how you deal with the fact that iew allows a child to have several parents

wtf? how does it manage that? doesn't sound like something you'd want, surely

liorean
11-29-2004, 10:18 PM
wtf? how does it manage that? doesn't sound like something you'd want, surelyIt's the Microsoft way of making things like
<div>
div
<i>
i
<b>
b+i
</i>
b
</b>
div
</div>

And, seriously, who can blame them? That code is a mess, and it was Netscape that started the whole tag soup parsing thing... They simply had to allow the same things that Netscape did. But they didn't do it in precisely the same way, of course. And that's the problem. Mozilla and Opera did handle that in different ways as well (I don't know whether that difference is the case today as well), and I have no idea how Safari handles the corresponding situation. Safari didn't exist at the time I last tested...

Kor
11-30-2004, 01:31 PM
Even I like FF (in fact I use both IE and FF, upon needs) I would be concerned about the childNodes counting inconsistency (well, it looks like for me) of FF



<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<title>Untitled Document</title>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<meta http-equiv="Content-Style-Type" content="text/css">
<meta http-equiv="Content-Script-Type" content="text/javascript">
<script language="JavaScript" type="text/JavaScript">
function seeN(){
d=document.getElementById('mydiv');
alert(d.childNodes.length)
}
onload=seeN;
</script>
</head>
<body>
<div id="mydiv">
<div></div>
</div>
</body>
</html>


Ie shows 1, FF shows 3 . This is not the problem I want to rise, as I know that FF considers textNodes as childNodes even when empty, which seems correct to me.

But when

<div id="mydiv"><div></div>
</div>

FF alerts 2

and

<div id="mydiv"><div></div></div>

FF alerts 1

This not so logical for me, as the empty textNodes are still there

liorean
11-30-2004, 02:52 PM
I would be concerned about the childNodes counting inconsistency of FF
<div id="mydiv">
<div></div>
</div>Ie shows 1, FF shows 3.
<div id="mydiv"><div></div>
</div>FF alerts 2
<div id="mydiv"><div></div></div>
FF alerts 1

This not so logical for me, as the empty textNodes are still thereWell, not quite. Each character in document that is not part of one of a tagged node is represented as a Text node.

In the first case, you have a newline above and a newline below the Element node. Those must be mapped to Text nodes containing the textual content (a newline). Thus, you have Text, Element, Text.

In the second case, you have no whitespace or indeed characters at all between the opening tag for the parent Element and the opening tag of the child Element. That means there is no need to create a Text node - there is no text to place in the Text node. Had there been a single whitespace there though, it would have necessited the creation of a Text node.

In the third case, the same applies.


As I see it, it would be a consistency error to not behave this way. Any characters, whitespaces and newlines should create a Text node. If there is no textual content, no Text node should be created. Essentially, what is missing here is an Element.prototype.childElements NodeList.

]|V|[agnus
12-02-2004, 07:02 AM
I've made good progress with the script, but I've hit yet another roadblock...

To link to the cite URI of <q /> elements, I want to basically wrap the existing quote text in an <a />. To do this, I thought it would be easy enough to capture the original <q /> text in a variable, then drop all child nodes of the <q /> and replace them with the newly constructed <a /> that contains the original <q /> text.

I've got this working fine, but I'm having issues with the recognition of child nodes that are <img /> elements. In WordPress, for example, certain smilies are converted to images. If a smiley is used in a quote, I want to grab the value of the <img />'s alt attribute before dumping the <img /> element as well as any other text nodes.

I'm not getting the <img />'s alt value in my variable holding the original <q /> text, and the <img /> elements aren't being dropped either.

An example page here: http://sethrasmussen.com/common/js/q-child-nodes.html

The script here: http://sethrasmussen.com/js/_exit.js

Also: liorean, are you saying that I could have this script in the <head /> and still do the window.onload call?

liorean
12-02-2004, 03:29 PM
Magnus: Yes, you could.

In fact, the way coding conventions go today, there are a number of things that are considered bad:
- The methods document.write, document.writeln. These shouldn't be used, use DOM at load instead.
- Above methods are the only real reason for allowing script inclusions in the body. Your scripts should all be in the head.
- Scripts should NEVER ever be placed in a href, src or data attribute on any element.
- Event handlers in the HTML are generally something you should avoid.
- If you have an event handler you need to place on your elements, give the elements an id and assign the event handlers at load from your script instead.


...all in the name of separation of structure and behavior, in analogy to the separation of structure and presentation that CSS facilitates.

]|V|[agnus
12-02-2004, 03:40 PM
Good info as usual... any clues about my bug du moment?



EZ Archive Ads Plugin for vBulletin Copyright 2006 Computer Help Forum