innerHTML doesn't work on IE?

[laredotornado]

Hi,

I have this HTML on my page

<table align="left" class="appAdmin dojoTabular">
<thead>
<tr>
<th align="center">Refresh URL</th>
<th align="center">Result</th>
</tr>
</thead>
<tbody id="thebody">
</tbody>
</table>

but when I execute the following JS on PC IE 7.0.5, I get a JS error
("Unknown runtime error") that doesn't occur on Firefox ...

var tbody = document.getElementById("thebody");
alert(tbody); // Produces "[object]"
tbody.innerHTML = ''; // JS error

I"m sure I'm missing something really obvious. Can you help? Thanks,
- Dave

 

[Gregor Kofler]

laredotornado meinte:

[snip]

but when I execute the following JS on PC IE 7.0.5, I get a JS error
("Unknown runtime error") that doesn't occur on Firefox ...
[snip]

I"m sure I'm missing something really obvious.

Yes. Called "Google". Using this SE with "internet explorer table
innerhtml" yields
http://support.microsoft.com/kb/239832

You've to read it for yourself, though.

Gregor

 

[Jeremy J Starcher]

Hi,

I have this HTML on my page

[html snipped]

but when I execute the following JS on PC IE 7.0.5, I get a JS error
("Unknown runtime error") that doesn't occur on Firefox ...

innerHTML is read-only with some table elements in IE.

I recommend avoiding innerHTML in [almost] any usage and going with
proper DOM access. Outside of IE's oddities, other user-agents have
their own different issues.

 

[laredotornado]

Hi,

I have this HTML on my page

[html snipped]

but when I execute the following JS on PC IE 7.0.5, I get a JS error
("Unknown runtime error") that doesn't occur on Firefox ...

innerHTML is read-only with some table elements in IE.  

I recommend avoiding innerHTML in [almost] any usage and going with
proper DOM access.  Outside of IE's oddities, other user-agents have
their own different issues.

What is proper DOM access in the case of setting innerHTML? Thanks, -
Dave

 

[Jeremy J Starcher]

I recommend avoiding innerHTML in [almost] any usage and going with
proper DOM access.  Outside of IE's oddities, other user-agents have
their own different issues.

What is proper DOM access in the case of setting innerHTML? Thanks, -
Dave

document.createElement and friends.
< https://developer.mozilla.org/en/DOM/document.createElement >

 

[beegee]

innerHTML is read-only with some table elements in IE.

I recommend avoiding innerHTML in [almost] any usage and going with
proper DOM access. Outside of IE's oddities, other user-agents have
their own different issues.

Interesting. However, using DOM methods to create a large table
requires finesse and quite a bit of book keeping. For instance
creating a table from the outside in (appending trs to the table and
then tds to the trs) is extremely inefficient and will be quite slow
in large tables. Creating them from the inside out is fast but takes
a lot of planning.

I would suggest to the OP to do away with thead and tbody and just use
innerHTML on a tr containing another table. It would accomplish the
same thing.

Bob

 

[Gregor Kofler]

beegee meinte:

Interesting. However, using DOM methods to create a large table
requires finesse and quite a bit of book keeping. For instance
creating a table from the outside in (appending trs to the table and
then tds to the trs) is extremely inefficient and will be quite slow
in large tables. Creating them from the inside out is fast but takes
a lot of planning.

I can't see the serious difficulties of the latter approach, but why is
it so much slower? We are talking about non document-tree-attached
tables, right?

Gregor

 

[RobG]

ntime error") that doesn't occur on Firefox ...

innerHTML is read-only with some table elements in IE.

I recommend avoiding innerHTML in [almost] any usage and going with
proper DOM access.  Outside of IE's oddities, other user-agents have
their own different issues.

Interesting.  However, using DOM methods to create a large table
requires finesse and quite a bit of book keeping.

It doesn't require any more effort on the programmers part, though it
might be slower in some browsers.

 For instance
creating a table from the outside in (appending trs to the table and
then tds to the trs) is extremely inefficient and will be quite slow
in large tables.

Inefficient? How? Building the HTML for a table to use with innerHTML
requires exactly the strategy. Also, there are convenience methods
for insertRow and insertCell:

<URL: http://www.w3.org/TR/DOM-Level-2-HTML/html.html#ID-39872903 >

 Creating them from the inside out is fast but takes
a lot of planning.

Horses for courses I suppose, but I don't see how these strategies
apply to only DOM or innerHTML tables.

I would suggest to the OP to do away with thead and tbody and just use
innerHTML on a tr containing another table. It would accomplish the
same thing.

I presume you mean insert the table in a td, since a table in a tr
would be invalid. I don't see how inserting a table in a td is any
different to inserting it in any other (valid) element. The logic for
constructing a table is the same whether innerHTML or DOM is used -
content must be wrapped in cells, cells by rows and rows by a table or
tableSection element. The use of helper functions can reduce the
difference in complexity to zero.

A tbody is not necessarily required when using DOM methods (see
insertRow above), it's only required if createElement is used instead
of insertRow to create rows (last time I tested, createElement('tr')
was faster than insertRow).

If you want to insert cells in a row or rows in a table, DOM methods
are much easier and more reliable.

 

[beegee]

It doesn't require any more effort on the programmers part, though it
might be slower in some browsers.

Yes it does require more effort due to my point below.

Inefficient? How? Building the HTML for a table to use with innerHTML
requires exactly the strategy. Also, there are convenience methods
for insertRow and insertCell:

Even with the convenience methods if you build the table from the
outside in, the DOM will re-render your table with EVERY append to a
parent! From the inside-out, the whole table doesn't get rendered
until the last append.

Much faster and simpler to use innerHTML. There are, of course, many
places where using the DOM methods are the only way to go. For the
OP's problem, though, I wouldn't suggest it.

Bob

 

[Thomas 'PointedEars' Lahn]

Yes it does require more effort due to my point below.

We'll see.

Even with the convenience methods if you build the table from the
outside in, the DOM will re-render your table with EVERY append to a
parent!  From the inside-out, the whole table doesn't get rendered
until the last append.

Please define "outside in" and "inside-out".

Much faster and simpler to use innerHTML.  [...]

Since there are known problems with using `innerHTML' within tables,
it should not be used there, wouldn't you say?


PointedEars

 

[Thomas 'PointedEars' Lahn]

On Thu, 08 Jan 2009 06:25:02 -0800, beegee wrote:
[ Comments about building tables snipped ]

Even with the convenience methods if you build the table from the
outside in, the DOM will re-render your table with EVERY append to a
parent! From the inside-out, the whole table doesn't get rendered until
the last append.

documentFragment can be your friend.

I don't understand that comment just now, please elaborate.

However, is it not much more simple (and compatible)? Set the table to
..display="none" when building it, and to .display="table" or "block" when
its done?


PointedEars

 

[Jeremy J Starcher]

On Thu, 08 Jan 2009 06:25:02 -0800, beegee wrote: [ Comments about
building tables snipped ]

Even with the convenience methods if you build the table from the
outside in, the DOM will re-render your table with EVERY append to a
parent! From the inside-out, the whole table doesn't get rendered
until the last append.

documentFragment can be your friend.

I don't understand that comment just now, please elaborate.

For those who have not used document fragments. They seem to be a little-
used method.

However, is it not much more simple (and compatible)? Set the table to
.display="none" when building it, and to .display="table" or "block"
when its done?

I found document fragments to be faster in my instance.

(In other cases, such as in GreaseMonkey scripts, document fragments are
a nice place to store bits things as one is moving elements around within
the document. The alternative would have been storing them inside of
DIV's or other structures.)

 

[Thomas 'PointedEars' Lahn]

beegee wrote:
[Comments about building tables snipped ]
Even with the convenience methods if you build the table from the
outside in, the DOM will re-render your table with EVERY append to a
parent! From the inside-out, the whole table doesn't get rendered
until the last append.
documentFragment can be your friend.

I don't understand that comment just now, please elaborate.

For those who have not used document fragments. They seem to be a little-
used method.

<https://developer.mozilla.org/en/DOM/document.createDocumentFragment>

I see. Very nice. Rest assured the Matrix has you! ;-)


PointedEars

 

[beegee]

Please define "outside in" and "inside-out".

Pseudo code:

Outside-in:

tbl = createElement("<table>")

outerLoop:
row = tbl.InsertRow
innerLoop:
cell = row.InsertCell






Inside-out
Loop1:
arrRows = CreateElement("<tr>")
innerLoop:
cell = arrRows.InsertCell

tbl = CreateElement("<table>")
Loop2:
tbl.appendChild(arrRows[j])


Outside-in looks cleaner and faster but actually Inside-out is more
efficient, many less re-renders. Again though,
tbl.innerHTML = theWholeTableGuts is by far the fastest.

Bob

 

[Gregor Kofler]

beegee meinte:

tbl.innerHTML = theWholeTableGuts is by far the fastest.

In which browser? And have you considered the creation time of the
properly masked innerHTML string? IIRC several benchmarks showed an
overall *slight* advantage of innerHTML when compared to createElement
(IMO there are way too many factors to allow a generalizing statement,
definitely not one qualifiying as "by far the fastest"). And all the
speed gain is lost, when you have to address nodes in the freshly
created fragment, which is rather "normal".

Gregor

 

[Jorge]

Outside-in looks cleaner and faster but actually Inside-out is more
efficient, many less re-renders. Again though,
tbl.innerHTML = theWholeTableGuts is by far the fastest.

Bob

Bob, ISTM that nothing is rendered until it's inserted into the
<body>. And then, only if it's visible.

 

[Jorge]

beegee meinte:


In which browser? And have you considered the creation time of the
properly masked innerHTML string? IIRC several benchmarks showed an
overall *slight* advantage of innerHTML when compared to createElement

I remember Crockford saying that "innerHTML" is demon-fast, as it uses
the browser's built-in (and usually highly-optimized) HTML parser. But
sure your other points still apply.

 

[beegee]

Bob, ISTM that nothing is rendered until it's inserted into the
<body>. And then, only if it's visible.

Well that would be news to me. It would be easy enough to check out by
seeing when coordinate members to the DOM nodes get filled in in the
debugger. I wish I could remember who first brought this to my
attention. It was either a javascript quiz at AjaxWorld or one of
those tutorials on YUI Theater. But if what you suppose is true, then
why documentfragments? Obviously if it is true then my whole point is
invalid, we should go ahead and create our huge tables with DOM
methods in any order we desire and then append the table to a
container that's already a part of the body.

Bob

 

[Gregor Kofler]

beegee meinte:
I'd think so, too. What should the browser "render" if it either not
attached to the tree or not visible?

Well that would be news to me. It would be easy enough to check out by
seeing when coordinate members to the DOM nodes get filled in in the
debugger. I wish I could remember who first brought this to my
attention. It was either a javascript quiz at AjaxWorld or one of
those tutorials on YUI Theater. But if what you suppose is true, then
why documentfragments?

Since appending a documentFragment to another node only appends the
childnodes of the fragment. With another type of parentnode one has to
iterate through the childnodes and append it one by one to the new
parentnode.

Obviously if it is true then my whole point is
invalid, we should go ahead and create our huge tables with DOM
methods in any order we desire and then append the table to a
container that's already a part of the body.

That's what I frequently do.

Gregor

 

[Jorge]

(...)
But if what you suppose is true, then
why documentfragments?  Obviously if it is true then my whole point is
invalid, we should go ahead and create our huge tables with DOM
methods in any order we desire and then append the table to a
container that's already a part of the body.

Look at this: <http://jorgechamorro.com/cljs/014/>

See how the fps rate goes up when the table's display: is "none" ?