innerHTML vs. replaceChild() [JavaScript]

From: Hallvard B Furuseth on 9 Feb 2006 13:28

Why does the FAQ (Q 4.15) recommend innerHTML when so many here
say one should use createElement(), replaceChild() etc?

Also, why does the "Alternative DynWrite function" at
<http://www.jibbering.com/faq/faq_notes/alt_dynwrite.html> need
such a lot of tests to find out if innerHTML assignment actually
works, instead of just inserting 
and checking if the document now contains an element with that ID?

There is a note which says the getElementWithId function they
define (based on document.all or getElementById) would fail if no
element with that ID exists, but that does not happen with Firefox
or IE 6.

--
Hallvard

From: Randy Webb on 9 Feb 2006 16:47

Hallvard B Furuseth said the following on 2/9/2006 1:28 PM:
> Why does the FAQ (Q 4.15) recommend innerHTML when so many here
> say one should use createElement(), replaceChild() etc?

cross-browser backwards compatability and nothing more.

>
> Also, why does the "Alternative DynWrite function" at
> <http://www.jibbering.com/faq/faq_notes/alt_dynwrite.html> need
> such a lot of tests to find out if innerHTML assignment actually
> works, instead of just inserting 
> and checking if the document now contains an element with that ID?

Because simply checking for that ID doesn't ensure that the element was
actually added to the page.

> There is a note which says the getElementWithId function they
> define (based on document.all or getElementById) would fail if no
> element with that ID exists, but that does not happen with Firefox
> or IE 6.

Example code? If an ID doesn't exist, then the code shouldn't produce an
error but it shouldn't return an element either.

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

From: Hallvard B Furuseth on 10 Feb 2006 09:30

Randy Webb writes:
>Hallvard B Furuseth said the following on 2/9/2006 1:28 PM:
>> Why does the FAQ (Q 4.15) recommend innerHTML when so many here
>> say one should use createElement(), replaceChild() etc?
>
> cross-browser backwards compatability and nothing more.

Heh. Now that I've looked at Microsoft's createElement() documentation,
it does look like "if (document.createElement)" isn't the best way to
check if it works. E.g. "In Microsoft Internet Explorer 4.0, the only
new elements you can create are img, area, and option.". Seems to have
current quirks as well which I don't see in the DOM 1 spec.

http://msdn.microsoft.com/workshop/author/dhtml/reference/methods/createelement.asp
http://www.w3.org/TR/2000/WD-DOM-Level-1-20000929/level-one-core.html

>> Also, why does the "Alternative DynWrite function" at
>> <http://www.jibbering.com/faq/faq_notes/alt_dynwrite.html> need
>> such a lot of tests to find out if innerHTML assignment actually
>> works, instead of just inserting 
>> and checking if the document now contains an element with that ID?
>
> Because simply checking for that ID doesn't ensure that the element
> was actually added to the page.

I don't understand. Will some browsers parse the HTML, insert the ID
somewhere in the DOM, but not insert the HTML?

Or are we talking past each other? I was thinking of

function testInnerTML(element) {
if (! document.getElementWithId("foobar")) {
element.innerHTML = 'xyzzy';
if (document.getElementWithId("foobar"))
return true; // Successfully inserted
}
return false; // Insertion failed
}

where getElementWithId is a getElementById emulation/wrapper like this
from the FAQ notes:

var getElementWithId;
if (document.getElementById) {
getElementWithId = function(id) {
return document.getElementById(id);
}
} else if (document.all) {
getElementWithId = function(id) { return document.all[id]; }
}else{
getElementWithId = function(id) { return null; }
}

>> There is a note which says the getElementWithId function they
>> define (based on document.all or getElementById) would fail if no
>> element with that ID exists, but that does not happen with Firefox
>> or IE 6.
>
> Example code? If an ID doesn't exist, then the code shouldn't
> produce an error but it shouldn't return an element either.

That's how it works for me. The FAQ notes' actual example is

getElementWithId(id).innerHTML = S; return true;

with the getElementWithId above, so I suppose it could just be referring
to how the .innerHTML part will fail if getElementWithId(id) doesn't
return an element. But that's a strange objection to the
getElementWithId implementation.

BTW, the FAQ code uses document.all["id/name"], the Microsoft doc says
document.all("id/name"), and I've seen document.all.id/name too. I
think I've seen some mention of browsers where one worked an another did
not, but I don't remember... If it's all the same, I guess one could
just do

// partial getElementById emulation, if no NAME/ID conflicts.
if (document.all && !document.getElementById)
document.getElementById = document.all;

--
Regards,
Hallvard

From: Randy Webb on 15 Feb 2006 01:48

Hallvard B Furuseth said the following on 2/10/2006 9:30 AM:
> Randy Webb writes:
>> Hallvard B Furuseth said the following on 2/9/2006 1:28 PM:
>>> Why does the FAQ (Q 4.15) recommend innerHTML when so many here
>>> say one should use createElement(), replaceChild() etc?
>> cross-browser backwards compatability and nothing more.
>
> Heh. Now that I've looked at Microsoft's createElement() documentation,
> it does look like "if (document.createElement)" isn't the best way to
> check if it works. E.g. "In Microsoft Internet Explorer 4.0, the only
> new elements you can create are img, area, and option.". Seems to have
> current quirks as well which I don't see in the DOM 1 spec.

I think I stopped worrying about IE4 support about the time IE5.5 came
out. But no, if (document.createElement) won't tell you if the element
was created, only if the browser supports document.createElement

> http://msdn.microsoft.com/workshop/author/dhtml/reference/methods/createelement.asp
> http://www.w3.org/TR/2000/WD-DOM-Level-1-20000929/level-one-core.html
>
>>> Also, why does the "Alternative DynWrite function" at
>>> <http://www.jibbering.com/faq/faq_notes/alt_dynwrite.html> need
>>> such a lot of tests to find out if innerHTML assignment actually
>>> works, instead of just inserting 
>>> and checking if the document now contains an element with that ID?
>> Because simply checking for that ID doesn't ensure that the element
>> was actually added to the page.
>
> I don't understand. Will some browsers parse the HTML, insert the ID
> somewhere in the DOM, but not insert the HTML?

document.myDiv.chicken = "This is document.myDiv.chicken";

alert(document.myDiv.chicken);

What you have to check is that the innerHTML property actually got
changed instead of just adding a new property to something.

> Or are we talking past each other? I was thinking of
>
> function testInnerTML(element) {
> if (! document.getElementWithId("foobar")) {
> element.innerHTML = 'xyzzy';
> if (document.getElementWithId("foobar"))
> return true; // Successfully inserted
> }
> return false; // Insertion failed
> }

That won't tell you if it changed the document or not. It could very
well just be adding a property instead of changing the DOM of the page.

<URL:
http://groups.google.com/group/comp.lang.javascript/browse_frm/thread/f382c40cb5019628/03a7b9973850cde4?tvc=1&q=+metallusions#03a7b9973850cde4
>

Is a very lengthy thread that you might find interesting reading. It
covers a lot of the problems that lead to the semi-solution in the FAQ
and its notes.

>
>>> There is a note which says the getElementWithId function they
>>> define (based on document.all or getElementById) would fail if no
>>> element with that ID exists, but that does not happen with Firefox
>>> or IE 6.
>> Example code? If an ID doesn't exist, then the code shouldn't
>> produce an error but it shouldn't return an element either.
>
> That's how it works for me. The FAQ notes' actual example is
>
> getElementWithId(id).innerHTML = S; return true;
>
> with the getElementWithId above, so I suppose it could just be referring
> to how the .innerHTML part will fail if getElementWithId(id) doesn't
> return an element. But that's a strange objection to the
> getElementWithId implementation.

If my memory serves me correctly, the gEBI emulation in the FAQ was
originally offered to be added by me in fact. The snippet I offered came
from metalusions web site. And to this day, I have always regretted
offering it or even thinking it should be in the FAQ. The only browser
that it comes into play with, that I am aware of, is IE4 and some early
Opera browsers. Browsers that are of the age that they should be dead
and gone by now. The only person I know of that uses IE4 is John Stockton.

> BTW, the FAQ code uses document.all["id/name"], the Microsoft doc says
> document.all("id/name"), and I've seen document.all.id/name too. I
> think I've seen some mention of browsers where one worked an another did
> not, but I don't remember... If it's all the same, I guess one could
> just do
>
> // partial getElementById emulation, if no NAME/ID conflicts.
> if (document.all && !document.getElementById)
> document.getElementById = document.all;
>

<URL: http://www.metalusions.com/backstage/articles/8/ >

if(document.all && !document.getElementById) {
document.getElementById = function(id) {
return document.all[id];
}
}

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

From: Hallvard B Furuseth on 26 Feb 2006 11:25

About the FAQ's Q 4.15 again -- Thanks for the answers so far - I
disappeared just at the time you answered:-)

Randy Webb wrote on 15 Feb 2006:
>Hallvard B Furuseth said the following on 2/10/2006 9:30 AM:
>>Randy Webb writes:
>>>Hallvard B Furuseth said the following on 2/9/2006 1:28 PM:
>>>> (..snip..)
>>>> Also, why does the "Alternative DynWrite function" at
>>>> <http://www.jibbering.com/faq/faq_notes/alt_dynwrite.html> need
>>>> such a lot of tests to find out if innerHTML assignment actually
>>>> works, instead of just inserting 
>>>> and checking if the document now contains an element with that ID?
>>> Because simply checking for that ID doesn't ensure that the element
>>> was actually added to the page.
>> I don't understand. Will some browsers parse the HTML, insert the ID
>> somewhere in the DOM, but not insert the HTML?
>
> document.myDiv.chicken = "This is document.myDiv.chicken";
> alert(document.myDiv.chicken);
>
> What you have to check is that the innerHTML property actually got
> changed instead of just adding a new property to something.

I didn't understand the point of that code until I read the thread you
referred to (below), but your chicken example at the end of the thread
is about a test like

tempVar = element.innerHTML;
element.innerHTML = newHTML;
return (tempVar == element.innerHTML); // .innerHTML is writeable

which would return true if innerHTML was changed to chicken.

Well, except I've substituted 'element' for the three
'document.getElementById(elem)'s, I don't see why I see so much code
which keeps doing getElementById() of the same ID over and over again
instead of doing it once and assigning the result to a variable.

Anyway, I see no reason in the thread you quoted why my function below
might return true if innerHTML is not supported. Note, my "element" is
an element fetched with getElementById or whatever, it's not the
"foobar" element.

>> function testInnerTML(element) {
>> if (! document.getElementWithId("foobar")) {
>> element.innerHTML = 'xyzzy';
>> if (document.getElementWithId("foobar"))
>> return true; // Successfully inserted
>> }
>> return false; // Insertion failed
>> }
>
> That won't tell you if it changed the document or not. It could very
> well just be adding a property instead of changing the DOM of the page.

Only if the browser knows that anything assigned to an .innerHTML
property should be parsed as HTML, so that it will discover that there
is a HTML element with ID "foobar" in the string. Why would it know
and do that if it does not support innerHTML?

Of course it'll return false if a "foobar" element already exists, but
that's OK for me. Just need to give it a weird name.

> <URL:
> http://groups.google.com/group/comp.lang.javascript/browse_frm/thread/f382c40cb5019628/03a7b9973850cde4?tvc=1&q=+metallusions#03a7b9973850cde4
>>
> Is a very lengthy thread that you might find interesting reading. It
> covers a lot of the problems that lead to the semi-solution in the FAQ
> and its notes.

Snipping document.all stuff.

--
Hallvard

| Next | Last
Pages: 1 2
Prev: getElementBy...
Next: Ping