Creating DOM elements in IE before page complete

[dd]

Has anyone found a way around the problem IE has if you create elements
(script or div, doesn't seem to matter) BEFORE the document.readyS tate
is "complete" ?

I know you can sometimes get away with only waiting for "interactiv e"
state, but I've found that on some pages, that can result in a weird
error with a dialog box along the lines of "Internet operation aborted
error" (or something like that, I haven't seen it for a long time since
I implemented the having to wait for "complete" so I can't be sure of
the wording).

I'd really like to be able to dynamically create script and div
elements without waiting for at least interactive. In a related
question, does anyone know why some pages don't get past interactive
state despite the status bar showing "done" ? You can see how that's
naturally screwing me up if I'm waiting for complete and/or an onload
event.

[RobG]

dd wrote:

Has anyone found a way around the problem IE has if you create elements
(script or div, doesn't seem to matter) BEFORE the document.readyS tate
is "complete" ?

AFAIK, document.readyS tate is a Microsoft invention introduced in
support of FrontPage extensions; it has been adopted by some other
browsers (but not Firefox AFAIK). The readyState property is also part
of the (Microsoft inspired) XMLHttpRequest Object specification[1], but
as a property of the request object, not the document.

If you want to know when you can safely start modifying the document,
your best bet is to wait for the load event (window.onload =
someFunction).

If you want to do DOM changes before then, then you need to wait for
elements to exist (e.g. place the script immediately after the closing
tag of the element you want to modify). If you are doing it from the
head and before the load event has occurred, expect problems.

>
I know you can sometimes get away with only waiting for "interactiv e"
state, but I've found that on some pages, that can result in a weird
error with a dialog box along the lines of "Internet operation aborted
error" (or something like that, I haven't seen it for a long time since
I implemented the having to wait for "complete" so I can't be sure of
the wording).

I'd really like to be able to dynamically create script and div
elements without waiting for at least interactive. In a related
question, does anyone know why some pages don't get past interactive
state despite the status bar showing "done" ? You can see how that's
naturally screwing me up if I'm waiting for complete and/or an onload
event.

That sounds very IE-specific. If that is your intention, you should
try an IE forum with a link to a test page.
1. 3rd working draft: <URL: http://www.w3.org/TR/XMLHttpRequest/ >

--
Rob

[dd]

RobG wrote:

If you want to know when you can safely start modifying the document,
your best bet is to wait for the load event (window.onload = someFunction).
If you want to do DOM changes before then, then you need to wait for
elements to exist (e.g. place the script immediately after the closing
tag of the element you want to modify). If you are doing it from the
head and before the load event has occurred, expect problems.

Yeah, I've been hoping to avoid that. My code is deployed within the
body
so the </bodytag definitely won't have been executed yet. I think
when
that happens the state of the document changes to "interactiv e" while
it's
waiting for images to finish loading. Somehow even this is too early
sometimes though.

RobG wrote:

That sounds very IE-specific. If that is your intention, you should
try an IE forum with a link to a test page.

Yeah I've tried IE forums in the past without success. I wasn't really
expecting
a successful answer. Everything I've seen in the past indicate I need
to wait
for onload. It was worth a try :)

[VK]

dd wrote:

Has anyone found a way around the problem IE has if you create elements
(script or div, doesn't seem to matter) BEFORE the document.readyS tate
is "complete" ?

Before the page is loaded, the document DOM tree is not completed yet.
Respectively you cannot manipulate something that doesn't exist yet:
same way as you cannot set up furniture in a flat before the floor is
build up. There is no difference in this aspect between browsers.

On the loading stage you have text input stream from the server being
sent to (X)HTML parser, this is all. What you can do on this stage is
to temporarily switch the input stream from the server to your script,
output the needed text stream segment to the parser and switch back to
the server-generated stream. In javascript you do it by using
document.write( ) method.

.... HTML page source ...
<script type="text/javascript">
document.write( yourSourceToPar se);
</script>
.... the rest of HTML page source

[dd]

VK wrote:

Before the page is loaded, the document DOM tree is not completed yet.

That I agree with.

Respectively you cannot manipulate something that doesn't exist yet:

Not quite what you first said. I agree it's not complete, but to say
it doesn't exist is going a bit far. It does exist, it's just not
complete.

VK wrote:

same way as you cannot set up furniture in a flat before the floor is
build up.

Taking that analogy too far I think. I'd say the floor in the flat is
busy
being built by a few guys going from one side of the room to the other
and I'm just asking them if I can place some furniture "behind them"
onto the piece of floor they've already finished, even if the glue
isn't
dry yet :)

VK wrote:

There is no difference in this aspect between browsers.

There's a HUGE difference. All other browsers allow inserting/adding
of items to the DOM before the page has finished parsing. Only IE
has a hissy fit if you mess with the incomplete floor.

[VK]

dd wrote:

VK wrote:

Before the page is loaded, the document DOM tree is not completed yet.

That I agree with.

Respectively you cannot manipulate something that doesn't exist yet:

Not quite what you first said. I agree it's not complete, but to say
it doesn't exist is going a bit far. It does exist, it's just not
complete.

It doesn't exist as a finalized scriptable unit where you could apply
DOM methods.

VK wrote:

same way as you cannot set up furniture in a flat before the floor is
build up.

Taking that analogy too far I think. I'd say the floor in the flat is
busy
being built by a few guys going from one side of the room to the other
and I'm just asking them if I can place some furniture "behind them"
onto the piece of floor they've already finished, even if the glue
isn't
dry yet :)

And they kick you out plus giving a nock to the behind: until the level
is finished: for personnel only.
:-)

VK wrote:

There is no difference in this aspect between browsers.

There's a HUGE difference.

Noop. You are cheated by the parser optimisation and look-ahead
mechanics. Try this for instance:

<html>
<head>
<title>Untitl ed Document</title>
<meta http-equiv="Content-Type"
content="text/html; charset=iso-8859-1">
</head>
<body>
<h1>Header</h1>
<script>
try {
var p = document.create Element('p');
p.innerHTML = '<em>Extra paragraph</em>';
document.body.a ppendChild(p);
}
catch(e) {
document.write( '<p style="color:re d">' + e.message + '</p>');
}
</script>
<p>Paragraph</p>
</body>
</html>

Both FF and IE will show "Extra paragraph". Did you really managed to
script DOM Tree before it came into existence? No at all. The parser
just gave a micro-delay in script execution to see if it can parse and
finalize DOM during this delay. So your inline script in fact was
implicetly converted into window.onload=a ddParagraph.

Can you relay on this behavior? I would insistently suggest never do
it. Next time you page will be more complicated or connection slower
and oops: "document.b ody is null or not an object".

Once again, for any robust solution the mantra is:

before page load event - document.write only
after page load event - DOM methods only
Ommm...
....
before page load event - document.write only
after page load event - DOM methods only
Ommm...
....

Repeat 10 times before go to bed and the life becomes much more easy
and your customers will stay happy, and money will stay in your house.

:-)

[Richard Cornford]

VK wrote:
<snip>

VK wrote:

There is no difference in this aspect between browsers.

There's a HUGE difference.

Noop. You are cheated by the parser optimisation and look-ahead
mechanics. Try this for instance:

<html>
<head>
<title>Untitl ed Document</title>
<meta http-equiv="Content-Type"
content="text/html; charset=iso-8859-1">
</head>
<body>
<h1>Header</h1>
<script>
try {
var p = document.create Element('p');
p.innerHTML = '<em>Extra paragraph</em>';
document.body.a ppendChild(p);
}
catch(e) {
document.write( '<p style="color:re d">' + e.message + '</p>');
}
</script>
<p>Paragraph</p>
</body>
</html>

Both FF and IE will show "Extra paragraph".

But they both (and Opera for that matter) show "Extra paragraph" above
"Paragraph" and below "Header", suggesting that it was inserted into
the DOM before the pragraph element defined in the HTML source.

Did you really managed to script DOM Tree before it came into
existence? No at all.

No, but it was scripted before it was finished, and certainly before
all the HTML had been parsed into DOM nodes.

The parser just gave a micro-delay in script execution

You just love to make this rubbish up off the top of your head.

to see if it can parse and finalize DOM during this delay.

You have no evidence for this, and your code contradicts it as the -
document.body.a ppendChild(p); - line appears to have appended the new
paragraph to the BODY element at precisely the point where the line of
code was called. Thus the new paragraph is the nextSibling of the
SCRIPT element and the previousSibling of the P element defined in the
HTML.

So your inline script in fact was
implicetly converted into window.onload=a ddParagraph.

<snip>

If that were true then the new paragraph would have been appended at
the end of the BODY element, as its last child, and so _after_ the
paragraph that was defined in the HTML. In reality it was clearly
inserted before that paragraph, and so your assertion is, as usual,
false.

I realise that analysis has never been one of your skills but even you
should have been able to look at the order of output on the page and
seen that what you were proposing made no sense what so ever.

Richard.

[Randy Webb]

RobG said the following on 1/8/2007 1:21 AM:

<snip>

1. 3rd working draft: <URL: http://www.w3.org/TR/XMLHttpRequest/ >

<quote>
A future version or extension of this specification will define a way of
doing cross-site requests.
</quote>

"cross-site"? I have never liked the way those documents are worded. Is
that the same as cross-domain or is it referring to sub-domains?

--
Randy
Chance Favors The Prepared Mind
comp.lang.javas cript FAQ - http://jibbering.com/faq/index.html
Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/

[dd]

VK wrote:

>
Both FF and IE will show "Extra paragraph". Did you really managed to
script DOM Tree before it came into existence? No at all. The parser
just gave a micro-delay in script execution to see if it can parse and
finalize DOM during this delay. So your inline script in fact was
implicetly converted into window.onload=a ddParagraph.

No, it did exist. Both show Extra paragraph before paragraph
implying it worked exactly the same as a document.write. I've
always known that would be the case.

My problem is that if you do that on IE, then somehow the
DOM becomes instable and can lead to later errors of the
likes of "Internet operation aborted". It was happening when
I was loading content into iframes dynamically. When I went
back to the earlier apparently unrelated DOM additions and
made them wait for "complete" then my dynamic loading into
iframes no longer got that error.