Creating DOM elements in IE before page complete

Discussion in 'Javascript' started by dd, Jan 8, 2007.

  1. dd

    dd Guest

    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.readyState
    is "complete" ?

    I know you can sometimes get away with only waiting for "interactive"
    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.
     
    dd, Jan 8, 2007
    #1
    1. Advertising

  2. dd

    RobG Guest

    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.readyState
    > is "complete" ?


    AFAIK, document.readyState 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 "interactive"
    > 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
     
    RobG, Jan 8, 2007
    #2
    1. Advertising

  3. dd

    dd Guest

    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 </body> tag definitely won't have been executed yet. I think
    when
    that happens the state of the document changes to "interactive" 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 :)
     
    dd, Jan 8, 2007
    #3
  4. dd

    VK Guest

    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.readyState
    > 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(yourSourceToParse);
    </script>
    .... the rest of HTML page source
     
    VK, Jan 8, 2007
    #4
  5. dd

    dd Guest

    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.
     
    dd, Jan 8, 2007
    #5
  6. dd

    VK Guest

    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>Untitled Document</title>
    <meta http-equiv="Content-Type"
    content="text/html; charset=iso-8859-1">
    </head>
    <body>
    <h1>Header</h1>
    <script>
    try {
    var p = document.createElement('p');
    p.innerHTML = '<em>Extra paragraph</em>';
    document.body.appendChild(p);
    }
    catch(e) {
    document.write('<p style="color:red">' + 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=addParagraph.

    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.body 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.

    :)
     
    VK, Jan 8, 2007
    #6
  7. 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>Untitled Document</title>
    > <meta http-equiv="Content-Type"
    > content="text/html; charset=iso-8859-1">
    > </head>
    > <body>
    > <h1>Header</h1>
    > <script>
    > try {
    > var p = document.createElement('p');
    > p.innerHTML = '<em>Extra paragraph</em>';
    > document.body.appendChild(p);
    > }
    > catch(e) {
    > document.write('<p style="color:red">' + 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.appendChild(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=addParagraph.

    <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.
     
    Richard Cornford, Jan 8, 2007
    #7
  8. dd

    Randy Webb Guest

    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.javascript FAQ - http://jibbering.com/faq/index.html
    Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/
     
    Randy Webb, Jan 8, 2007
    #8
  9. dd

    dd Guest

    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=addParagraph.


    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.
     
    dd, Jan 8, 2007
    #9
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Chris Seberino
    Replies:
    3
    Views:
    750
    Stefan Behnel
    Jun 12, 2009
  2. John Harvey
    Replies:
    0
    Views:
    163
    John Harvey
    Jan 9, 2006
  3. Mark Anderson

    Executing code before page load complete...

    Mark Anderson, Oct 23, 2003, in forum: Javascript
    Replies:
    2
    Views:
    290
    Mark Anderson
    Oct 23, 2003
  4. uoL
    Replies:
    2
    Views:
    92
  5. Rubikzube
    Replies:
    2
    Views:
    85
Loading...

Share This Page