innerHTML vs. replaceChild()

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 <span id="strange name"></span>
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

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

cross-browser backwards compatability and nothing more.
[color=blue]
>
> 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 <span id="strange name"></span>
> and checking if the document now contains an element with that ID?[/color]

Because simply checking for that ID doesn't ensure that the element was
actually added to the page.
[color=blue]
> 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.[/color]

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/

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

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/a...ateelement.asp
http://www.w3.org/TR/2000/WD-DOM-Lev...-one-core.html
[color=blue][color=green]
>> 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 <span id="strange name"></span>
>> and checking if the document now contains an element with that ID?[/color]
>
> Because simply checking for that ID doesn't ensure that the element
> was actually added to the page.[/color]

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 = '<span id="foobar">xyzzy</span>';
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; }
}
[color=blue][color=green]
>> 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.[/color]
>
> Example code? If an ID doesn't exist, then the code shouldn't
> produce an error but it shouldn't return an element either.[/color]

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

Hallvard B Furuseth said the following on 2/10/2006 9:30 AM:[color=blue]
> Randy Webb writes:[color=green]
>> Hallvard B Furuseth said the following on 2/9/2006 1:28 PM:[color=darkred]
>>> Why does the FAQ (Q 4.15) recommend innerHTML when so many here
>>> say one should use createElement(), replaceChild() etc?[/color]
>> cross-browser backwards compatability and nothing more.[/color]
>
> 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.[/color]

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
[color=blue]
> http://msdn.microsoft.com/workshop/a...ateelement.asp
> http://www.w3.org/TR/2000/WD-DOM-Lev...-one-core.html
>[color=green][color=darkred]
>>> 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 <span id="strange name"></span>
>>> and checking if the document now contains an element with that ID?[/color]
>> Because simply checking for that ID doesn't ensure that the element
>> was actually added to the page.[/color]
>
> I don't understand. Will some browsers parse the HTML, insert the ID
> somewhere in the DOM, but not insert the HTML?[/color]

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.

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

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....a7b9973850cde4[color=blue]
>[/color]

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.
[color=blue]
>[color=green][color=darkred]
>>> 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.[/color]
>> Example code? If an ID doesn't exist, then the code shouldn't
>> produce an error but it shouldn't return an element either.[/color]
>
> 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.[/color]

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.
[color=blue]
> 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;
>[/color]


<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/

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:[color=blue]
>Hallvard B Furuseth said the following on 2/10/2006 9:30 AM:[color=green]
>>Randy Webb writes:[color=darkred]
>>>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 <span id="strange name"></span>
>>>> 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.[/color]
>> I don't understand. Will some browsers parse the HTML, insert the ID
>> somewhere in the DOM, but not insert the HTML?[/color]
>
> 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.[/color]

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.
[color=blue][color=green]
>> function testInnerTML(element) {
>> if (! document.getElementWithId("foobar")) {
>> element.innerHTML = '<span id="foobar">xyzzy</span>';
>> if (document.getElementWithId("foobar"))
>> return true; // Successfully inserted
>> }
>> return false; // Insertion failed
>> }[/color]
>
> 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.[/color]

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.
[color=blue]
> <URL:
> http://groups.google.com/group/comp....a7b9973850cde4[color=green]
>>[/color]
> 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.[/color]

Snipping document.all stuff.

--
Hallvard

Hallvard B Furuseth said the following on 2/26/2006 11:25 AM:[color=blue]
> About the FAQ's Q 4.15 again -- Thanks for the answers so far - I
> disappeared just at the time you answered:-)[/color]

I had disc replacement surgery on Feb 10 so I can totally relate to what
you are saying :)
[color=blue]
> Randy Webb wrote on 15 Feb 2006:[color=green]
>> Hallvard B Furuseth said the following on 2/10/2006 9:30 AM:[color=darkred]
>>> 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 <span id="strange name"></span>
>>>>> 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?[/color]
>> 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.[/color]
>
> 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;[/color]

If the browser doesn't support innerHTML, you will get an error on that
line. Attempting to set it first and then read it won't cause an error
(if the browser supports setting properties that way).
[color=blue]
> element.innerHTML = newHTML;
> return (tempVar == element.innerHTML); // .innerHTML is writeable
>
> which would return true if innerHTML was changed to chicken.[/color]

The test in the FAQ Notes is such that it uses "non-normalized" HTML and
reads it back and checks to see if it has been normalized by the browser:

<span id = "someID">Some text</span>

It has that extra spaces in it. If the browser supports changing the
innerHTML then it won't have those extra spaces in the normalized HTML
that it returns from reading innerHTML.
[color=blue]
> 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.[/color]

I saw that in reading it this time, and not last time. You run into a
possible scenario where your function will fail but the browser may
support innerHTML.

If the browser supports innerHTML but it won't read dynamically inserted
ID's, then it will fail, even if it supported changing the innerHTML of
an element.
[color=blue][color=green][color=darkred]
>>> function testInnerTML(element) {
>>> if (! document.getElementWithId("foobar")) {
>>> element.innerHTML = '<span id="foobar">xyzzy</span>';
>>> if (document.getElementWithId("foobar"))
>>> return true; // Successfully inserted
>>> }
>>> return false; // Insertion failed
>>> }[/color]
>> 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.[/color]
>
> 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?[/color]

It could support innerHTML and not support recognizing the dynamically
added ID. The test for innerHTML support in the FAQ Notes was very well
conceived and written, it took a while to come up with it, along with
some very interesting discussions :)
[color=blue]
> 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.
>[color=green]
>> <URL:
>> http://groups.google.com/group/comp....a7b9973850cde4
>> 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.[/color]
>
> Snipping document.all stuff.
>[/color]

<g>

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

Back to FAQ's Q 4.15... I seem to be coming and going - for more
pleasant reasons than yous, fortunately:-) Off to holiday in a few
days...

Randy Webb writes:[color=blue]
>Hallvard B Furuseth said the following on 2/26/2006 11:25 AM:[color=green]
>>(blah blah blah)
>>
>> tempVar = element.innerHTML;[/color]
>
> If the browser doesn't support innerHTML, you will get an error on
> that line. Attempting to set it first and then read it won't cause an
> error (if the browser supports setting properties that way).[/color]

Hm? Firefox, IE and Opera do not fail on 'tempVar = element.urgle;'.
Will some browsers do so? I hope none fail on 'if (document.all)'...

The "Alternative DynWrite()" page does mention a browser which will err
on attempts to test/read/modify HEAD elements. But it wraps those tests
in "if (typeof element.innerHTML == 'string')", maybe that avoids the
problem. Anyway, in my case I'll just avoid .innerHTML for HEAD
elements. And of input elements. And, and, and...
[color=blue][color=green]
>> element.innerHTML = newHTML;
>> return (tempVar == element.innerHTML); // .innerHTML is writeable
>> which would return true if innerHTML was changed to chicken.[/color]
>
> The test in the FAQ Notes is such that it uses "non-normalized" HTML and
> reads it back and checks to see if it has been normalized by the browser:
>
> <span id = "someID">Some text</span>
>
> It has that extra spaces in it. If the browser supports changing the
> innerHTML then it won't have those extra spaces in the normalized HTML
> that it returns from reading innerHTML.[/color]

Yup, that part I get, since it is commented in the DynWrite source:-)
I just didn't use that, my above quotes is about someone else's code.
[color=blue][color=green]
>> (...)
>> 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.[/color]
>
> I saw that in reading it this time, and not last time. You run into a
> possible scenario where your function will fail but the browser may
> support innerHTML.
>
> If the browser supports innerHTML but it won't read dynamically inserted
> ID's, then it will fail, even if it supported changing the innerHTML of
> an element.[/color]

Yuck. Looks like one should be even more careful about innerHTML than I
had yet realized.

Yet the "alternative DynWrite" function also includes such a test, and
will also fail then. So that's not reason to include a test for whether
the HTML code was normalized either.

The reason I can think of is still that some browser might do the
opposite - recognize the dynamically inserted IDs, but not insert the
HTML. Or it could simply be that with innerHTML it's best to be as
paranoid as at all possible.
[color=blue][color=green][color=darkred]
>>>> function testInnerTML(element) {[/color][/color][/color]
if (typeof element.innerHTML == 'string')[color=blue][color=green][color=darkred]
>>>> if (! document.getElementWithId("foobar")) {
>>>> element.innerHTML = '<span id="foobar">xyzzy</span>';
>>>> if (document.getElementWithId("foobar"))
>>>> return true; // Successfully inserted
>>>> }
>>>> return false; // Insertion failed
>>>> }[/color][/color]
>
> (...) The test for innerHTML support in the FAQ Notes was very well
> conceived and written, it took a while to come up with it, along with
> some very interesting discussions :)[/color]

Having read far too many threads about innerHTML I'm realizing even more
detail in there than the source discusses - I just don't understand it,
and would still like to.

It does have a bug: The inner if() needs "else el.innerHTML = inH;".
Otherwise, if .innerHTML is partially supported but DynWrite() does not
realize that, the function will insert <sTrOnG Id='tSt' >test</StRoNg >
in the document and leave it there. E.g. if the browser updates the
HTML but not dynamically inserted IDs, like you said above.
The same applies to my function.

BTW, any special reason to use <strong>? I'd think something less
visible would be better for the test, like <span> or <tt>.

--
Hallvard

Hallvard B Furuseth wrote:
[color=blue]
> Randy Webb writes:[color=green]
>> Hallvard B Furuseth said the following on 2/26/2006 11:25 AM:[color=darkred]
>>> [...]
>>> tempVar = element.innerHTML;[/color]
>>
>> If the browser doesn't support innerHTML, you will get an error on
>> that line. Attempting to set it first and then read it won't cause an
>> error (if the browser supports setting properties that way).[/color][/color]

There will only be an error if `element' is a null object reference,
throwing a ReferenceError exception then. So far all known DOM
implementations work according to the [[Get]] property access method
of the ECMAScript specification (although they do not have to).
Therefore, if `innerHTML' is not supported, the reference evaluates
to `undefined', and nothing breaks.

Unconditional _write_ ([[Put]] property) access to the `innerHTML'
property is a different thing, though.
[color=blue]
> Hm? Firefox, IE and Opera do not fail on 'tempVar = element.urgle;'.[/color]

As expected. (However, Firefox's error console would yield a warning here.)
[color=blue]
> Will some browsers do so?[/color]

I know of none.
[color=blue]
> I hope none fail on 'if (document.all)'...[/color]

That depends on how you define `fail'. This breaks in no known user agent
breaks, but not all user agents evaluate `document.all' to `true' here.
[color=blue]
> The "Alternative DynWrite()" page does mention a browser which will err
> on attempts to test/read/modify HEAD elements. But it wraps those tests
> in "if (typeof element.innerHTML == 'string')", maybe that avoids the
> problem.[/color]

If there is a problem, yes. A `typeof' operation only evaluates the type
of its argument, not its value. So there is no [[Get]] property access
then.
[color=blue]
> Anyway, in my case I'll just avoid .innerHTML for HEAD elements.[/color]

Good man.
[color=blue]
> and of input elements.[/color]

Pardon?
[color=blue]
> And, and, and...[/color]

There are good reasons to use `innerHTML' _occasionally_, though. Splitting
text nodes to insert an element for a word, for example, can be a real PITA
with standards compliant DOM access. I posted an example the other day.
[color=blue][color=green]
>> If the browser supports innerHTML but it won't read dynamically inserted
>> ID's, then it will fail, even if it supported changing the innerHTML of
>> an element.[/color]
>
> Yuck. Looks like one should be even more careful about innerHTML than I
> had yet realized.[/color]

Yet I wonder if such a user agent even exists or could exist successfully
in the future. I know of none.
[color=blue]
> [...]
> The reason I can think of is still that some browser might do the
> opposite - recognize the dynamically inserted IDs, but not insert the
> HTML.[/color]

Improbable. Markup has to be parsed into a tree before the respective
element nodes and text nodes can be inserted. (Which is the main
drawback of using innerHTML & Co. compared to W3C DOM methods.)
[color=blue]
> Or it could simply be that with innerHTML it's best to be as
> paranoid as at all possible.[/color]

Seldom good things come from paranoia, if that.
[color=blue]
> BTW, any special reason to use <strong>?[/color]

To mark up <strong>very important</strong> text content. Ref. <em>...</em>.
[color=blue]
> I'd think something less visible would be better for the test,
> like <span> or <tt>.[/color]

<span style="font-weight:bold">foo</span> cannot tell a screen reader that
"foo" is very important and therefore has to be strongly emphasized. And
`strong' elements are usually rendered bold (as being strongly emphasized
compared to the rest of the text), so you can address both visual and aural
user agents with only one element. (I would define a rule with emphasizing
aural CSS properties for `strong', however a screen reader is likely to
have it in its basic stylesheet already.)

The `tt' (teletype) element is for text content that should be marked up
as being typed by the user, such as commands in a manual or tutorial.
Therefore it is often rendered as teletype or monospaced text. See the
specs.


HTH

PointedEars

Thomas 'PointedEars' Lahn writes:[color=blue]
>Hallvard B Furuseth wrote:[color=green]
>>Randy Webb writes:[color=darkred]
>>>Hallvard B Furuseth said the following on 2/26/2006 11:25 AM:
>>>> [...]
>>>> tempVar = element.innerHTML;
>>>
>>> If the browser doesn't support innerHTML, you will get an error on
>>> that line. Attempting to set it first and then read it won't cause an
>>> error (if the browser supports setting properties that way).[/color][/color]
>
> There will only be an error if `element' is a null object reference,
> throwing a ReferenceError exception then. (...)[/color]

Ah, good. That's easy enough to test.
[color=blue]
> Unconditional _write_ ([[Put]] property) access to the `innerHTML'
> property is a different thing, though.
>[color=green]
>> Hm? Firefox, IE and Opera do not fail on 'tempVar = element.urgle;'.[/color]
>
> As expected. (However, Firefox's error console would yield a warning here.)[/color]

Mine doesn't. (Still version 1.0.7.)
[color=blue]
> (...)
>[color=green]
>> The "Alternative DynWrite()" page does mention a browser which will err
>> on attempts to test/read/modify HEAD elements. But it wraps those tests
>> in "if (typeof element.innerHTML == 'string')", maybe that avoids the
>> problem.[/color]
>
> If there is a problem, yes. A `typeof' operation only evaluates the type
> of its argument, not its value. So there is no [[Get]] property access
> then.[/color]

Yes it does, unless typeof(element.innerHTML) is treated specially.
Types belong to values, not variables. The EcmaScript spec says typeof
UnaryExpression does evaluate UnaryExpression. I just tested that it
did, with typeof some_function(). Maybe you are thinking of C/C++.
[color=blue][color=green]
>> Anyway, in my case I'll just avoid .innerHTML for HEAD elements.[/color]
>
> Good man.
>[color=green]
>> and of input elements.[/color]
>
> Pardon?[/color]

Just one of the things some site said innerHTML does not work for, with
some web browser. Might have been about IE4 or something equally
ancient, I don't remember.
[color=blue]
> (...)[/color]
[color=blue][color=green][color=darkred]
>>> If the browser supports innerHTML but it won't read dynamically inserted
>>> ID's, then it will fail, even if it supported changing the innerHTML of
>>> an element.[/color]
>>
>> Yuck. Looks like one should be even more careful about innerHTML than I
>> had yet realized.[/color]
>
> Yet I wonder if such a user agent even exists or could exist successfully
> in the future. I know of none.[/color]

That doesn't bother me much anyway. If my page incorrectly decides that
innerHTML doesn't work, it just omits some functionality. It would be
worse if it incorrectly decided innerHTML does works.
[color=blue][color=green]
>> The reason I can think of is still that some browser might do the
>> opposite - recognize the dynamically inserted IDs, but not insert the
>> HTML.[/color]
>
> Improbable. Markup has to be parsed into a tree before the respective
> element nodes and text nodes can be inserted.[/color]

Yes, I can't imagine why it would fail that way. I was just speculating
about why the alternative DynWrite() function is written as it is.
[color=blue]
> (Which is the main
> drawback of using innerHTML & Co. compared to W3C DOM methods.)[/color]

Yup. But I'll want to support non-W3C DOM browser for a while yet.
Tried to write a wrapper which tried either, but that got too much
bother pretty fast.
[color=blue][color=green]
>> Or it could simply be that with innerHTML it's best to be as
>> paranoid as at all possible.[/color]
>
> Seldom good things come from paranoia, if that.
>[color=green]
>> BTW, any special reason to use <strong>?[/color]
>
> To mark up <strong>very important</strong> text content. Ref. <em>...</em>.[/color]

Um. perhaps I should have clarified that I was talking abotu the
functionality test in the "alternative DynWrite()" at
<http://www.jibbering.com/faq/faq_notes/alt_dynwrite.html>.

This test isn't very important to the user, only to the JavaScript
programmer. For the user, the testing ought to be smooth and mostly
invisible, not a brief <strong> flash with "I'm testing strange things
here".
[color=blue][color=green]
>> I'd think something less visible would be better for the test,
>> like <span> or <tt>.[/color]
>
> <span style="font-weight:bold">foo</span> cannot tell a screen reader that
> "foo" is very important and therefore has to be strongly emphasized. And
> `strong' elements are usually rendered bold (as being strongly emphasized
> compared to the rest of the text), so you can address both visual and aural
> user agents with only one element. (I would define a rule with emphasizing
> aural CSS properties for `strong', however a screen reader is likely to
> have it in its basic stylesheet already.)
>
> The `tt' (teletype) element is for text content that should be marked up
> as being typed by the user, such as commands in a manual or tutorial.
> Therefore it is often rendered as teletype or monospaced text. See the
> specs.[/color]

--
Hallvard

Hallvard B Furuseth said the following on 3/8/2006 12:57 PM:[color=blue]
> Back to FAQ's Q 4.15... I seem to be coming and going - for more
> pleasant reasons than yous, fortunately:-) Off to holiday in a few
> days...[/color]

Add two pulled teeth in the last two days and it gets more fun :) Hope
your holiday was good though.
[color=blue]
> Randy Webb writes:[color=green]
>> Hallvard B Furuseth said the following on 2/26/2006 11:25 AM:[color=darkred]
>>> (blah blah blah)
>>>
>>> tempVar = element.innerHTML;[/color]
>> If the browser doesn't support innerHTML, you will get an error on
>> that line. Attempting to set it first and then read it won't cause an
>> error (if the browser supports setting properties that way).[/color]
>
> Hm? Firefox, IE and Opera do not fail on 'tempVar = element.urgle;'.
> Will some browsers do so? I hope none fail on 'if (document.all)'...[/color]

No it doesn't, but alerting tempVar will give you undefined. Not a very
good test. Not sure why I said that though, I don't remember to be honest.
[color=blue]
> The "Alternative DynWrite()" page does mention a browser which will err
> on attempts to test/read/modify HEAD elements. But it wraps those tests
> in "if (typeof element.innerHTML == 'string')", maybe that avoids the
> problem. Anyway, in my case I'll just avoid .innerHTML for HEAD
> elements. And of input elements. And, and, and...[/color]

I never modify the head via innerHTML so I don't know :) And I don't
create forms with innerHTML either.
[color=blue][color=green][color=darkred]
>>> element.innerHTML = newHTML;
>>> return (tempVar == element.innerHTML); // .innerHTML is writeable
>>> which would return true if innerHTML was changed to chicken.[/color]
>> The test in the FAQ Notes is such that it uses "non-normalized" HTML and
>> reads it back and checks to see if it has been normalized by the browser:
>>
>> <span id = "someID">Some text</span>
>>
>> It has that extra spaces in it. If the browser supports changing the
>> innerHTML then it won't have those extra spaces in the normalized HTML
>> that it returns from reading innerHTML.[/color]
>
> Yup, that part I get, since it is commented in the DynWrite source:-)
> I just didn't use that, my above quotes is about someone else's code.[/color]

Gotcha.
[color=blue][color=green][color=darkred]
>>> (...)
>>> 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.[/color]
>> I saw that in reading it this time, and not last time. You run into a
>> possible scenario where your function will fail but the browser may
>> support innerHTML.
>>
>> If the browser supports innerHTML but it won't read dynamically inserted
>> ID's, then it will fail, even if it supported changing the innerHTML of
>> an element.[/color]
>
> Yuck. Looks like one should be even more careful about innerHTML than I
> had yet realized.[/color]

innerHTML is expensive in terms of memory also when compared to DOM
methods, some even in IE.
[color=blue]
> Yet the "alternative DynWrite" function also includes such a test, and
> will also fail then. So that's not reason to include a test for whether
> the HTML code was normalized either.[/color]


[color=blue]
> The reason I can think of is still that some browser might do the
> opposite - recognize the dynamically inserted IDs, but not insert the
> HTML. Or it could simply be that with innerHTML it's best to be as
> paranoid as at all possible.[/color]

If it recognized dynamically created/inserted ID's but not innerHTML it
would totally shock me. But, it could happen.
[color=blue][color=green][color=darkred]
>>>>> function testInnerTML(element) {[/color][/color]
> if (typeof element.innerHTML == 'string')[color=green][color=darkred]
>>>>> if (! document.getElementWithId("foobar")) {
>>>>> element.innerHTML = '<span id="foobar">xyzzy</span>';
>>>>> if (document.getElementWithId("foobar"))
>>>>> return true; // Successfully inserted
>>>>> }
>>>>> return false; // Insertion failed
>>>>> }[/color]
>> (...) The test for innerHTML support in the FAQ Notes was very well
>> conceived and written, it took a while to come up with it, along with
>> some very interesting discussions :)[/color]
>
> Having read far too many threads about innerHTML I'm realizing even more
> detail in there than the source discusses - I just don't understand it,
> and would still like to.[/color]

What parts? (You are trying to make me read all those notes aren't you! :)
[color=blue]
> It does have a bug: The inner if() needs "else el.innerHTML = inH;".
> Otherwise, if .innerHTML is partially supported but DynWrite() does not
> realize that, the function will insert <sTrOnG Id='tSt' >test</StRoNg >
> in the document and leave it there. E.g. if the browser updates the
> HTML but not dynamically inserted IDs, like you said above.
> The same applies to my function.[/color]

If I were putting a test in DynWrite, or any other function to test
innerHTML, the element I attempted to insert it in would be hidden via
CSS so that the user wouldn't see it.
[color=blue]
> BTW, any special reason to use <strong>? I'd think something less
> visible would be better for the test, like <span> or <tt>.[/color]

Any reason for Strong versus span? Not that I am aware of. The entire
purpose of that test is to see if the browser normalized it or not, not
necessarily the code it normalized but the normalizing itself.

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