End of .html parsing ?

Discussion in 'Javascript' started by Jorge, Sep 27, 2009.

  1. Jorge

    Jorge Guest

    Consider this:

    <html>
    <head>
    <script>
    setTimeout(function f1 () {
    alert(".html parsing done.");
    }, 0);
    </script>
    </head>
    <body>
    </body>
    </html>

    Is it safe to assume that f1 will be run, and that it won't run until
    the parsing has ended ?

    TIA,
    --
    Jorge.
    Jorge, Sep 27, 2009
    #1
    1. Advertising

  2. Jorge

    rf Guest

    "Jorge" <> wrote in message
    news:...
    > Consider this:
    >
    > <html>
    > <head>
    > <script>
    > setTimeout(function f1 () {
    > alert(".html parsing done.");
    > }, 0);
    > </script>
    > </head>
    > <body>
    > </body>
    > </html>
    >
    > Is it safe to assume that f1 will be run, and that it won't run until
    > the parsing has ended ?


    No.
    rf, Sep 27, 2009
    #2
    1. Advertising

  3. Jorge

    SAM Guest

    Le 9/27/09 2:49 PM, rf a écrit :
    > "Jorge" <> wrote in message
    > news:...
    >> Consider this:
    >>
    >> <html>
    >> <head>
    >> <script>
    >> setTimeout(function f1 () {
    >> alert(".html parsing done.");
    >> }, 0);
    >> </script>
    >> </head>
    >> <body>
    >> </body>
    >> </html>
    >>
    >> Is it safe to assume that f1 will be run, and that it won't run until
    >> the parsing has ended ?

    >
    > No.


    No?

    Then try :

    <html>
    <head>
    <script>
    var t1, t2;
    setTimeout(function f1 () {
    t1 = new Date();
    alert(".html parsing done.");
    document.getElementById('t').innerHTML = t1*1;
    }, 0);
    alert('Am I the first?');
    </script>
    </head>
    <body>
    <h1>title</h1>
    <script>
    t2 = new Date();
    </script>
    <p>does the JS fired before to see this "title" above ?</p>
    <h2>Annswer :</h2>
    <pre>
    <script>
    document.write("time spent between parsing :\nthe setTimeout (date:"+
    (t1*1)+")\nthe tilte (date:"+(t2*1)+")\ntotal = "+(t2-t1));
    </script>
    Time t1 = <span id="t">? ? ?</span>
    </pre>
    </body>
    </html>


    Where I think that we can now say that Jorge is right.
    --
    sm
    SAM, Sep 27, 2009
    #3
  4. Jorge

    SAM Guest

    Le 9/27/09 3:48 PM, Hans-Georg Michna a écrit :
    > On Sun, 27 Sep 2009 04:50:57 -0700 (PDT), Jorge wrote:
    >
    >> Consider this:
    >>
    >> <html>
    >> <head>
    >> <script>
    >> setTimeout(function f1 () {
    >> alert(".html parsing done.");
    >> }, 0);
    >> </script>
    >> </head>
    >> <body>
    >> </body>
    >> </html>
    >>
    >> Is it safe to assume that f1 will be run, and that it won't run until
    >> the parsing has ended ?

    >
    > Jorge,
    >
    > it is safe to assume that f1 will be run, but if by "parsing"
    > you mean "rendering to screen", then no, it will usually run
    > before the parsing has ended, provided the web page is a bit
    > bigger than the empty example above.


    I think Jorge speak of 'parsing'.
    About 'run' I think he does a difference with 'fire'

    The setTimeout fires as soon as it's parsed (normal, no?)
    but the f1 will rum at that moment +0
    that's to say after complete parsing of the file

    .... if I had well tested (?) (only in Fx.3)

    --
    sm
    SAM, Sep 27, 2009
    #4
  5. Jorge

    Jorge Guest

    On Sep 27, 3:48 pm, Hans-Georg Michna <hans-
    > wrote:
    > On Sun, 27 Sep 2009 04:50:57 -0700 (PDT), Jorge wrote:
    > >Consider this:

    >
    > ><html>
    > ><head>
    > ><script>
    > > setTimeout(function f1 () {
    > > alert(".html parsing done.");
    > > }, 0);
    > ></script>
    > ></head>
    > ><body>
    > ></body>
    > ></html>

    >
    > >Is it safe to assume that f1 will be run, and that it won't run until
    > >the parsing has ended ?

    >
    > Jorge,
    >
    > it is safe to assume that f1 will be run, but if by "parsing"
    > you mean "rendering to screen", then no, it will usually run
    > before the parsing has ended, provided the web page is a bit
    > bigger than the empty example above.


    I meant parsing (of the DOM tree) not rendering (*)

    > In all browsers I know the rendering to screen is totally
    > invisible to the JavaScript subsystem, and there is no direct
    > way to find out what the browser's rendering engine is doing or
    > has done. Also they usually don't render to screen before the
    > JavaScript code has finished running, perhaps with the exception
    > of Opera. In other words, JavaScript execution has a higher
    > priority than rendering to screen.
    >
    > Have a look athttp://winhlp.com/node/633for a possible way to
    > wait until the rendering to screen is complete. You can copy the
    > code and use it without understanding it fully, but test it
    > thoroughly in your application.


    setTimeout(, 20ms) in order to allow the rendering to finish ?
    Sorry but no, I don't think that's the way it works.
    Although that might be true for IEs (I don't know) it's not so in
    Safari, Chrome FiereFox nor Opera.

    > But note that you normally need to worry about this question
    > only when you have both a considerable amount of calculation to
    > do and a considerable amount of DOM to render. If any of the two
    > is small, no worries.


    I was thinking about a dom-ready callback, after parsing but before
    onload. I've written a test page and this setTimeout(f, 0); technique
    is looking quite good to me: see: http://jorgechamorro.com/cljs/083/index6.html

    (*)related and interesting : http://www.youtube.com/watch?v=a2_6bGNZ7bA

    Cheers,
    --
    Jorge.
    Jorge, Sep 27, 2009
    #5
  6. Jorge

    Jorge Guest

    On Sep 27, 5:05 pm, Stefan Weiss <> wrote:
    >
    > No. That's easy to disprove by adding a delay somewhere on the page, for
    > example with PHP:
    >
    > <body>
    >   <p>line1</p>
    >   <? flush(); sleep(2); ?>
    >   <p>line2</p>
    > </body>
    >
    > The alert will show up long before "line2" becomes visible. I've only
    > tested this with FF3, but one browser is all it takes to answer "is it
    > safe to assume" :)


    Could you please put this online somewhere for me to test it too ?

    Thanks !
    --
    Jorge.
    Jorge, Sep 27, 2009
    #6
  7. Jorge

    SAM Guest

    Le 9/27/09 5:05 PM, Stefan Weiss a écrit :
    > On 27/09/09 13:50, Jorge wrote:
    >> Consider this:
    >>
    >> <html>
    >> <head>
    >> <script>
    >> setTimeout(function f1 () {
    >> alert(".html parsing done.");
    >> }, 0);
    >> </script>
    >> </head>
    >> <body>
    >> </body>
    >> </html>
    >>
    >> Is it safe to assume that f1 will be run, and that it won't run until
    >> the parsing has ended ?

    >
    > No. That's easy to disprove by adding a delay somewhere on the page, for
    > example with PHP:
    >
    > <body>
    > <p>line1</p>
    > <? flush(); sleep(2); ?>
    > <p>line2</p>
    > </body>
    >
    > The alert will show up long before "line2" becomes visible. I've only
    > tested this with FF3, but one browser is all it takes to answer "is it
    > safe to assume" :)


    I tried that and did a mistake as all appears in one time and before the
    alert (or very very close after).
    (Fx.3 too)

    Anyway I don't see what that can reveal except the wait on server.

    --
    sm
    SAM, Sep 27, 2009
    #7
  8. Jorge

    Luuk Guest

    Jorge schreef:
    > Consider this:
    >
    > <html>
    > <head>
    > <script>
    > setTimeout(function f1 () {
    > alert(".html parsing done.");
    > }, 0);
    > </script>
    > </head>
    > <body>
    > </body>
    > </html>
    >
    > Is it safe to assume that f1 will be run, and that it won't run until
    > the parsing has ended ?
    >
    > TIA,
    > --
    > Jorge.


    i think readyState should be used for this

    w3.org:
    http://www.w3.org/TR/2006/WD-XMLHttpRequest-20060405/

    msdn.microsoft.com:
    http://msdn.microsoft.com/en-us/library/ms534359(VS.85).aspx

    i think it will work on other browsers than IE too...

    --
    Luuk
    Luuk, Sep 27, 2009
    #8
  9. Jorge

    Jorge Guest

    On Sep 27, 6:10 pm, Stefan Weiss <> wrote:
    >
    > @Jorge, I've put the example page online so you can try it out:
    >
    >   <http://foo.at/paste/2009/test_delayed.php>
    >
    > To make it more noticeable, I increased the delay to 5 seconds.


    Yep, in some browsers the alert comes up long before line 2... and
    therefore while still parsing the .html.

    Big thanks !

    Cheers,
    --
    Jorge.
    Jorge, Sep 27, 2009
    #9
  10. Hans-Georg Michna wrote:
    > On Sun, 27 Sep 2009 08:41:11 -0700 (PDT), Jorge wrote:
    >> I meant parsing (of the DOM tree) not rendering (*)

    >
    > For that there is the window.onload event or, better, if you use
    > jQuery,


    .... which you shouldn't ...

    > the jQuery(document).ready(fn), where fn is a callback
    > function that is called when the DOM is completely built and
    > ready to be traversed.


    Hardly.

    > The short form of that is what you often see: $(fn);


    .... which is equally, if not more stupid, as it unnecessarily wraps a
    Function object in another object, inefficiently, just to call it.

    > jQuery works a bit of magic here, but if you want to rely on
    > pure JavaScript, use window.onload, perhaps with a little
    > additional checking whether everything is completely there.
    >
    > https://developer.mozilla.org/en/DOM/window.onload


    Neither is jQuery any kind of magic (rather the opposite if you look into it
    and have any clue about what you are doing), nor is `window.onload' "pure
    JavaScript"; it is a proprietary property of an object provided by some host
    environments that should not be used, for there is the fully
    standards-compliant and backwards-compatible `onload' attribute of the
    `body' element that provides the very same functionality in a much more
    reliable way.


    PointedEars
    --
    var bugRiddenCrashPronePieceOfJunk = (
    navigator.userAgent.indexOf('MSIE 5') != -1
    && navigator.userAgent.indexOf('Mac') != -1
    ) // Plone, register_function.js:16
    Thomas 'PointedEars' Lahn, Sep 27, 2009
    #10
  11. Hans-Georg Michna wrote:
    > Jorge wrote:
    >> <html>
    >> <head>
    >> <script>
    >> setTimeout(function f1 () {
    >> alert(".html parsing done.");
    >> }, 0);
    >> </script>
    >> </head>
    >> <body>
    >> </body>
    >> </html>
    >>
    >> Is it safe to assume that f1 will be run, and that it won't
    >> run until the parsing has ended ?

    > [...]
    > it is safe to assume that f1 will be run, but if by "parsing"
    > you mean "rendering to screen", then no, it will usually run
    > before the parsing has ended, provided the web page is a bit
    > bigger than the empty example above.
    >
    > In all browsers I know the rendering to screen is totally
    > invisible to the JavaScript subsystem, and there is no direct
    > way to find out what the browser's rendering engine is doing or
    > has done. [...]


    However, you have evaded the question. Parsing (tokenizing the source code)
    must happen before rendering (painting a graphical representation of tokens
    that have or generate a graphical representation).

    Insofar it stands to reason and can be shown that a `script' element's
    content is going to be executed when the `script' element and its previous
    siblings have been parsed (but not necessarily rendered, or the
    corresponding DOM objects created). So it is possible to determine when
    parsing has (nearly) finished; for example, code in a `script' element that
    is the last child of the `body' element (ignoring white-space text nodes)
    will execute then and not before. (However, with the W3C DOM the `load'
    event appears to be best suited to determine that moment more exactly.)

    Therefore, if `f1' is called at all (the markup is not Valid, setTimeout()
    is not defined a built-in method of the Global Object, the Function instance
    reference may not be supported, 0 may not be supported for the second
    argument), it is going to be called almost immediately after the `script'
    element has been parsed (as 0 would be the approximate number of
    milliseconds after the setTimeout() call after which `f1' would be called),
    and the correct answer to the OP's question must be "no" (it is not safe to
    assume [the opposite]). After all, the `head' element is parsed before the
    `body' element, and this `script' element is a child of the `head' element.

    But, as you say correctly, in a standard-security environment it is not
    possible *in general* to determine with scripting when *rendering* has
    finished; for example, the `load' event specification does not define if all
    referred image resources have been downloaded and rendered when the event
    occurs. There are special cases, though, where it can be determined with
    scripting whether rendering was finished.


    PointedEars
    --
    Anyone who slaps a 'this page is best viewed with Browser X' label on
    a Web page appears to be yearning for the bad old days, before the Web,
    when you had very little chance of reading a document written on another
    computer, another word processor, or another network. -- Tim Berners-Lee
    Thomas 'PointedEars' Lahn, Sep 27, 2009
    #11
  12. Jorge

    SAM Guest

    Le 9/27/09 6:10 PM, Stefan Weiss a écrit :
    > On 27/09/09 17:50, SAM wrote:
    >> Le 9/27/09 5:05 PM, Stefan Weiss a écrit :
    >>> <body>
    >>> <p>line1</p>
    >>> <? flush(); sleep(2); ?>
    >>> <p>line2</p>
    >>> </body>
    >>>
    >>> The alert will show up long before "line2" becomes visible. I've only
    >>> tested this with FF3, but one browser is all it takes to answer "is it
    >>> safe to assume" :)

    >> I tried that and did a mistake as all appears in one time and before the
    >> alert (or very very close after).
    >> (Fx.3 too)
    >>
    >> Anyway I don't see what that can reveal except the wait on server.

    >
    > The point is that the alert box appears before HTML "parsing has ended".


    Not in my tests.

    > If you don't see the effect, maybe it's browser dependent; I used FF3.0
    > on Linux for testing.


    FF3.014 (cache disabled)
    on iMac-Intel 10.4.11
    and its server [Apache/1.3.41 (Darwin) PHP/5.2.4].

    > @Jorge, I've put the example page online so you can try it out:
    >
    > <http://foo.at/paste/2009/test_delayed.php>


    Same config as given above :
    Line 1
    then alert
    then line 2
    Right as you said.

    Can we get your file in text ?
    because mine didn't do that, display nothing, wait, then display all and
    alert without possibility to see which one was really the first.
    I tested it on my server Apache at home.
    I uploaded it on free.fr ...
    .... the php line seems there to do not be interpreted :-(

    Notice that Safari with that url displays all together (lines and alert)
    at end of delay.

    > To make it more noticeable, I increased the delay to 5 seconds.


    My file with delay 6 seconds, on server at home :
    - FF.3 : white, wait, display all, alert (in this order, sure)
    - Safari.3 : white, wait, display all together (window and alert)

    My tested file in copy-paste :

    <html>
    <head>
    <script>
    setTimeout(function f1 () {
    alert(".html parsing done.");
    }, 0);
    // alert('Am I the first?');
    </script>
    </head>
    <body>
    <h1>title</h1>
    <?php flush(); sleep(6); ?>
    <p>ligne test php</p>
    <pre>
    Time t1 = <span id="t"></span>
    </pre>
    </body>
    </html>


    --
    sm
    SAM, Sep 27, 2009
    #12
  13. Jorge

    rf Guest

    "SAM" <> wrote in message
    news:4abf6b20$0$23447$...
    > Le 9/27/09 2:49 PM, rf a écrit :
    >> "Jorge" <> wrote in message
    >> news:...
    >>> Consider this:
    >>>
    >>> <html>
    >>> <head>
    >>> <script>
    >>> setTimeout(function f1 () {
    >>> alert(".html parsing done.");
    >>> }, 0);
    >>> </script>
    >>> </head>
    >>> <body>
    >>> </body>
    >>> </html>
    >>>
    >>> Is it safe to assume that f1 will be run, and that it won't run until
    >>> the parsing has ended ?

    >>
    >> No.

    >
    > No?


    Yes, no. It is not safe to assume that f1 will be run. Javascript might be
    turned off.
    rf, Sep 28, 2009
    #13
  14. Jorge

    SAM Guest

    Le 9/28/09 1:38 AM, Stefan Weiss a écrit :
    > On 28/09/09 00:01, SAM wrote:
    >>
    >> Can we get your file in text ?

    >
    > Of course: http://foo.at/paste/2009/test_delayed.php.txt
    >
    >> My tested file in copy-paste :
    >>
    >> <html>
    >> <head>
    >> <script>
    >> setTimeout(function f1 () {
    >> alert(".html parsing done.");
    >> }, 0);

    > ...
    >
    > Looks similar enough.


    Yes.

    Tried your file on my home server with FF ...
    white, wait, then window and alert together :-(

    I don't know what to tell to my Apache to get same behavior than at your
    site.

    --
    sm
    SAM, Sep 28, 2009
    #14
  15. Jorge

    Jorge Guest

    On Sep 28, 1:13 am, "rf" <> wrote:
    > (...) Javascript might be
    > turned off.


    Sheesh ! Still advocating the good ol' form-comes form-goes web
    model ?

    Do you want to know a secret ?
    In the very near future *nobody* will want a browser without a good
    javascript engine under the hood.
    --
    Jorge.
    Jorge, Sep 28, 2009
    #15
  16. Jorge

    Bart Lateur Guest

    Jorge wrote:

    >Consider this:
    >
    ><html>
    ><head>
    ><script>
    > setTimeout(function f1 () {
    > alert(".html parsing done.");
    > }, 0);
    ></script>
    ></head>
    ><body>
    ></body>
    ></html>
    >
    >Is it safe to assume that f1 will be run, and that it won't run until
    >the parsing has ended ?


    Well I often use this as an alternative to onWindowLoad. I've never
    known it to fail.

    --
    Bart.
    Bart Lateur, Sep 28, 2009
    #16
  17. Jorge

    Bart Lateur Guest

    Jorge wrote:

    >On Sep 28, 1:13 am, "rf" <> wrote:
    >> (...) Javascript might be
    >> turned off.

    >
    >Sheesh ! Still advocating the good ol' form-comes form-goes web
    >model ?
    >
    >Do you want to know a secret ?
    >In the very near future *nobody* will want a browser without a good
    >javascript engine under the hood.


    Wrong. Lots of people use NoScript, and only turn Javascript on for
    domains they know, and trust.

    --
    Bart.
    Bart Lateur, Sep 28, 2009
    #17
  18. Jorge

    Bart Lateur Guest

    Bart Lateur wrote:

    >Well I often use this as an alternative to onWindowLoad. I've never
    >known it to fail.


    Judging by the posts in the rest of this thread, I've just been lucky.
    :)
    --
    Bart.
    Bart Lateur, Sep 28, 2009
    #18
  19. Bart Lateur kirjoitti:

    > Wrong. Lots of people use NoScript, and only turn Javascript on for
    > domains they know, and trust.


    And then some, take me for example. I script kid around almost daily,
    but still I surf with QuickJava extension that by (my) default disables
    JavaScript (and Java). And that backed up with (blacklisting) YesScript,
    in case I decide, to quote Jorge, to turn on my good javascript engine
    under the hood.

    I really hope that Jorge's vision about the future of the Web turns out
    to be an illusion.

    --
    Nada personal,
    Osmo
    Osmo Saarikumpu, Sep 28, 2009
    #19
  20. Hans-Georg Michna wrote:
    > On Mon, 28 Sep 2009 17:09:33 +0300, Osmo Saarikumpu wrote:
    >
    >> I really hope that Jorge's vision about the future of the Web turns out
    >> to be an illusion.

    > s
    > Osmo,
    >
    > I am convinced that JavaScript will gain even more widespread
    > acceptance in the very near future. I actually even like that,
    > but even if I didn't, I would have to adapt to it.
    >
    > Just-in-time JavaScript compilers and new releases of the
    > language will be built into all major browsers. They will open
    > the floodgates to many new applications we may not even be able
    > to imagine right now. JavaScript may well supplant some other
    > technologies, like Flash.
    >
    > I can only contribute a tiny example for a heavily
    > computing-intensive and not web- or Internet- or browser-related
    > program written in JavaScript, "Telly", at
    > http://winhlp.com/telly/ ,


    Warning: this is extremely intensive application that may cripple the
    system it runs on.

    which can serve as a simple speed
    > test. It merely uses the browser as its hardware-independent
    > platform.
    >
    > Works best in Firefox right now, but does work in the other
    > major browsers, albeit more slowly. Haven't done any speed tests
    > with the allegedly compiling Google Chrome.


    It is not apparent what that web page is supposed to be doing.

    Using Firefox 3.5, I see a few navigation links (those work), a dropdown
    menu with "English" selected, a text input field, a button with "...".

    It doesn't seem to do anything useful in the one browser you claim it
    "works best" in.

    View source reveals invalid XHTML served as text/html and jquery.js.
    A fair assessment of the quality would probably be "junk".

    Launching safari 4, I see:
    | Change your telephone number into words you can use to dial.

    Entering a phone number, Safari became unresponsive. Launching Task
    manager, I see CPU at 60%, and Safari at nearly 1gb memory usage.
    --
    Garrett
    comp.lang.javascript FAQ: http://jibbering.com/faq/
    Garrett Smith, Sep 30, 2009
    #20
    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. Neo Geshel
    Replies:
    2
    Views:
    3,555
    Versteijn
    Aug 18, 2004
  2. William
    Replies:
    2
    Views:
    1,704
    Kevin Spencer
    Jun 1, 2005
  3. Replies:
    2
    Views:
    339
  4. Jimmy
    Replies:
    3
    Views:
    302
    J. J. Farrell
    Sep 9, 2011
  5. Jimmy
    Replies:
    13
    Views:
    626
    Peter Nilsson
    Sep 21, 2011
Loading...

Share This Page